Scott P. Sanders
We are all familiar with the great promise of more effective instruction that the use of computers in the writing classroom offers. Nowhere would this promise seem more likely to be fulfilled than in the technical writing classroom. Many technical writing students have used computers in their academic work before they take technical writing. Such students readily accept that when they write, either now in school or later on the job, they should do their work with word-processing packages on computers instead of typewriters or pen and paper. Their acceptance of the computer as a professional tool helps the less experienced, more computer-phobic students work through the rough spots. Also, this attitude helps all students see that their classroom work is immediately relevant to the professional world they expect to enter upon graduation.
But even with these advantages, careful planning is necessary to make computers and word processors a positive part of the technical writing course. The marriage of the word processing on
computers and the technical writing course may seem to have been created in heaven; but, as we found out, it takes much work, more persistence, and still more understanding to make the marriage a happy one. In this article, we describe what happened--good and bad--when we introduced word processing on computers into the sophomore-level, service course in technical writing, a course offered by the English Department at the University of New Mexico (UNM). To complicate the plot further, we taught our separate sections of this multiple section course together, somewhat, making what follows the chronicle of a double marriage: our professional liaison as team teachers of technical writing and the curricular wedding of word processing on computers with technical writing.
We had so much in common. In October we both received Zenith micros (an IBM-compatible, MS-DOS machine) and assorted software packages from the university--the same hardware and software available in the computer classroom where we would each teach a section of introductory technical writing in the spring semester. One of us would teach at 8:00 a.m., the other at 10:00 a.m. We were both on MWF schedules; our offices were next door to each other; we both had taught advanced writing courses before, and we would come up for tenure in the same year, an event still comfortably far off in the future.
We complemented each other so well. Chris was new to the technical writing course and to UNM; Scott had taught technical writing for several years, and, as Director of the Professional Writing Program, was in his second year at UNM. Scott had never used an IBM or compatible (he owned a Macintosh and had used DEC mainframe and micro-equipment on summer writing jobs) and had never taught with computers; Chris had used IBMs and compatibles for several years and had trained writing teachers to use computers in the St. Louis Gateway Writing Project.
Combining our similar goals with our complementary strengths and weaknesses, we looked forward to team planning the first technical writing courses to be taught at UNM using computers in the classroom. We hoped to feed the demand for more micros on
campus; specifically, we wanted a pod of computers in the humanities building and eventually perhaps a desktop publishing lab for the professional writing program. In short, we seemed the perfect couple.
In planning our pedagogical nuptials, we had to adapt to the special demands of our computer classroom and to the protocol observed by the UNM Computing Center. Together we visited our future home, a small classroom with twelve computers facing the front, sitting on the Physical Plant's best unfinished plywood and two-by-four benches.
We ingratiated ourselves with the landlady, a department secretary who controlled the keys to the hardware and software. Then we paid our respects to the instructional computing supervisor, the pod-boss of the Computing Center. He assured us that the other two computer classrooms and the three public pods had identical hardware and software that would allow our students easy access for their out-of class work.
Finally, we arranged for responsible family planning by visiting the registrar and limiting enrollment. We wanted our family limited to, but not significantly less than, twenty-four students-- two per computer. After calculating the usual attrition rate for the first week, we asked the registrar to limit enrollment to twenty-seven. With these arrangements completed, our house was ready to become a home.
We wrote our syllabi together, planning assignments through the midterm. Because we wanted across-class feedback that would mimic writing for professional audiences, each of us gave up some favorite assignments for jointly written assignments, assignments that we both felt comfortable teaching. We hoped that some students in Chris' class might respond to Requests For Proposals (RFPs) that Scott's students wrote (or vice versa) and that the
ensuing proposals and reports would then shuttle in various drafts between the classes and students before finally landing on our desks to be graded.
We also planned to make an end-of-the-term database of papers from both classes that subsequent classes could use as models. These plans meant that all students would have to learn the campus standard word processor so they could trade disks and review each other's papers on the screen. Requiring everyone to learn the same software would also mimic corporate settings where all employees, regardless of previous word-processing experience or preference, must use the standard company software. If students wanted to use another computer for word processing elsewhere, they would have to convert their files for in-class use. (The campus word processor compresses files, but it contains a utility program for converting files to and from ASCII.)
Here was cur principal innovation: we designed our sequence of major writing assignments so that we could teach word processing as we taught technical writing. We adapted the Computing Center's dittoed, quick-reference documentation to make a four-page, "minimal documentation" handout that presented only enough information to get the students through the first day and help them print the first assignment--a "get acquainted resume." Chris set up a basic resume template, an electronic file with headings designating the usual resume sections, into which students could insert their personal information.
Working with the resume template would teach a few basic DOS commands ("Dir, "Copy," and "Del") for file management and a few basic functions of the word processor, such as entering and deleting text, saving a file to the disk, and using the print menu. The "get acquainted resume" would be accompanied by a letter of introduction that would introduce the students to us. The letter would teach business-letter format, word wrap, and paragraphing.
We hoped that printing and circulating this two-assignment package would demonstrate the power of the word-processing software for making the revision process physically easier and for helping students produce neater, more professional final copies than they might otherwise have done. The two-assignment package would also prepare students for the next assignment: a job-application package (a professional rather than personal resume and letter)
that would require centering, underlining, boldface, and more advanced editing features.
For this assignment, we would explain to students individually how to perform the new computer functions as they discovered which functions could improve their documents. Thus, students would increase their computer competence in the context of satisfying their needs to use the new skills in their writing. With these assignments, we hoped to tie the development of students' computer and writing competencies together, so that the tangible development of computer skills would help increase our students' confidence and competence as writers.
After the get-acquainted assignment and with the power of the computer fresh in their memories, students would begin the next series of assignments that would take them to the mid term: writing RFPs to other students (they could not respond to their own RFPs) for short reports that documented whatever feature of DOS or of the word-processing software (such as file comparison, diskcopy, spell checking, file conversion) about which they wanted to know additional information.
In effect, students would document the computer and the word-processing program for each other. In so doing, they would develop their writing and computer competencies within a realistic technical-writing context presenting practical information in a clearly written, persuasive, and easy-to-use format for a real audience with a real need to use that information.
The night before classes began, we were hopeful. We felt our syllabus was a good piece of match-making, marrying without discord our perfectly matched couple in this double wedding: computers and technical writing. How could our own pedagogical marriage possibly go awry? We'd planned carefully, adapted to our new space and to each other, and generally agreed on our goals. Over pretzels and beer at a mutual friend's bachelor party, we smugly toasted our union.
And it was wonderful. The first-day lesson plan helped every student boot the word processor, retrieve the resume template,
insert personal information, save the resume to a disk, and print a hardcopy before the class ended. We felt we had won over even those students who were surprised to learn the class would be taught on word processors.
But problems remained. Because we had only twelve computers for twenty-four students, we planned simultaneous, in-class activities so that half of the class could work with the computers while the other half worked with partners in a separate group. But the classroom's immovable benches didn't allow enough room for small groups to work comfortably on the same project. By the end of the week we had arranged for occasional use of a nearby terminal room for the groups to meet and confer. However, this solution only worked as long as some of the students were not using the terminals. Our students legitimately complained. Our computer home was too crowded.
Students also complained about having only twenty minutes per class on the computers. Students often failed to complete final copies in time for the review process. So we provided schedules and equipment inventories to the other pods, assured students that the hardware and software were identical, and encouraged them to work outside class. Then we learned that the classroom was vacant in the hour between our class periods. We reserved it, and, with one of us either staying late or arriving early, we staffed it for students who wanted to work on assignments. The students realized that the crunch was an inevitable consequence of having only twelve computers in the classroom, and though they appreciated our help, they still mumbled about limited access.
And more troublesome complaints began to surface about some of our (we thought) good decisions. For example, to provide audiences for both classes, we made assignments due in time for the 8:00 a.m. class. Students in the 10:00 a.m. class resented showing up two hours early to submit their RFPs, proposals, and final reports. Worse, students using home or work computers resented learning the campus word-processing software because they had to convert
ASCII files. Students using systems that were incompatible with IBM were angrier still.
One student complained that he had to learn the basics of telecommunications software before he could work on his company mainframe and that he had to download to a micro before he could even begin converting his file. After two weeks, these students were "forgetting" to bring their work disks to class and often failed to bring hardcopies of their drafts. By "forgetting," these students gave additional computer time to the other students; however, they could not participate in peer reviews. Class time became boring for them, and our justifications for requiring everyone to use the same software never made sense to them.
Our computer home was crowded and the children were restless. We also had trouble with the neighborhood. The campus pod-boss had provided us with lab times and equipment inventories and had assured us that access was "no problem." We mistakenly believed him. One of the five pods (one of two open twenty-four hours a day) was open to engineering students only. Since engineers crunch numbers, that pod did not stock the campus word-processing software.
Another pod, scheduled to stay open until 9:00 p.m., would close at 7:30 p.m. if no one showed up, so students could not count on it at night. All the pods had sufficient hardware, but they stocked, at most, four copies of the word-processing program. Our students might immediately find open machines and then have to wait half an hour or more for software. It took us two weeks to realize that we could boot the software and then enter and edit text without the disk--only printing required that the disk be in the machine.
And we adapted to our students' complaints, but our tempers were showing, and matters only got worse. Scott complained about the lack of word processors in the engineering pod, and the podboss responded by promising to stock the pod with the latest version (4.0) in two weeks. Then Chris tried to compensate for limited software access in the pods by teaching some advanced
word-processing features in the classroom, only to find that his version (3.5) was more recent than the classroom version (3.0) and that some of the screen displays differed. More, not less, confusion ensued.
One morning, Scott's class began adding text to existing files and found that a previous class had reset the margin defaults in the classroom software. When Chris took over the lab at 10:00 a.m., Scott was grumbling over "those damn ruler lines." But Chris could not listen because his students had queued up to beg for two-hour extensions on their proposals, due for the next class. He insisted that his students submit their proposals by 8:00 a.m. so that both classes could stay on the same schedule, which made neither class and neither professor happy. Even the podboss' call failed to help the situation. He called with the good news that the promised word-processing software, the latest version, 4.0--was now installed in all the pods.
Students in both classes were to bring multiple copies of their proposals to the classroom by 8.00 a.m. where Scott's class, working in evaluation teams, would review them and accept or reject the proposals from both classes that were addressed to them. But by 9:10 a.m., before Chris could get to the classroom, Scott was standing in the doorway of his office.
"That's it!" said Scott. "1'm tired of surprises! My students are going to write their own &$#@! RFPs and their own &$#@! proposals, and we're not trading with anybody!"
The proposal submission had turned into a zoo. Stuck with an inflexible deadline, students had swarmed angrily to the pods the night before and been overjoyed to find additional copies of the word-processing software, though not quite enough to supply each with a disk. Disk swapping and logging off and on to take breaks had thrown them into chaos. Finally, what had seemed to be a blessing became a curse: neither version 3.0 nor 3.5 was convertible to and from 4.0. Once opened with 4.0, a file could never again be opened by the earlier versions. The older versions reported a terse
"File Not Found" when asked to open files saved while using the newest version. "It's not there!" one student was reported to have screamed." The &$#@! computer ate my &$#@! proposal!"
The harried pod consultant realized the incompatibility of the versions only after students had stomped out of the pods grumbling that after they strangled their technical-writing professor, they would never touch a computer again. So when Scott greeted the combined classes with a cheerful "Good morning. I trust you all have your proposals ready," our kids, some of whom were up two hours early to meet an 8.00 a.m. deadline for their 10:00 a.m. class, others not having gone to sleep at all, let him have it.
"I've had it!" he shouted now at Chris, slamming the door to his office and locking it behind him. We separated the next day.
The divorce was amicable. Class custody was not contested. But we still had to live with that other married couple, the computers and technical writing. What to do? Scott allowed his students to choose, individually, either to continue with the campus word-processing software; learn PC-WRITE, a shareware product that could be given directly to the students; or write their papers without using computers. Chris required his class--all but those already using other programs--to switch to PC-WRITE. That lowered demand for the campus word-processing software, and most of Scott's class finished the semester with it. Scott switched to PC-WRITE the next semester and has used it successfully for two semesters now. Chris hasn't taught technical writing since.
In analyzing our experience, we've identified three ways that our naive optimism contributed to the failure of our relationship. First, we took the pod-boss' word about the availability of the pods without checking out the pods ourselves. We should have checked
the hours of pod operation, the number of available programs, and the compatibility of the version numbers, just as carefully as we had toured the computer classroom ourselves and adapted our plans to account for its limitations.
As classroom instructors, we should have anticipated problems that the computing center supervisor could not imagine. Had we discovered that the word-processor version (3.5) we were issued for use in our offices differed from the versions (first 3.0 and later 4.0) available in the public access pods and in the classroom, we would not have been surprised by the different screen displays. We could have anticipated the incompatibility of version 4.0 with the earlier versions. We could have warned our students before 4.0 entered the pods.
We were also naive to assume that our mutual interests, professional similarities, and complementary qualities could compensate for our pedagogical differences. One of us is more process oriented and takes two weeks to introduce, generate ideas for, draft, respond to, and peer edit an assignment that the other instructor routinely deals with in one week. We did modify our assignments and the pacing of our presentation of material somewhat, but perhaps some residual resentment made us less happy to deal with each other, given the logistical headaches neither had dealt with before.
Finally, and probably most importantly, we failed to make enough time for each other either for detailed day-to-day planning or for venting our frequent frustrations. Chris routinely conferred with students MWF when Scott had office hours and time to debrief the day's classroom events. Scott wrote at home on Tuesdays, Chris on Thursdays. And initial successes during the honeymoon season led us to neglect the specific, reserved planning time we'd agreed to before the semester started. When difficulties began to arise, we spent time quieting the kids, and we neglected our own relationship until it was too late.
But the experience was not a total loss. We neglected to make the database of student papers we had planned, but students did submit their final papers in hardcopy and on disk. If we find the time and patience to convert the papers to ASCII, we may yet have our electronic database of model documents.
Although the students were frequently frustrated, their course evaluation responses showed that all who finished the class enjoyed it and were very pleased to have learned word processing as well as
technical writing. However, many did recommend that in the future, we should teach only word processing during the first two weeks of class or teach it in a separate course.
Following up on some of the students' suggestions, Scott has since refined our computer/technical writing syllabus as he has taught one computerized section of technical writing in each of the last two semesters. Scott uses PC-WRITE so that each student has an individual copy of the word-processing software and the first eight weeks of the term remain essentially as we team-taught them. The get-acquainted and professional resumes and letters teach the basics of the computer and the word processing software. Students then document the finer points for each other in reports due at the midterm. After midterm, they may continue to use the campus computers and PC-WRITE, or they may complete their assignments however they choose, just as they would in any other technical writing section. Not too surprisingly, most students elect to use the computer for the entire term.
Last semester, two computer-experienced teaching assistants taught computer-assisted technical-writing sections using our evolved syllabus as a guide. For now and the next several years, we expect to teach three of our six sections of technical writing in the computer-equipped classroom. Finally, although we haven't discussed it formally, after writing this article together, we might team-plan or team-teach computer technical writing again.
If asked for advice on team-planning a computer-aided technical-writing class, we would say choose to become teaching partners because of your compatible philosophies rather than because of your compatible hardware, software, or other such more obvious similarities. Most importantly, make time for each other before, during, and after your professional marriage. You can expect hard times, but you can avoid divorce, however
amicable. And whether you team plan or not, checkout personally every detail of every thing you can think of about the classroom, the campus computer resources, and certainly, certainly, about the software.