Kim Hayworth & Warren B. Roby
May 1, 1993

Software development is no longer the exclusive domain of professional programmers. Authoring tools such as HyperCard and ToolBook allow computer enthusiasts to create their own programs without investing hundreds of hours learning the intricacies of arcane codes. A large proportion of the amateurs are educators who are taking advantage of these new tools to develop their own courseware. Many are working independently on projects for their own use; they conceive of their work as a part of what they now normally do in preparing their own teaching materials. Some eventually show the fruits of their labors to interested colleagues. The most confident post their projects on bulletin boards as shareware.

Foreign Language teachers are well-represented in the ranks of these do-it-yourselfers, and not surprisingly so: “. . . language teachers as a body have been more ready than most to accept and explore the pedagogical potential of new technologies as they have emerged” (Last 15). Moreover, the suitability of the computer for language instruction was recognized by pioneers of mainframe CAI such as Patrick Suppes and R.C. Atkinson at Stanford (who were not language educators), and French software was an early component of the PLATO system at the University of Illinois. Thus, there is good reason to believe that computers and “homegrown” software will be a part of foreign language instruction for good (pun intended).

This paper will first of all provide justifications for courseware development in the language laboratory/language learning resource center. It will then discuss personnel issues and conclude by briefly describing the development process. Much of the discussion will be illustrated by examples from the authors’ experience.

The bottom line in the education business is learning. All that we educators do should work, directly or indirectly, toward assuring that our students acquire new knowledge and skills. Thus, the first and foremost reason to develop software is pedagogical. (The reader is asked to keep these seemingly truistic statements in mind when later a number of secondary motivations for software development are given.)

The authors were initially prompted to create courseware for a very mundane reason: to supplement a first and second semester French textbook which did not have accompanying software. This will be a less likely motivation in the future because software will undoubtedly be a standard component in all textbook packages –– at least of the most commonly-taught languages. Until then, it is advisable to fill in this gap so that language A does not compare unfavorably with languages B, C, and D in students’ minds just because there are no programs to use to learn A. Moreover, it may be that there will never be many programs available in the less widely-taught languages, so instructors may have no choice but to compose their own.

Another pedagogical reason for developing courseware is that it is proven that students can learn well from computers (Kulik and Kulik 279) and often prefer the computer as an information delivery medium over paper (Kinzie and Sullivan 12). It has been speculated that students are engaged by the flickering screen of the computer much as people are entranced by a hearth fire. This engagement, called continuing motivation, (Maehr 443) results in task persistence. But students are not the only ones who can learn from courseware: we submit that the instructors/ developers learn much in the process. All experienced teachers have experienced the truth of the following: “I explained it to the student, but the student didn’t understand it. So I explained it to the student again, but the student still didn’t understand it. So I explained it to the student again . . . and then I understood it.” This flash of insight is facilitated by programming procedures. How? To answer this we may first of all consider classroom lesson preparation. It entails a series of conscious decisions: what to teach, in what sequence, and how. Programming pedagogical software involves the same issues, but the results are more overt. That is, the decisions which are made get embodied into the program for all to see, whereas the classroom delivery of them normally takes place “behind closed doors” and is ephemeral.

Now that the ostensive reasons for software development have been listed, it is time to give some ulterior motives. There are economic and political reasons for creating courseware. The financial justification is simple: commercial software costs. To this it can be objected that the “homegrown” variety also costs in the form of salaries and wages. This is granted, but these costs can be minimized by limiting the amount of faculty time spent on the project. Most of the work can be done by less-expensive graduate students and by even “cheaper” undergraduates.

The personnel scenario will be described in greater detail below. At this juncture another human factor bears mentioning. A major reason to develop one’s own courseware is simply to prove that it can be done. We have collegial relations in mind. Many in the Humanities are technophobes who cannot imagine that anyone other than a degreed computer scientist can program. This irrational fear is often coupled with a skepticism of CALL. These faculty assume that courseware is produced by “computer jocks” who know little about language or pedagogy. When it can be shown that bona fide language professionals who are not technical whizzes can create programs, then the skepticism can turn to enthusiasm.

It can not be overemphasized that good will on the part of confreres is essential. Some faculty view the inescapably high cost of computer hardware as only slightly more justifiable than huge expenditures for athletic programs. This is particularly the case in stringent budgetary periods such as many institutions are now facing. We in CALL view technology outlays as investment; many of our brethren wonder why the money is not spent on salary increases, more generous travel allowances, library acquisitions, etc. When major monies are appropriated for equipment, those of us who are responsible for its acquisition are held accountable for its effective use. To prove that our “consumption” of large amounts of the institutions’s resources is justifiable, we must produce something. We submit that good courseware is the best product imaginable.

We have touched on some of the human elements connected with courseware development. No matter how prominent machinery seems to loom in CALL discussions, it must be remembered that it is people who produce programs and people who use them. We believe that the entire continuum of persons in the university must be involved. We begin the discussion with faculty; not because they are the most important (for they are not), but because they normally provide the initiative in development endeavors. They are charged with communicating their knowledge of a field, they presumably have their students’ best interests at heart, they perceive a gap in their syllabus which needs filling, they know that students can only get so much out of regular class sessions, they can imagine the potential of a new piece of software. They turn to technology to help them do their job better.

Yet as noted above, not all faculty see the possibilities of technology; some are even wary of it. It is here that leadership on the part of the technologically-literate instructors is essential. They must resist the temptation to dismiss reluctant colleagues as “old fogies.” Rather, faculty expertise is a great resource which must be harnessed to guarantee the success of the products. Gentle elicitation is in order. We recommend starting projects and then inviting comments on specific aspects. This gradual approach does not take up much faculty time. It must be admitted that at present there is no guarantee that CAI projects will be rewarded in tenure and promotion considerations in many institutions.

In universities with graduate programs, we advise relying on graduate students to do most of the work. Their time is less expensive and they can easily be rewarded for their work. They can create programs as class assignments for a grade. In some cases they can be reassigned from their standard duties of teaching and grading. Undergraduates are the ideal “guinea pigs.” Not only are they easy to recruit from classes, but they are most likely the audience for whom the courseware is being created anyway. We were fortunate to enlist the services of a computer science major. He was genuinely struggling in second semester French, and thus welcomed the additional practice he received in trialling the software. An added benefit was his willingness to make suggestions about screen design and program features. He even helped us with some of our scripting!

Faculty oversight is essential to assure that curricular objectives are met and that projects are brought to completion. Since graduate students are transient by definition, continuity across versions is maintained by the faculty. Involving many parties allows the institution’s mark to be put on the product. It can truly be called groupware. We encourage the inclusion of customized elements such as the names of local sites (i.e. restaurants, parks, streets, etc.) and personalities in the dialogues and illustrative sentences. We believe that such features add immediate relevancy to the program. The “personal” touch has proven effective in the classroom (Omaggio 264-65). Of course, such flourishes should be left out if the courseware is to be shared with other institutions.

We have argued that in-house courseware development is a worthy undertaking. We have briefly defined the roles of the various participants in the process. In the preceding discussions we have alluded to the details of the development. We now will describe the actual work. We do not claim to be setting out definitive procedures. We will relate our own approach and give some suggestions which we have not actually attempted.

We believe that good courseware begins with a spark of enthusiasm. It matters little where the spark comes from. In our own case it came from an ambitious undergraduate who had created his own HyperCard stack for self-study purposes. The initial inspiration can just as well come from a dedicated pedagogue. Wherever the flicker comes from, it must be fanned. We believe this is the faculty’s task. He or she must commit time and energy to seeing that something is done. Other people must be enlisted, especially faculty members who are willing to consult as subject matter experts. The greater the number of people involved in the project, the less the likelihood of sabotage and the brighter the prospects for successful implementation (Burkman 434).

The next step is to mock up the idea. This is the approach of Rapid Prototyping (Tripp and Bichelmeyer 34). The mock-up can be very crude. Its purpose is to make the notion concrete so that others can critique it. Granted, showing rough drafts to skeptics makes one vulnerable to cheapshots. We counter that the risk is worth taking because constructive criticism is essential at the beginning of the project. One often has to take the bad along with the good. We are convinced that more in-house courseware would be developed if those with ideas avoided front-end “analysis paralysis” by using the Rapid Prototyping procedure.

Rapid Prototyping is comprised of three main components: a plastic and modular medium, and the objective of learning through the design process (Tripp and Bichelmeyer 41). The electronic environment is plastic in that it allows for quick and easy modifications of materials; it is modular because specific segments of information may be added, deleted and changed without affecting the rest of the instructional unit (Tripp and Bichelmeyer 38). Rapid Prototyping uses a partial model, the prototype, as a means of approaching a complete design. The prototype is trialled by student-users who provide valuable information with regard to problem-discovery and problem-solving, as well as general suggestions for improvement. These student-user comments are then synthesized to modify and expand the initial model. The basic notion is that if the end-user collaborates in the initial prototypes, the courseware or "groupware" will more clearly respond to user needs and preferences regarding aspects such as screen design, feedback messages, help features, etc. It is an axiom among programmers that no piece of software is ever finished. Rapid Prototyping recognizes this fact and incorporates it into its modus operandi. It is one of many Instructional Design models available. Thibeault has recently adapted a different model to in-house courseware development in the language laboratory (8-9).

Faculty and graduate students may encourage undergraduate student participation in courseware development through incentives such as extra credit for trialling. It is no secret that students are very grade-conscious. This is one of the reasons we prefer the term “courseware” in this paper to pedagogical software. We believe that students will be more willing to participate in the development process if they see that it is germane to what they are learning in class and that they can get some tangible benefit for their effort. As noted above, we were prompted to begin our work by a young man who had put together a stack for himself. If the reader is in an institution with many such students, he or she could offer awards for student-designed programs. These could then be fostered along into something usable by all. In such a scenario, students would end up teaching other students.

A final note about the development process. If one does not already know how to script in HyperCard or some other authoring tool, one must allow time in the first project for learning the system. We slightly overshot the initial deadline we had set for ourselves because we ran into programming problems. We earnestly desire to generate enthusiasm for "do-it-yourself" courseware, yet we do not want to oversimplify the task.

It must be admitted that educational benefits aside, many institutions are investing in computers as an academic way of “keeping up with the Jones’.” We hope that what we have proposed in this paper will insure that there be a “principled integration” (Garrett 94) of technology into a department’s curriculum. We are optimistic about the ability of “just plain folks” to create effective courseware, but at the same time we maintain that the process counts more than the product. The great heuristic value of the development endeavor stands independent of the outcome. That is, the cooperation that the work entails and the focusing of curricular objectives which is occasioned are benefits which extend beyond the resulting program. There is a ample precedent of successful materials development in the language laboratory (Pill 18). We believe that this tradition can and should be built upon. If we have contributed to the launching of a courseware cottage industry, we will count ourselves as successful.

back