COMPUTERS and COMPOSITION 9(2), April 1992, pages 17-39

We know by now that increasing numbers of composition instructors are teaching in computer-assisted classrooms. Barnes (1989), in her interviews with five such instructors, noted that if these instructors were to design a textbook for teaching writing with computers, "they would want one that contains writing activities that secondarily teach word processing" (p. 32). More recently, Kantrov (1991), in her review of research on the integration of word processing with writing instruction, states that:

If we want students to take advantage of the potential of the technology, and to overcome its disadvantages, we have to integrate word-processing technologies into writing instruction. Students need to learn about the capabilities of word processing; they need guided practice in using those capabilities to carry out writing tasks; they need to see demonstrations of specific strategies . . .; and they need to learn about the potential pitfalls and the ways to avoid them . . . They can then evolve their own ways of making the best use of the particular features of word processing at their disposal. (p. 74)

Despite these suggestions, composition textbooks often present limited treatments of word-processing strategies or they include extensive technical jargon. In Perrin's (1988) review of ten handbooks, he notes that while authors and publishers recognize the need for instruction on word processing and writing, they do not incorporate discussions that are complete. In the reverse case, or when composition textbooks include extensive explanations of word processing-strategies, instructors often view these as including too much "computer-tech" language (Barnes, 1989, p. 31). Essentially, instructors seem to prefer textbooks that offer new models for teaching writing "not formerly possible in the noncomputer paradigm of composition teaching" (Barnes, p. 34). To fulfill this need, Barnes states that publishers should "create collaborative teams of both software specialists and expert composition teachers that will explore ways the software can be adapted . . . assuring the fullest possible exploitation of computer-assisted composition classrooms" (p. 34).

Over the past year, we participated in such a collaborative process to create a first-year composition textbook that works to integrate word processing with the teaching of writing. From this experience, we learned that collaborating on a textbook--especially one that integrates instructions for word processing at appropriate stages in the teaching and learning of writing--is a complex and difficult form of collaboration. Farkas (1991) offers six reasons why the collaborative development of integrated texts is a difficult process:

1. Highly integrated documents are very complex artifacts.
2. The process of preparing a document becomes more complex when it is performed collaboratively.
3. The writing process generates strong emotional commitments.
4. Documents are reworkable and are subject to infinite revision.
5. Collaborative writers lack fully adequate terms and concepts with which to create a clear and precise common image of the document they wish to produce.
6. It is difficult to predict or measure success. (p. 15)
   

In this article, we describe the collaborative process involved in the development of Writing with the Macintosh: Using Microsoft Word (1991). This collaboration involved developing a highly integrated document through a process that included strong commitments, vast amounts of revision, and terms and concepts that evolved throughout the development process. Although researchers and theorists have described how writers collaborate on reports and other nonacademic documents (Lunsford & Ede, 1990), how business professionals collaborate to develop corporate statements (Cross, 1990), and how scientists collaborate on major grants (Olsen, 1989), to our knowledge no one has described in detail the collaborative development of a textbook that integrates the teaching of technology with writing instruction.

Indeed, in 1989 W. Ross Winterowd stated that "considering the stakes, the game played by publishers and textbook authors is extraordinarily consequential, yet scholars and authors and scholar-authors have paid too little attention to the rules, the ethics, the tradition, or the results" (p. 139). Thus, by describing our experience, we wish to offer a process that collaborative teams of instructors, software specialists, and publishers might follow when developing future college textbooks. We hope that describing our experience will be helpful for those instructors interested in developing texts that integrate computer applications with college composition courses as well as courses in other areas. We also hope that this information will aid publishers in revising and refining their production processes to include the additional personnel and time needed to develop this new form of college text.

To begin, the audience for Writing with the Macintosh: Using Microsoft Word (WWTM) is first-year college composition students, and the purpose is to teach students how to apply word-processing strategies at appropriate stages in the writing process. In order to integrate tutorials about computer applications into college textbooks, we followed a textbook development and production process that involved intense collaboration on the part of a larger number of people than would normally collaborate on a composition textbook.

Grice (1991), in describing the information-development process in place at IBM, centers his discussion around the types of verification needed when developing technical information. He states that "verification is one of the most important steps in producing good technical information; it rightly makes up a major portion of the information-development cycle" (p. 224). Though a college composition text may not readily seem a form of technical information, an integrated composition and word processing text must combine the teaching of writing with the technical information involved in using a word-processing program. Therefore, when beginning this project, we knew that the development of this text would follow a process different from the development processes of more traditional texts.

Grice (1991) classifies his verification activities into four categories: editing, reviewing/inspecting, usability testing, and ensuring early customer involvement. While we prefer the word collaboration to verification, we find that Grice's descriptions of these four categories overlap a great deal with the people involved in the development of WWTM and with the collaborative process that we followed. The following descriptions give an overview of the collaborators involved in this project:

• Under editing, our product manager or main editor scrutinized all of our work--and that of all the other people involved in the project--for style, structure, and adherence to the purpose and audience for the text, as well as to established standards and conventions.
  
• Under reviewing/inspecting, we had 12 reviewers review two drafts of a proposal and project outline and up to three drafts of each chapter in the text. These reviewers ranged from those who were fairly new in their use of computers to those who were "technical experts" in terms of their knowledge of computers and experience with teaching in computer settings. We also had numerous support staff design, review, or inspect components such as concept art and style templates, and we had copy editors and proofreaders review and alter the text as well.
  
• Under usability testing, we had quality assurance people (who were currently college students) test all versions of the chapters in a controlled setting to determine the texts' and tutorials' accuracy, suitability, and usability.
  
• Under ensuring early customer involvement, we had two first-year composition sections use an early version of the text and its associated computer files in the same way that we intended the final version to be used in the classroom.
  

As co-authors we worked with all of the above people, but our collaboration took place via the direction of the product manager. Though we relied a great deal on the product manager's scrutiny and interpretation of feedback from reviewers, support staff, copy editors, proofreaders, and quality assurance people, all of the above parties acted and were involved with the making of meaning within this text. In this sense, our collaboration took a Bakhtinian form (Bakhtin, 1984) in that, rather than working toward consensus (Bruffee, 1984), collaborators in this project became involved in a dialogue of response and counter response, in a process that included voicing opposing views and sharing decisions (Weiss, 1991). Through this shared collaboration, we found ourselves making connections--sharing a social stream, a social milieu--with our product manager, with reviewers, with students, with the publication department, and with each other as co-authors. Like a stream that has many currents, these collaborative connections ran concurrently throughout the project. Had any one connection failed, we could not have completed the project. This leads to our discussion of six connections that made up our collaborative process.

Author-Author Connection

The collaborative process began when Ann drafted the original proposal for this text and met with the President and Vice President of Course Technology, Inc. (CTI, the publisher of this text) on two occasions prior to Kathleen's involvement. The original proposal (dated April, 1990) stated the following objectives of the text:

• to help writers improve their writing processes through the use of the word-processing program;
  
• to illustrate how the word-processing program supports writers throughout the planning, drafting, revising, and editing stages of designing documents and to progressively expose writers to word processing features;
  
• to demonstrate how writers can use the word-processing program to collaborate throughout the writing process; and
  
• to orient writers to a problem-solving approach toward writing in their first-year composition course.
  

The chapters listed in the original proposal are presented in Table 1. Desiring to incorporate a more visual emphasis throughout the writing process, Ann then asked Kathleen (a Ph.D. student in training and development and an expert on the use of MICROSOFT WORD) if she wished to collaborate on the text. Ann also realized that such collaboration was needed in order to meet CTI's compressed timetable (six months to complete the text).

We began our collaboration by discussing our individual writing styles as well as the variables that Lunsford and Ede (1990) note influence success and satisfaction in collaborative writing groups: control over texts, how credit will be given, how we would respond to modifications in each other's texts, flexibility with the CTI style guide, our deadlines and other constraints, and the status of the project in terms of our work time and commitment. We then revised the original proposal to include a more visual emphasis as the first revision of the chapters in Table 1 (especially chapters 3, 4, 7, and 9) indicates. CTI's product manager then sent our revised proposal to reviewers.

Nearly all of the reviewers reacted negatively to our inclusion of chapter 3, "Designing for Diverse Readers," and chapter 4, "Thinking Visually," in the early chapters of the text, stating that design and visual concerns should not be a major focus for first-year composition students. They also felt that developing and incorporating graphics (chapter 7) was not an area for first-year composition students to pursue. One reviewer summed up the general consensus by stating that:

Visual elements of the written product are extremely important, especially in professional writing. They aren't so important in academic writing, however. Since freshman composition is usually taught as an academic writing course rather than a business writing course, this could be a problem. Most composition instructors 1) try to avoid the general glitz that computers have to offer and 2) think that obsession with visuals and detail on computers is a typical student problem. Not to say that we shouldn't get beyond this: perhaps we should teach professional writing and presentation across the board. We're not there yet (Reviewer's correspondence with the product manager, 22 August 1990).

Although the stated objectives in the second proposal remained similar to those stated in Ann's first proposal, we provided detailed descriptions of the chapters according to CTI's Detailed Development Outline specifications. For example, Table 2 shows our detailed development outline for chapter 5, "Making Plans and Organizing Ideas." Note the categories and format of this outline, and thus the resulting emphasis on the software and tutorial steps.
 

Although we had preceded the outlines with prose detailing the text's objectives, and although the text's objectives had not changed, the majority of reviewers reacted strongly to the "technical" feel of the text, stating that it was more computer manual than textbook and that it should focus first on writing. Though we felt that our statements clearly stressed our goals of using word processing to facilitate writing (and not the reverse), the visual presentation of the detailed development outlines with specified headings such as "Software Learning Objectives" and "General Sequence of Steps," contributed to the reviewers' nearly unanimous reaction that the proposed text bowed to technology. Again, one of the reviewers summed up the general consensus as follows:

[There is] not enough emphasis on writing. If this is going to be an effective writing textbook, rather than just a student version of a word processor manual, there needs to be much more emphasis on the writing process . . . The outline must go into more detail on substantive writing instruction--all else must be subordinate (Reviewer's correspondence with the product manager, 20 August 1990).

Needless to say, we drafted a third proposal, scrapped the detailed development outlines, and opted instead to elaborate on the purposes, concepts, and skills that we intended to focus on in each chapter (note the chapters listed under the Second Revision in Table 1). To our disappointment, and after numerous conference calls with our project manager, we moved chapter 4, "Thinking Visually," and chapter 7, "Developing and Incorporating Graphics," to the end of the text. Our goal of integrating this information into the writing process was welcomed by only one of the reviewers. In addition, chapter 3, "Designing for Diverse Readers," now became chapter 8, "Writing for Diverse Audiences," placing attention toward readers' differing purposes for reading more as a revising theme instead of a major focus during the planning and organizing stages. As we expanded our proposed concepts and skills for each chapter, we also realized that our expectations for some chapters had been too great, and we thus developed additional chapters.

Reviewers were pleased with our revisions, and we began to settle into our own specialized form of collaboration. Ann was responsible for the majority of the textual information about writing, and Kathleen was responsible for the majority of the tutorials. Generally, our collaboration and the document-cycling process is described in the following paragraphs.

First, Ann expanded on elements detailed in the third proposal and developed the early text of a chapter. This early draft included numerous comments to Kathleen about the types of tutorials that were needed as well as ideas concerning steps that students might follow when learning a specific word processing feature. Table 3 shows one excerpt from instructions in chapter 4 on analyzing one's audience. This example illustrates how Ann inserted comments to Kathleen.

Next, Kathleen added tutorials to the rough text and returned this to Ann with notes concerning questions as well as other ideas that might be included. Ann then reviewed Kathleen's notes, revised the text and tutorials, added new questions and notes to Kathleen, and returned this draft to her. Kathleen then revised and sent her copy with notes back to Ann.

Table 4 shows one example of how Ann added more comments and questions to Kathleen's development of the audience analysis section (which included an Audience Analysis Grid tutorial). This example also shows Kathleen's early development of the tutorial steps as well as her emoticon or typographic indication of her feelings toward her notes and responses.
 

This document cycling process continued until we felt a draft was ready to send to CTI and, subsequently, to the reviewers. We could neither have met the short timetable for this project nor made extensive comments and revisions to each other's text without the use of technology. This leads us to a discussion of the technologies that we used in this project.

Computer-Computer Connection

Numerous researchers note the influence of the computer on collaboration. Wheeler (1988) cites the importance of a word-processing program's style sheet on helping collaborative groups develop and support cohesiveness in their writing; Forman (1987) emphasizes that electronic mail is the preferred communication medium for managers' revision of drafts; O'Hara (1988) describes how electronic mail allows writers and project coordinators to go through three review sessions in one day; and van Pelt and Gillam (1991) state that "once writers start using the computer in this way, they rapidly become heavily dependent on it, often unconscious of how thoroughly it is woven into their writing process" (p. 177). Likewise, we found that we were not only developing a text that integrated the computer into the writing process, but that we were weaving technology into our collaboration.

We first used BITNET to send sections of drafts back and forth to each other. However, we found that the extra time needed to reformat text was too great. Therefore, we found driving an hour to meet with each other and swapping disks to be more efficient than using BITNET. We also found that the face-to-face meetings helped us to become better acquainted with each other and offered an opportunity to brainstorm together.

Shortly thereafter, Kathleen located a simple telecommunications program, MACKNOWLEDGE, which we used to send binary forms of drafts to each other. We quickly found that this program enhanced the quality and speed of our collaboration. Instead of having to drive an hour to meet each other or sending disks through the mail, we could now send and respond to drafts in a single day. And because this program sent documents in the same form and appearance as one created them, the sender could boldface her comments and questions, and the receiver could easily spot these comments and respond to them (much as Tables 3 and 4 show in terms of our using boldface for questions and responses to each other).

Our product manager also purchased this software, and we began sending early drafts and notes to him for his initial feedback. Our product manager was clearly a strong collaborator throughout all stages of the project, and we will discuss specifics concerning our collaborative connection with him next in the next section.

Author-Product Manager Connection

We collaborated with our product manager and his editorial assistant through the telecommunications program described in the previous section, as well as through conference calls, phone messages, Federal Express or Express Mail, FAX machines, and (though rarely) traditional mail. Of all these technologies, the strongest in terms of aiding the author-product manager connection was the telecommunications program. In the early stages of collaboration, we made paper copies of all drafts, comments, and responses, but as the number of revisions grew, these copies became too difficult to keep track of, and we found that our initial reliance on paper evolved into a reliance on telecommunications. After only a month of collaboration, our product manager expected us to send him nearly everything via telecommunications. This way, we could send a draft to him in the morning, and he could send it to reviewers that afternoon.

We also collaborated with our product manager and his assistant through weekly or twice weekly conference calls. These calls usually took one to two hours and resulted in over 35 hours of conference call time. Although we discussed logistics, deadlines, and the product development process, we spent the most time discussing the audience and purpose for the text, the areas where we needed additional reviewer input, and our responses and revision decisions based on the reviewers' comments and quality assurance tests. Grice (1991), in discussing the editor-writer verification/collaboration, states that:

Writers must learn how to work with editors in all phases of the writing process rather than just at the end so that the editor is a full contributor to the development of the information. This continuing involvement throughout the process saves time, produces better information units, and ensures a consistent, thorough treatment of the information. (p. 233)

Our product manager not only worked with literary or stylistic editing, technical editing, and copy-editing; more importantly, he became a full collaborator with us. He used every opportunity possible through available technologies to read our early drafts, respond to them, deliver our questions to reviewers, call reviewers for feedback, and synthesize this feedback for us. His continual conversation with the reviewers resulted in the reviewers becoming much more than evaluators of the text; through the product manager, the reviewers became collaborators, connected with us in making meaning. This leads to a fuller description of the author-product manager-reviewer connection.

Author-Product Manager-Reviewer Connection

As we stated at the beginning of this paper, our product manager scrutinized all of our work--and that from all of the other people involved in the project--for style, structure, and adherence to standards and conventions. Even more than this verification, the product manager strived to keep all collaborators focused on the audience and purpose of the text. As stated earlier, the product manager communicated regularly with the reviewers throughout the project. The reviewers represented a range of computer expertise and institutions of higher education, and through the filter of the product manager, the reviewers influenced the text a great deal.

As an example of the review process, the list below includes the questions that the product manager asked the reviewers to respond to concerning chapter 4 of the text. These questions were a blend of our questions to the product manager (and subsequently to reviewers) as well as his questions to reviewers.

• Do the scenarios at the start of the chapter successfully orient students to the detailed discussions that follow? Are they useful?
  
• Does the primary importance of writing and not word processing remain clear?
  
• Chapter 4 includes six prewriting strategies. Should we include all of them in this chapter? If not, which will be most useful and understandable for our intended audience? Which strategies are better included in the Instructor's Manual?
  
• Do you think that listing and using the Microsoft WORD "Sort" feature demonstrates how to use WORD as a tool for writing? Will students be able to understand the keyboard directions for using the "Sort" feature?
  
• Do the grids help students to analyze themselves, their readers, the text, and their purpose? Will students be able to use the grids with Microsoft WORD?
  

The reviewers responded to each draft and sent their comments to the product manager. As the project continued, reviewers began to request that the questions be sent to them on disks so that they could simply insert their feedback and then send back a disk or fax the comments to the product manager. The product manager would then delete any references to the reviewers' names or institutions and send copies of the comments to us. As authors, we began to know the reviewers by numbers, often finding ourselves liking or disliking certain "numbers" and anxiously awaiting the comments from other "numbers." Because of the large amount of reviewer feedback, both the product manager and Ann developed feedback grids and ordered these according to reviewers. These grids showed reviewer overlap and helped us to create lists of those revisions that most needed to be made. The reviewers thus became collaborators with us as their expertise led to major changes in the content and structure of the chapters.

A major concern of the reviewers during the early drafts was whether subsequent drafts would contain student examples. This leads to the next group of collaborators, our students, who supplied us with the student examples included in the text.

Author-Student Connection

As part of the design and development of any text that includes documentation, writers should iteratively develop and then share the text with potential users to uncover problems that should be corrected (Duin, 1990). That is, to iteratively design and develop a text, writers should do the following: plan and develop an early draft of the information and then "test" this information on users; based on how users respond to the information, writers should make additional plans, revise the first draft, and add and delete information as needed; they then test this information again on users, and the cycle repeats itself until the writers have a usable/final copy of the documentation. In the case of this text, while we were not able to test and retest the drafts in a strict sense, we were able to pilot test the document in two sections of a first-year composition course, and as students used the text and gave us feedback, we were able to supply them with revised tutorials and additional information.

Because of the project's six-month timeline, these students worked mostly with draft three of the chapters in part one, draft two of the chapters in part two, and draft one of the chapters in part three. For example, as part of their planning process in chapter 4, students used the Audience Analysis Grid discussed earlier. As students used the text, we worked to include their use of the text as student examples in the later drafts, always requesting the students' permission to do so. Thus, Table 5 shows part of one student's use of the Audience Analysis Grid which we included in the final versions of the text.

In order to preserve the students' use of the text and the grids, we asked the publication department not to copy-edit students' errors, so that the examples in the text could indeed represent the students' actual individual and/or collaborative work. In this way, the students were also collaborators with us: Their frustrations became our goals for revision, their insights became our elaborations, and their words became our examples.

Our students were not the only student collaborators with us on this text. In addition to our students' use of the text, CTI conducted laboratory-based testing (formally called Quality Assurance testing or QA for short) of all drafts of the text. CTI had students from local colleges in the Boston-Cambridge area come in and test the chapters and the tutorials. For each draft, two or three students would read the text and complete the tutorials, writing numerous comments in the margins and indicating what parts of the text confused them. Essentially, these QA students supplied verification as part of the usability testing process. According to Grice (1991):

Testing information improves the product's interface to the customer by ensuring that the information is a vital part of the product, not a superficial feature, and that it contributes to the product's ease of use . . . By measuring characteristics of the information . . . information developers can measure task performance including: time required to do a task, the number of errors made, and the amount of help needed, as well as the attitude of those taking the test towards the information and product being tested. (p. 236-237)

The verification that we could not have easily asked our own students for--the time required to complete tutorials, the number and types of problems encountered, and the specific amount of help needed--these QA students could provide. The QA students also collaborated with us in that they identified problems that reviewers, the product manager, our students, and ourselves as co-authors had not yet seen. They helped us decide when to add, delete, or condense information, and they regularly wrote about their attitudes toward the information. Indeed, it was refreshing to read that the text gave them new insights into their own writing processes, and it was equally frustrating when they gave up on a section because of missing information.

The QA students also gave us feedback on the style and layout of the text. The style of the text evolved through our collaboration with the publication department, which leads to our sixth collaborative connection.

Author-Publication Department Connection

Our author-publication department connection included the head of the production process, the copy editor, the graphic artist, the proofreader, desktop publishing personnel, additional QA students, and the indexer. Although we collaborated to varying degrees with these people, each played an important role in the development of the text.

Early on in the development of the text, we worked with the head of the production process to develop a style guide for the text. As part of our author-author collaboration, we found ourselves concurrently developing a style guide for the text as we generated the first drafts. We wanted the visual style of the text to help students identify the tutorials, and we wanted the font, column, margins, and other visual decisions to enhance students' understanding and use of the information. After we had sent a first draft of chapters 1-3 to CTI, the publication department sent us the style guide that they expected us to follow. Much as was the case with the categories in the detailed development outlines, we found the look and feel of the CTI style guide to lend itself more to a computer manual and less to a composition text. For example, the beginning of the CTI style guide stated that "This document describes how to use Microsoft Word and style sheets to write a manual for CTI. It is written in the form of a CTI tutorial" (1990, p. 1).

Because the majority of CTI's earlier products had been for more technical audiences, perhaps this style had worked for previous projects. However, we knew that if we followed this same style for audiences involved with first-year composition courses, this would confuse our audiences and cause our reviewers to once again state that we were placing technology ahead of writing. Therefore, we worked with the product manager and the head of production to design a new CTI style guide, which essentially can be seen in the format of the final text.

After we submitted our final drafts of the text to the project manager, our connections with collaborators in the production process dwindled to almost nil. Although we were slightly relieved to have a respite from the project, we still wanted to remain collaborators or makers of the final "meaning" of the text.

The first production person who formally worked with the text at this point was the copy editor. Under the product manager's guidance, the copy editor did what Grice (1991) would call "literary or stylistic editing, in which the editor examines the draft for correctness of grammar, wording, and punctuation" (p. 231). Although the product manager assured us that the copy editor understood the goals of the text and would work to maintain our style and tone, we found that the copy editor made changes that affected the text to a greater extent than we had expected. For example, in one tutorial in chapter 7, the final version which we sent to CTI contained the following short paragraph on tone:

As you read through your revised introduction, you should also check on the tone of your introduction. Tone can be difficult to assess. Think of tone as how your introduction would sound if spoken to your audience. When you talk with a young child, what tone do you use? If you explained your use of computers to an elderly adult, what tone would you use? If you presented this paper orally to your class, what tone would you use in your introduction?

When the product manager sent this chapter to the copy editor, he requested that she make some changes to this section in order to explain better the concept of tone. The copy editor thus revised the above section to read as follows:

As you read through your revised introduction, you should also check on the tone of your introduction. Tone may be thought of here as appropriate language for the audience you are addressing, for the subject, and for your point of view. For instance, if you were asked by another adult who is unfamiliar with computers to explain your writing in this class to her, you would try to avoid specialized terms such as "split bar," or misleading words such as "menu." On the other hand, you would respect that person's general knowledge and experience and not use babyish language or talk down to her.

When the product manager received this revised passage, he in turn changed the pronoun her in each case to him, and the final version of this short section appeared as the above section but with the masculine pronoun. Because we had worked hard to have a consistently inclusive text, this particular change especially bothered us.

This short example shows how, in some sections of the text, we lost our collaborative connection to the decision-making processes when we submitted our final draft of the text to the production department. Indeed, Winterowd (1989) cites similar cases where a publisher makes changes without informing the author and issues a book with the alterations in place. Although researchers have noted that goals and ways of operating need to change throughout the collaboration process (Malone, 1991), as authors we felt that the production process resulted in too little author-production department collaboration.

In some cases, once a text moves from the development to the production process, authors continue to have some involvement with the copy editor's work. However, in our case we did not have the opportunity to react to the copy-edited text. We feel that author involvement at this point should have been imperative. Although authors may now know the text so well that they miss identifying needed changes, authors still understand the tone and direction of the text and have had the greatest involvement, along with the project manager, with all other collaborators involved with the project.

Believing that the visual components of a text should enhance the verbal components, we had also requested more and closer collaboration with the graphic artist prior to the production process; however, the graphic artist did not formally become a collaborator until well into the production stage. Because our collaboration with the artist started so late, the artist had not been involved in a deeper understanding of the text and its goals, and therefore was not able to develop artistic themes that might have been used to visually unify the parts, chapters, and appendices.

Last, the proofreader, desktop publishing personnel, and additional QA students also participated at several points in the production process. Once a chapter had gone through the desktop publishing process, a proofreader and several QA students would verify that the information and steps were accurate. After a second desktop publishing pass and verification, the indexer entered the process, and then final pages would go through desktop publishing. After this point, the text went to a print vendor and our collaborative venture ceased. The prose from this major collaboration was now in print; there was no longer the chance to revise. While computer technology gave us the ability to adjust the text as we collaborated with reviewers, students, and some of the production personnel, at this point desktop publishing made the text permanent. Our fluid text became the fixed word.

We collaborated to develop Writing with the Macintosh: Using Microsoft Word because we wanted to help students improve their writing processes by teaching them strategies for using MICROSOFT WORD that are linked to and appropriate for all stages in their writing process. At the end of most of the chapters of the text we included strategies for collaborating at specific stages in the writing process. While strategies for collaborating are relatively easy to describe on paper, they are much harder to implement.

As college instructors seek to incorporate computer applications into their teaching and their students' learning processes, we will need to develop textbooks that are highly integrated computer/content area documents. In this sense, we will need to follow a collaboration/verification process that includes involvement on the part of more than just the traditional editor/publisher and the author(s). The larger number of collaborators results in a more complex collaboration that requires developing and following a collaboration flowchart as well as a style guide for the development of the text. Although both the flowchart and style guide can be revised, they are needed in order that the collaborators can understand and follow the collaboration, development, and testing processes. These collaboration tools also help collaborators to use a common vocabulary when discussing the process and the resulting text; in this way, a shared image of the text is more likely to evolve.

Because this text involved integrating computer instruction with writing instruction, it was a difficult collaborative task but one that we completed two weeks ahead of the deadline and with relatively few major disagreements. Factors that contributed to the success of the collaboration included the following:

• A common vision for the text and for collaboration
  In this collaboration, the authors and the product manager talked weekly about our understanding of the goals of the text, and the largest amount of discussion occurred during the initiation stages of the project. During these discussions we also worked to develop a similar understanding of what it means to collaborate. Researchers have found that such discussion is needed at the beginning stages of a complex project in order for the project to succeed (Ede and Lunsford, 1990; Kraut, Galegher, and Egido, 1988). A shared understanding of the development and production processes for this type of integrated text on the part of the project manager, authors, and production department members also made the collaborative process flow smoothly.
  
  
• Clear audience and purpose
  Researchers have found that lack of communication about the actual audiences for a document can be a major source of delay in a collaborative project (Cross, 1990). In this collaboration, the product manager made a concerted effort during the entire development process to communicate information about the audience and purpose of the text to all collaborators. He also repeatedly asked authors, reviewers, and other collaborators to state and restate their understanding of the audience and purpose for the text.
  
  
• Involvement by crucial collaborators
  As Grice (1991) has stated, the diffusion of technology demands "that technical information be verified as completely and thoroughly as possible before it is presented to users" (p. 224). In order to verify the information, and more importantly, in order to add perspective from an audience larger than a traditional review board, we had classroom students, quality assurance students, and reviewers all contribute as collaborators to the text. This large involvement resulted in their greater influence on the text and in a higher level of verification than normally results from more traditional approaches to textbook publishing.
  
  
• Computer technology
  Numerous computer systems have been developed to aid collaboration (for some recent examples, see the 1991 Proceedings of the Conference on Computer-Supported Cooperative Work). In our case, we found that using BITNET to collaborate had the effect of forcing us into an awkward interaction mode. Therefore, we found a simple computer program (MACKNOWLEDGE) that would allow us to send and receive multiple comments, drafts, and graphics and to respond quickly to the project manager and reviewer concerns. The computer technology allowed us to make needed revisions of the proposal and the text, and the technology helped us to meet our deadline.
  

To conclude, in order to collaborate on a complex text, such collaboration must be viewed by all collaborators as more than a production process in which sections of a text are passed from one collaborator to the next with little interest in the iterative development of the text. Instead, authors, production managers, editors, reviewers, desktop publishing personnel, graphic artists, copy editors, quality assurance personnel, students, and others involved in the making of the text need to understand the audience and purpose for the text as well as their role in the collaborative development of it. As we seek to integrate the teaching of technology into content area textbooks, we face a more complex collaborative process than that involved in the development of more traditional textbooks. How we approach this collaboration will in large part determine the quality of future textbooks in college composition.

Ann Hill Duin and Kathleen S. Gorak teach in the Rhetoric Department of the University of Minnesota.

Bakhtin, M., & Voloshinov, V. N. (1986). Marxism and the philosophy of language. (L. Matejka, & I. Titunik, Trans.). Cambridge, MA: Harvard University Press.

Barnes, L. L. (1989). Why is there a text in this class? Classroom teachers' (re)views of computer-assisted composition textbooks. Computers and Composition, 7(1), 27-36.

Bruffee, K. A. (1984). Collaborative learning and the 'Conversation of Mankind.' College English, 46(7), 635-652.

CTI style guide. (1990). Cambridge, MA: Course Technology, Inc.

Cross, G. (1990). A Bakhtinian exploration of factors affecting the collaborative writing of an executive letter of an annual report. Research in the Teaching of English, 24(2), 173-203.

Duin, A. H. (1990). Computer documentation--Centering on the learner. Journal of Computer-Based Instruction, 17, 73-78.

Duin, A. H., & Gorak, K. S. (1991). Writing with the macintosh: Using microsoft word. Cambridge, MA: Course Technology, Inc.

Farkas, D. K. (1991). Collaborative writing, software development, and the universe of collaborative activity. In M. M. Lay & W. M. Karis (Eds.), Collaborative writing in industry: Investigations in theory and practice (p. 13-30). Amityville, NY: Baywood Publishing Co.

Forman, J. (1987). Computer-mediated group writing in the workplace. Computers and Composition, 5(1), 19-30.

Grice, R. A. (1991). Verifying technical information: Issues in information-development collaboration. In M. M. Lay & W. M. Karis (Eds.), Collaborative writing in industry: Investigations in theory and practice (p. 224-241). Amityville, NY: Baywood Publishing Co.

Kantrov, I. (1991). Keeping promises and avoiding pitfalls: Where teaching needs to augment word processing. Computers and Composition, 8(2) 63-77.

Kraut, R. E., Galegher, J., & Egido, C. (1988). Relationships and tasks in scientific research collaboration. Human-Computer Interaction, 3, 31-58.

Lunsford, A., & Ede, L. (1990). Singular texts/plural authors: Perspectives on collaborative writing. Carbondale, IL: University of Southern Illinois Press.

MacKnowledge™ (1989). Tigard, OR: Prometheus Products, Inc.

Malone, E. L. (1991). Facilitating groups through selective participation: An example of collaboration from NASA. In M. M. Lay & W. M. Karis (Eds.), Collaborative writing in industry: Investigations in theory and practice (p. 109-120). Amityville, NY: Baywood Publishing Co.

O'Hara, F. M., Jr., (1988). Beyond word processing: Computers in the composition process. In R. Krull (Ed.), Word processing for technical writers. Amityville, NY: Baywood Publishing Co.

Olsen, L. (1989). Computer-based writing and communication: Some implications for technical communication activities. Journal of Technical Writing and Communication, 19(2), 97-118.

Perrin, R. (1988). What handbooks tell us about teaching writing with word-processing programs. Computers and Composition, 6, 15-26.

Proceedings of the Conference on Computer-Supported Cooperative Work. (1991). Baltimore, MD: Association of Computing Machinery.

van Pelt, W., & Gillam, A. (1991). Peer collaboration and the computer-assisted classroom: Bridging the gap between academia and the workplace. In M. M. Lay & W. M. Karis (Eds.), Collaborative writing in industry: Investigations in theory and practice (p. 170-206). Amityville, NY: Baywood Publishing Co.

Weiss, T. (1991). Bruffee, the Bakhtin circle, and the concept of collaboration. In M. M. Lay & W. M. Karis (Eds.), Collaborative writing in industry: Investigations in theory and practice (p. 31-48). Amityville, NY: Baywood Publishing Co.

Wheeler, W. (1988). Word processing for the technical writer: A case study. In R. Krull (Ed.), Word processing for technical writers. Amityville, NY: Baywood Publishing Co.

Winterowd, W. R. (1989). Composition textbooks: Publisher-author relationships. College Composition and Communication, 40, 139-151.