Hayworth, K. & Roby, W. B. (1993). In-house courseware development: the whys, whos, and hows. In Peter Liddel (Ed.) CALL:
Theory and Applications.
Proceedings of CCALL2/CCELA02:
The second Canadian CALL conference (pp. 115-122). Victoria,
BC: University of Victoria.
Kim Hayworth & Warren B. Roby
May 1, 1993
Abstract:
The advent of
authoring tools and software such as HyperCard have made it possible for
instructors to create their own courseware without learning a full-fledged programming
language. This paper discusses the pros
and cons of in-house software development based on the authors’ experience
creating a program to supplement a first-year French textbook. It is granted that courseware development
can be time-consuming and occasionally frustrating, but it is argued that the
process is worthwhile if done properly.
Ideally, instructors incorporate their linguistic expertise in
prototypes which are trialled by students.
The result of this collaboration is user-friendly, pedagogically-sound
groupware.
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.
Why develop courseware
in-house?
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.
Who should develop courseware?
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.
How should courseware be
developed?
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.
Conclusion
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.
References
Burkman, E.
"Factors affecting utilization." In Instructional
technology: Foundations . Ed. R.M. Gagné. Hillsdale: Lawrence Erlbaum Associates, 1987. 429-55.
Garrett, N.
"Technology in the service of language learning: trends and issues." Modern
Language Journal 75 (1991): 74-101.
Kinzie, M. B., and H. J. Sullivan. "Continuing motivation, learner
control, and CAI." Educational Technology Research and
Development 37.2 (1989): 5-14.
Kulik, J., and Chen-Lin
Kulik. "Meta-Analysis in Education." International
Journal of Educational Research 13.3 (1989): 221-340.
Last, R.W.
Artificial intelligence techniques
in language learning.
Chichester: Ellis Horwood
Limited, 1989.
Maehr, M. L. "Continuing motivation:
An analysis of a seldom considered educational outcome." Review
of Educational Research 46 (1976):
443-62.
Omaggio, A. "The relationship between personalized classroom talk and
teacher effectiveness ratings: Some
research results." Foreign Language Annals 15 (1982):
255-69.
Pill, G.
"Home-made or store bought –– two approaches to work in the
laboratory." NALLD Journal 8
(1974): 18-21.
Thibeault, T. F. "A dynamic protocol for cooperative courseware
development." IALL Journal of Language Learning Technologies
26 (1993): 7-18.
Tripp, S., and B. Bichelmeyer. Rapid Prototyping: An alternative instructional design strategy. Educational
Technology Research and Development 38 (1990): 31-44.
Authors:
Ms. Hayworth did
her M.A. in French at Washington State University in Pullman, Washington. Dr. Roby was her thesis director. She is currently at Stanford
University. kimhwrth@stanford.edu
At the time of
writing the article, Warren B. Roby was Director of the Language Learning
Resource Center and an Assistant Professor of Foreign Languages at Washington
State University. He currently is
Professor and Chairman of Language Studies at John Brown University. wroby@jbu.edu