English teachers make remarkably good programmers. The reason for this talent should be clear to those who have persevered beyond the cryptic surface features of BASIC, LOGO, or Pascal to the heart of a computer program. Successful programming has less to do with mathematical formulae than with the fundamental skills of composition: programming calls for logical thinking, clear expression, and a working knowledge of the standard rules of syntax. Programmers develop ideas through written language, exploring and revising them in response to their effect on readers, both mechanical and human.
My own path to this discovery began with a mixture of curiosity and consternation. After years of teaching literature to first-year college students, I had become troubled by the number of students who were unable to write a formal literary analysis when asked to do so on their own. My approach had been traditional enough: we read a wide range of stories, plays, and novels and discussed them in class, focusing on the most important elements of fiction in each
text. All students were expected to select a work for individual study. As part of their analysis, students were to identify the setting, major characters, narrative point of view, chief features of the plot, important symbols and themes. This assignment was described in a handout, revised each year. I took great pains to specify each step in meticulous detail. Why, then, did so many students fail to get the message? Why did their work so often seem so incomplete, disorganized, and ill-informed?
One of the problems, I realized, was in the nature of the handout itself. Written instructions, however elaborate, are poor substitutes for an instructor. For inexperienced readers, words on the page are often merely words. We know that print lacks the gestures and inflections which help give emphasis, vitality, and meaning to spoken language. Nor does a handout respond to individual readers who may need more examples, definitions, or a judicious word of praise. With abundant time and personal attention in my office, these students could undoubtedly be guided through the conflicts of Antigone or the symbolic complexities of "The Metamorphosis," but left alone with only the assignment and the text, not enough could make the journey on their own.
Herein lay the appeal of programming. Although a computer is still no substitute for a human tutor, a computer program can represent a tutor's methods more adequately than can a printed handout. That's because a program is a set of procedures. It activates a process, a process that can be made to emulate dynamic features of a tutor's repertoire impossible to duplicate on the printed page. Like a teacher, a good tutorial program can pause for a response, analyze the response, infer the student's needs, and move on to the next step in the student's labyrinthine progress. A tutorial program can focus attention on one concept at a time, holding in reserve, as needed, those detailed explanations, illustrations, new ideas, and opportunities for practice which often confuse beginning readers of conventional texts. Through electronic sounds and moving images, computer programs can highlight key ideas and demonstrate certain operations where printed texts can only be silent and inert. For reluctant readers, the screen is often more engaging than the page.
Of course, the quality of engagement depends largely on the programmer. When the programmer is also the teacher, certain
benefits accrue. These benefits became clear to me when I began to transfer a conventional literature assignment to a computer program. I called the program, after considerable hesitation, STORY TUTOR. My students knew that I had written the program specifically for them, and they could see its relevance to our work in class; this fact may be one reason for their willingness to follow through. Most students said they spent more time at the computer than they would have given the assignment if it were merely written down. Their work was correspondingly more complete and carefully thought out. They considered all the major issues of analysis because the computer guided their progress. They wrote extensively because the program called for written responses at each point. Although a few complained that the program took too long, the majority wrote appreciative evaluations. The most inexperienced readers especially liked the chance to work at their own pace, writing and revising their way through what they perceived to be an orderly analysis of their chosen literary text. As one student said, "It was like having the teacher there with you at every step of the way."
When the programmer is a teacher trying to decide what students need to know and how they're likely to respond at each stage of the learning process, something more than a computer program takes shape. The computer becomes a medium of exchange, an instrument for testing the transaction between learner and instructor. By permitting teachers to gauge a student's understanding while watching his or her performance at the keyboard, the program provides a kind of window to the student's mind. By reflecting the failures and successes of specific techniques, as measured by the student's response to each screen, the tutorial program also becomes a kind of mirror of the teacher's methods. So programming can be a tool for evaluating and refining pedagogical assumptions.
Not every tool is worth its price for everyone. Some tools require more time to master than the jobs to which they're likely to be put. Programming may well seem like one of these tools to many teachers. It is certainly quicker to type a handout than produce a comparable program, even if you're fluent in a programming language. For those teachers who may be weighing the benefits and risks of designing their own programs, I want to highlight four areas where I have found programming to be unlike any other
teaching tool: lesson planning, student response, individualized instruction, and collaborative learning.
Rewriting my assignment as an interactive program forced me to reexamine my objectives. Exactly what did I want my students to learn? More specifically, what did I want them to accomplish with what they learned? Good computer programs stress reader response, so I had to clarify just what each student should be doing at each point in the lesson. Moreover, since screen size is limited, I had to pare down sprawling explanations. The 24-line screen enforces a kind of pedagogical economy, as many teacher/programmers have noted. The limitations of the computer screen also highlight certain student needs related to the display. At every stage, I found myself thinking about the header "Where are we in this lesson?", the text "What is absolutely essential to say to the student at this point?", prompts "What student responses are called for here?", and branching options "What should follow each response?".
It seemed logical to follow the same sequence that I used in my handout: a section on setting, one on characterization, another on point of view, and so on. When I watched my students at the keyboard, though I soon discovered that their progress through these sections was not strictly sequential. They would choose a character to analyze, then change their minds in medias res. Or a question on symbolism would give them new ideas about the setting. The program needed flexibility, a way to make the process of analysis recursive as well as orderly. So my sequential approach gave way to a menu of options. Now students were able to investigate the tool story's setting, characters, symbolism, or point of view in any order. For further flexibility, I added the option of moving backward as well as forward through each section. In this way, I discovered for myself why menus and backpaging have become standard features of educational software.
The sequence of my program needed to be reworked for yet another reason: the interrelatedness of certain elements of fiction. Although it is true that setting often shapes character, characters may also influence their environment. The plot may be dependent on the setting, but the reverse is some-times true. Any program that
guides a student through these possibilities should reflect the way one element may build on another. In fact, computer programming allows for this interdependence quite well. What a student writes about the setting early on can be recalled during a later section on plot, and a discussion on plot may branch back for a reconsideration of the setting. All this related activity requires careful planning, of course, and a willingness to keep tinkering with the plan, but it can lead both teachers and students to a better understanding of literary analysis. The computer program becomes a working model of the analytic process, to be revised and refined as this process becomes more clearly understood.
Programmers call it feedback: the way a system is strengthened when the responses to certain factors help to modify those factors. When the system reflects your teaching, as it does in a homemade program, it pays to monitor the responses of your students closely. In effect, the computer becomes an instrument for measuring reader response.
When I write a letter or an essay, I imagine my readers. I try to anticipate their questions, curiosity, laughter, lapses of interest; rarely do I have a chance to watch them as they read. But when I write a screenful of text for the computer, I know that I will get to see my audience responding to it soon. If students smirk at some cute phrasing or turn to ask about a puzzling term, I'm likely to revise the text and test the new version with another set of readers. The illuminated screen becomes a textual proving ground, especially handy for pointing out linguistic rough spots. At first, I used to caution students not to touch the screen, but watching them develop an almost physical intimacy with the electronic text, I realized that this relationship ought not to be discouraged. Even when my students keep their fingers on the keyboard, I can measure their speed, note their pauses, observe the options they select. As they compose their thoughts, the computer helps to make visible their thinking. I can monitor their learning and composing as never before.
Of course, I'm not just a passive presence. My students come to regard me as a kind of veteran flyer in the co-pilot's seat. As they
learn to handle the controls, we discuss their strategies and work through patches of linguistic turbulence. What I like most is the way this model--the computer as flight simulator--lets me offer help during the process of analysis instead of after the fact. Tutorial intervention comes into play when it's most effective. At the same time, my role as a programmer is to eliminate such intervention. One eye is always looking for those problems and solutions which can be built into the program so that my presence will become unnecessary. The ultimate aim is the student's solo flight.
Some changes in my program have been technical. Early on, my students felt the need for a large writing area. Most programming languages impose a 255 letter limit on input typed by the user. I expanded this to 40 lines. Then, as my students used this writing space to try out and revise their thoughts, they wanted to move more freely within the space to add and erase text. So I found myself trying to include some basic features of word processing. Now they can erase mistakes, scroll through their texts, and let a word-wrap feature automatically prevent split words at the end of lines. When I saw students copying definitions from the screen, I added printout capabilities; now they can make copies automatically on the printer. When I saw their exasperation at the school buzzer, announcing the beginning of another class, I added saving features. Now, in addition to a printed running record of their progress, students can save their work on their own diskettes and continue at a later time. Their texts are saved as textfiles, which means that they can also be retrieved with any standard word-processing software and reworked into essay form. None of these ideas is entirely new, of course. The point is that they were incorporated into an evolving program in response to feedback from the students.
Many of the changes have been more obviously pedagogical. How do you set the proper tutorial tone? Initially, my authorial voice was a shade too whimsical. Alone at my desk, I was in a playful mood, and my prose reflected this. But when I watched some ESL students struggling to take my lighthearted explanations seriously, I realized that cuteness can be a risky substitute for clarity. What about the problem of depth? When you introduce a concept for the first time, how faithful can you be to its complexity without losing your reader? Again, the computer let me test the limits of complexity through its emphasis on feedback. If my students
looked confused or responded inappropriately to the screen, I knew that my approach needed more work. Moreover, programming provides a built-in solution in the form of branching. If an explanation seems too complex--or too simple for an individual student, he or she can be given the option of branching to another level.
The concept of branching leads to the notion of individualized instruction. Let's say you're discussing characterization in Fitzgerald's story, "The Jelly Bean." Your student, unfamiliar with the notion of character development, doesn't know where to begin. So you ask her to identify a major character. She chooses Nancy Lamar. You ask her what she thinks of Nancy. "Not much," she says. You press for some reasons. "Nancy is a show-off. She thinks she's hot stuff." You ask for evidence, and your student gives you instances of how Nancy acts and what she says. You may decide to take the inquiry further. What do other characters think of Nancy? How does Nancy see herself? Where does the narrator express his point of view? How unbelievable is Nancy as a human being? Eventually, these questions should lead to a fairly full analysis of Nancy's character and how it is developed. A more experienced reader might have produced a complete analysis on her own, but students who don't know what questions to ask themselves often need a patient tutor. A program, like a tutor, can break a large task into smaller ones through the if/then flow of computer logic. If a student indicates the need for more help, by pressing a help key or pausing too long for a response or typing an inadequately short answer, the program can branch to a series of simpler explanations. If the student asks for illustrations or another round of practice, the program can branch accordingly. For the programmer, keeping track of proliferating branches can mean a lot of work. But for the teacher- programmer, it is also a way to sharpen teaching skills by making tutorial questions more explicit and orderly.
What makes this approach particularly challenging is the generic nature of these questions when a program must be general enough to handle different stories. It is one thing to ask students about the symbolism of "The Metamorphosis," quite another to ask specific
questions that can apply to any work of fiction. Programmers deal with this open-endedness by using variables. The student's story may be one variable, her choice of a main character may be another, her selected symbol a third, the setting a fourth. For the programmer, this branching can lead to some very abstract thinking (What does B think of C in D?"), but for the student, it allows the lesson to be quite specific ("What does Gregor's boss think of the insect in the Samsa household?"). Limiting the variables to significant units and anticipating how they will appear in new contexts is only part of the challenge. But it has much to do with understanding the nature of two important variables of teaching English: language and the individual student's thought.
Along with this capacity to address individual differences, the computer encourages collaborative forms of learning. The earliest fears about computer-aided education often conjured up images of students pecking at terminals like laboratory animals. The surprise for many teachers has been that, far from dehumanizing learning, computers have become catalysts for social interaction. The screen display invites public attention in ways that paper never does. And the natural need for technical knowledge often provides a pretext for requesting other kinds of information. One student may ask another which key to press, and soon they're talking about the setting of a story. When I noticed this happening again and again, I tried to encourage more collaborative writing by assigning two students to a computer. Not only does this increase computer use, but it also gets students to defend their choices and consider other points of view. They begin to think about their thinking. They use language to articulate their use of language. Such metacognitive activity among peers more than compensates for the mechanistic nature of computer programs.
Although I planned no formal evaluation of STORY TUTOR, student questionnaires, dose observations of the students at work, and the completed assignments do give some measure of the program's effectiveness. A few results are immediate. For example, every student quickly learns the convention for short-story titles. This learning occurs because of a subroutine that checks the beginning
and end of every title. If students type a title without quotation marks, a bell rings and a prompt reminds them of the rule. I rarely need to circle unacknowledged titles after STORY TUTOR does its work.
The real payoff, though, is in the quality of critical thought fostered by sustained, focused attention. My students' willingness to spend so much time with the assignment--more than many had ever given to an assignment of this kind--may reflect to some degree their positive interest in a new technology. They regard STORY TUTOR as an opportunity for hands-on experience with computers. To a greater degree, I attribute the completeness of their work to the nature of the program and the computer itself. Parts of the analysis which students often missed while following my handout--the story's symbolism, for example, or point of view--were never ignored when they worked with the computer version. Perhaps this situation occurs because the program guides each student through each step. Perhaps, too, their attentiveness owes something to that sense of interaction stimulated by computers. After each screenful of text, users must make a choice: type something, rewrite it, save it on the diskette, print it out, go back, move on. As they write, the blinking cursor beckons them to continue. The program seems to remember students' decisions, and the printer keeps a running record of their accumulating text. They know that if they follow the program's line of inquiry, they will eventually have the makings of a full analysis. More than one student has joked appreciatively about the computer's inhuman patience. The computer seems to say, "Proceed at your own pace; repeat as often as you like. There's no need to feel embarrassed. I'm only a machine."
I don't believe that the value of STORY TUTOR lies in any special features of my program. Rather, it seems to grow out of the medium itself. The possibilities for more dynamic, interactive modes of learning are available to all educators willing to refashion their teaching in a different key.
What do teachers need to create their own computer programs? Lots of time, certainly, and determination. I estimate that I have spent some 80 hours developing STORY TUTOR so far. This estimate
includes time to work out my objectives, write tentative subroutines, key them in, debug them, test them with colleagues and students, revise them, integrate them into a structured program, and tinker without end. As recently as yesterday, I revamped the section on theme. My students were having trouble seeing how their understanding of the theme evolves from perceptions of a story's plot, setting, symbolism, and so on. I wanted the computer to remind of them what they had written about these elements of fiction, so they could make connections more easily. I added a subroutine that lets individuals call up earlier texts from a menu. Now, before writing about the story's theme, they can see how previous answers may have thematic relevance. Time required to design, add, and test this subroutine: five more hours.
A program can take less time if you team up with a knowledgeable programmer, student, or colleague who can make the computer follow your designs. I taught myself programming because I wanted to understand exactly what computers can do and how they do it. As a result, my teaching ideas are guided by my expectations of technology, and my technical knowledge often leads to pedagogical solutions. It took a while, though, to find the right programming language for my needs. At first, SuperPILOT seemed like an attractive choice. Like other "authoring languages," SuperPILOT has built-in routines for handling text, graphics, and sounds. This feature lets you concentrate on the content of a lesson without worrying about low-level technical details. But SuperPILOT limits each student's response to a few sentences at best, and I wanted my students to write extensively. I turned next to Pascal because it gave me more control. Pascal is widely used as a highly structured language. That is, Pascal enforces clarity of design and logical coherence, somewhat like a writer's outline. But while this characteristic is good for "top-down" programming, where the designer already knows what the program should do, it was ill suited for my approach. What I needed was a language that allowed me to experiment, to test ideas quickly and independently before combining them to build a program from the bottom up. My final choice was BASIC. The basics of BASIC are relatively easy to learn and put to use. I found that as my needs grew more demanding, I could learn its more sophisticated features and even add subroutines in assembly language for special tricks and extra speed.
Whether you do your own programming or get technical assistance, the process of adapting an educational process to the language of computers is affected by an inevitable fact: computers are machines. Machines tend to be mechanistic, and no matter how cleverly you disguise the fact, the fundamental yes-or-no logic of computer circuitry keeps tugging at the complex ambiguities on which the teaching of language and literature is based. Related to this problem is the fact that people tend to give computers more credit than they deserve. Many of my students assume at first that the computer knows all about the story they have chosen, so when they misspell the title of "Previous Condition" or mistakenly identify the point of view as omniscient, they believe they have been given tacit approval. A few students even think that the computer can somehow read what they write. Anthropomorphism is strong in the computer lab.
Of course, it would be possible to add a database of facts about familiar stories so that the program could respond with more specific information. At this stage, however, I've limited my task to asking generic questions. This approach entails treating many of the student's answers as variables which will be meaningful in other questions. "Where does X take place?" "What is most important about Y?" "What abstract ideas do you associate with S?" "What concrete facts did you learn about S from reading Z?" Each letter stands for what the student may have typed in response to an earlier question. The letter is a variable which the computer replaces with a specific title, character, or setting. One trick is to restrict some of the user's responses with CLOZE-like sentences. Instead of "Describe the setting of X," I've learned to say "X takes place in...." This assures some syntactical coherence later on when the student's answer appears in another context: "Since X is set in Y...."
Clearly, STORY TUTOR is an unfinished work, subject to continuous revision like any manuscript. Maybe more so. Having written programs of my own, I now understand why computer software goes through more editions (versions) than most printed matter. As a writer, I feel a strong sense of closure when my book or article is printed and bound. I may pore over some reviews, get a few irate or grateful letters, and talk about it with readers now and then, but the text remains fixed. In contrast, my programs are always in the making. The computer's interactive nature, the opportunities to see
users responding to my words and subroutines, the suitability of computer texts and program design, the ease of change--all these observations encourage me to think of every program as a work in progress.
Although STORY TUTOR was designed for local use, I'm interested in learning how students might respond to it in other settings. Readers of Computers & Composition who would like a copy are invited to send a blank diskette to
STORY TUTOR runs on the Apple IIe. Please include a stamped, self-addressed mailer. I particularly welcome suggestions from teachers who approach the same problems of teaching literature in different ways. If there is enough interest, I'd like to redesign the program so that English teachers without programming knowledge may tailor it to local needs. Teachers would be able to change the menu, screen displays, terminology, definitions, and examples while retaining the subroutines which enable students to write extended answers, revise them, print them out, and rework what they have written using a standard word- processing package.
My purpose in this article has not been to describe a particular computer program so much as to explain what can happen when an English teacher tries to create one. I would like to hear from other teachers whose ventures into programming have run along similar or diverging tracks. Although this article is fixed in print, the ideas on which it's based are not.