---

[On-CALL Home] [VOL 5] [VOL 6] [VOL 7] [VOL 8] [VOL 9] [VOL 10] [VOL 11] [VOL 12]
[Special article] [Other CALL links] [CALL-EJ Online]

---

Choice and constraint in software design

Choice is not optional

Because computers are providing increasingly flexible configurations for the presentation of information, it is easy to get the impression that the key difference between pre- and post-computer learning was the shift from a linear organisation to multi-strand, multi- function, multi-resource materials. Closer consider- ation, however, shows this view to be some way from the truth. Foreign language students reading a newspaper article or a novel, for example, have always known that the task can be made more productive by having dictionaries or grammars at hand, and by knowing how to consult them efficiently during the process; that comprehension is enhanced by going to outside sources to obtain textual, visual or audio information on events, places, people, and other cultural references; and that access to other peoplesŐ interpretations or to parallel accounts can enrich understanding. Many of these avenues are often left unexploited by students -- out of ignorance, lack of resources, or lack of inclination. Capable and conscientious teachers, however, have always made a point of anticipating student needs, providing appropriate resources, integrating them intelligently into units of work, and creating relevant exercises to reinforce subject matter or principles, and to test and measure student mastery.

What computers do bring to language teaching is the possibility of easy and speedy access to a wide variety of learning resources at any point in an activity, and the possibility of creating a virtually infinite variety of pathways through those resources.

In order to allow for this user "freedom" in a piece of tutoring software, a great many choices must be made behind the scenes. Not the least of these is just how much choice the learner should have: too much could be confusing or make it impossible to provide focused and helpful feedback; too little may render an activity sterile and inflexible.

The issue of choice is ever-present in the process of software design, and is very often drawn to the designer's attention by students, users or assessors asking questions beginning "Why did/didn't you ...?" To some such questions one can only reply that it was simply impossible or impractical to do so. To others the answer is along the lines that the omission or inclusion of a particular feature was a conscious decision, determined by preference or by policy and in some cases (one must be honest) that it was the result of an oversight, for, as in any field, the process is a teacher, and one cannot be eternally revising work of an earlier period.

The hardest thing about deciding between alternatives is not always having to work out which is more appropriate or attractive, it is realising that, having made a choice, one is committed to a particular perspective or course of action. Choices restrict flexibility. Subsequent changes of perspective cannot always be achieved by neat sideways pirouettes. They often involve a complicated process of working oneŐs way back up through the maze of earlier decisions in order to determine consequences, and whether the proposed modifications will allow the overall structure to remain in tact. This is a time-consuming process and may well introduce new problems which may not be detected until considerably later. The original choices are therefore very important, and they require insight and a certain courage of conviction on the part of the designer.

This paper looks at a number points at which choice was exercised in designing a piece of CALL software for beginner students of French. Although there may be some problems which are subject-specific, most will manifest themselves in one form or another regardless of language, approach or topic. Broadly speaking these choices can be categorised as those made prior to embarking on the project; those resulting from pedagogical or linguistic considerations; and choices made available to the student within the software.

Pre-embarkation choices

The numerous choices to be made prior to putting pen to paper or code to computer are as frustrating as they are clear-cut.

Platform choices

The primary choice is that of platform: PC, Mac, Apple II, BBC, Archimedes, mainframe, etc. Factors influencing this decision are:

• the information and resources available to the developer at the time the project is launched;
• the country in which or for which the software is being developed;
• the type of hardware most widely used in the targeted population;
• the likelihood that the hardware will undergo dramatic change or become obsolete. With platforms such as Apple IIs and Microbees one must make a realistic assessment about their likely continued use and the investment of time, effort, expertise and resources into developing materials for them.
• the ability of the hardware to cope with the demands which the planned software will impose on it.
• whether the software is for personal/local use or for wide distribution. Software which does not need to take account of the resources which may or may not be available to other potential users can be designed to incorporate any or all of the peripheral gadgetry at the developer's disposal: videodisc, electronic writing pad, CD ROM, touch screen, printer, microphone, overhead display pad, 80MB of storage... For software intended for wide circulation one must consider what equipment the likely public already has at its disposal, or would be prepared to purchase in order to run that software.
  Although some platforms, notably PC and Apple Macintosh, are moving ever closer together, they are not yet at the point where what is designed on and for one system will run readily on the other, particularly when multimedia activities are involved (a sound card, for example, is an extra for PCs, and is therefore likely to involve users in extra expense; and sound files are not converted easily and reliably between these systems). There are therefore a number of options available:
• develop uncompromisingly for one or other platform -- this means being free to exploit all the resources with no regard for translatability of software;
• develop for two or more platforms in parallel -- this involves duplication of expense, and perhaps two different sets of programming expertise;
• develop for one or other platform using only applications and formats which current translators can convert readily between systems;
• develop for one platform, but restricting oneself to applications and formats which are likely to become convertible to the other in the near future.

Programming choices

A second set of fundamental issues relates to programming. Language teachers are not normally trained programmers. They must therefore decide whether they will set out to learn how to program themselves, or get somebody else to do it.

The present writer, for example, chose not to do it himself. To do so would have required time, considerable time, and there was no guarantee that his talents lay in that direction. Time spent in learning how to program, and then in programming each piece of software, is time taken away from coming up with ideas, producing specifications, generating and refining linguistic input. It also shifts the focus away from the pedagogical. On the other hand, choosing not to do the programming is a luxury -- it implies that there is somebody else qualified, willing and available to do it -- and it introduces the possibility of communication breakdown between the teacher- linguist and the programmer. Continuity of expertise and the ability to effect user-guided corrections, modifications and refinements can be seriously handicapped in the case of grant-funded development where the programmer has no choice but to move on in pursuit of other employment opportunities at the end of one or two years.

Another issue concerns whether programming is to be done from scratch (i.e. using a programming language such as Pascal or C); using an authoring tool such as Authorware Professional or MacroMind Director; or using an authoring environment such as HyperCard, SuperCard or ToolBook. There are distinct advantages to programming from scratch. One is in complete control of design direction at all times, and the question of ownership of proprietary utilities (e.g. fonts, graphics, sound and routines) does not arise. There are, however, considerable disadvantages as well. It requires a great deal more time, and greater and more specialised expertise. Moreover, one runs the risk of either reinventing wheels or of inventing wheels which are even less round than many already in existence.

Another influence on programming which has a bearing on decisions from the earliest stages is what might be called the "end-user factor". Software developed primarily for experimental purposes and/ or for use in the sponsoring institution, is not subject to the same constraints and demands as material developed with publication and wider distribution in mind. "In-house" development does have its pluses. One can be sure that all users will be looking at it from roughly the same viewpoint, because they are all doing the same course, and the material was designed to be integrated into it. The teacher-designer can guide users. If the software has not been distributed or sold, the designer can make modifications at any time without feeling under any obligation, moral or legal, towards other colleagues. And the copyright of graphics, sound, video and utilities is much less of an issue if the software is solely for "private" use. Less positive, however, is that software produced under such conditions remains experimental or prototypic in character, and could be considered to be a questionable investment of the developer's time if its benefit is to be limited to students of a single foreign language program or to colleagues hearing a report of it at a congress or reading an article about it in a learned journal. Perhaps the biggest problem is that software not exposed to a wider public of non-sympathetic (this does not mean hostile) users is unlikely to develop the quality of robustness characteristic of many arcade games, business systems or word processing packages, and conspicuously lacking in so many educational packages. If the software is to be published, however, one must ask who will publish it and with what constraints on content, cost, platform and ownership.

Designer motives

Software design can be motivated by a variety of factors, personal or external, operating in isolation or in combination. These may include the need or desire to:

• produce an independent, durable language learning activity;
• see what operations the computer is capable of;
• study the effectiveness of the computer as an aid to language learning in different contexts;
• examine a pedagogical theory;
• teach more efficiently;
• save the institution money;
• cultivate or retain students.

Technological solutions

In any software design, realistic consideration must be given to the limitations which may be imposed on its use by the sophistication of the hardware generally available for running it by considering the average Australian language classroom, for example. Neither does a designer need to incorporate all the presentation enhancers available just because they are there.

In deciding whether to work with black and white or colour, for example, consideration should be given to:

• pedagogy: colour can enhance presentation or be aesthetically off-putting, it can focus or distract attention, provide system or confusion;
• programming expediency;
• flexibility: whether to develop one version only, two versions from the outset, or plan to revise everything into colour at some future point.

The incorporation of sound almost invariably enhances foreign-language activities on the computer, although there are cases, particularly in activities focusing on reading, writing, cognitive development, information-gathering or group use, where it could be considered peripheral. Some considerations relating to the use of sound are:

• how the student will be interacting with it;
• the amount of sound to be stored;
• how to maximise the use of any sounds that are incorporated.

Sound digitised using MacRecorder (SoundEdit and HyperSound) occupies 22Kb per second uncompressed. Therefore, unless the activity contains only a very small amount of sound, some consideration must be given to the balance between quality and compactness. The overall size of a module must be taken into account. For reasons of economy and transportability it is best if a single module does not occupy more than one HD floppy, preferably uncompressed. Having to expand files prior to first use is just one more straw on the often shaky camel's back of the enthusiastic but uninitiated CALL language teacher. And in any event there is a certain trade-off to be made at the user- teacher's end between the usefulness of the activity and the amount of disk space it occupies. The smaller the modules the more of them it is possible to store on a hard disk at one time (and sound modules do not always function satisfactorily from floppies). This is important if the computer is to be used as a reference library of activities to allow students to work at their own pace, to allow students at different levels to use the same machine, and to enable students to return to work covered earlier in order to revise. If language teachers have to share hardware with colleagues in other disciplines, they are more likely to be encouraged to initiate their projects if they do not gobble up an inordinate amount of disk space on existing resources. Similar considerations to those mentioned for sound apply to the use of video images.

Propriety considerations

One of the attractions of the Macintosh interface is that copying is easy, although from the software publisher's point of view this can be very much a mixed blessing. It does not seem unreasonable to want to protect the fruit of one's expertise and of hundreds of hours of work from pirating, but copy protection has been widely abandoned because it raises more problems than it solves. Everyday occurrences such as lost passwords, or original users leaving the institution that has purchased the software can become major impediments. Protected software can also cause problems when moving between different versions of an application. It appears, moreover, that one of the laws of the informatic jungle is that anyone who really wants to get around the protection can, that there are some perverse souls who break through codes for the pleasure of it, then retail their code-cracking skill on the back of the items of software they have rendered commercially worthless in the process. The actual programming is similarly vulnerable. A further difficulty can arise from the fact that the place where the file is kept (usually a folder) cannot be locked if the activity is one requiring the acceptance of type-in answers.

It would be more than a little naive to pretend that the types of decision dealt with to this point have been of a purely technical nature and belong to a domain entirely separate from the those relating more to pedagogical and linguistic matters which we shall discuss in the following paragraphs. Quite clearly, in designing CALL software, one must have computers, language, and assistance to learning in mind at every stage. In what we have considered so far, choices were being made about computers and programming in the context of language learning and teaching. We now switch to choices about language principles and teaching practices made once the parameters of the medium and the tools to be used have been set.

Pedagogical choices

Students as a "design factor"

In some senses, the software designer has little or no choice when it comes to the students who will be using the material. If the designer lives in New Zealand, the users, in the first instance at least, will in all probability be New Zealanders, if in Japan, Japanese. And if the software is made available commercially, anyone who wants to can purchase and use it. But in other respects the designer does have choice, and must exercise it.

Factors such as the age of students, their linguistic and cultural background, the status of the target language in the country where it is being taught, and the reasons for learning it, all have considerable influence on the design and content of a piece of software. It is unlikely, for example, that a module designed for primary school pupils in Rabat, regardless of the point(s) addressed, would be of much use to third semester students at a university in Kansas. Rather than attempt to describe or tabulate all the broader language education factors which might have a bearing on software design, we shall outline the context in which we were working, and allow colleagues from other backgrounds to reflect on the parallels or differences in their own situation.

When French is taught as a truly foreign language, which is definitely the case in Australia, there is virtually no incidental contact with that language outside the classroom as would be the case in a French- speaking country (i.e. where French is taught as a second rather than a foreign language) or even in Europe, many parts of Africa, or in parts of the US or Canada where one can fairly readily find radio and television stations broadcasting in French.

A one-year beginner language course at an Australian university typically has a maximum of 168 class hours. This is the equivalent of 2 weeks of 12-hour days of exposure to the language. In secondary schools, a pupil may have of the order of 500 hours over 5 or 6 years. If the teacher is to provide students with maximum opportunity to develop communicative skills in class, through pair-work, simulation or role- play activities in an unthreatening but monitored environment, ways must be found to allow students to work productively on receptive skills and language systematisation outside of the classroom. Reading, listening or listening/viewing comprehension (computer-assisted or otherwise) are one group of activities which can to a large extent be freed from close teacher supervision. Grammar exercises are another. These two activities between them can provide any number of starting points for the development of CALL materials. Perhaps one of the most awkward situations for potential CALL developers is that of having to decide on a single avenue, as awareness of all the other possibilities becomes keener the better-acquainted with the field one becomes.

The decision at the present writer's institution to target the Beginner French course took account of the following considerations:

• There have been consistently more enrolments in the department's ab initio course than in the post-secondary course.
• The designer had been teaching, examining, designing courses and publishing texts for such students for the past 20 years with experience covering grammar-translation, audio-lingual, structuro-global audio-visual, and communicative approaches.
• Classes tend to be large, often with 35-40 students at the beginning of the year. Many beginner students French only ever intend to do one year of the subject, which means that enrolments in higher years are markedly lower, and the need for computer support less pressing. The situation is fairly similar in all Australian universities.
• Any materials developed for university beginner students will also be of use to secondary school pupils, with little or no modification required.

Tools and tutorials

There are many options: discovery activities using data bases; creative teacher-monitored exercises in which students exploit word-processing, thesaurus, spelling and grammar checking resources; expository tutorials; and closed drills (gap-filling, multiple choice, sequencing, matching, etc.).

If one designs a tool such as a gap-filler or a concordancer, it does not impose any specific content on the teacher using it. It also means that if teachers want content, they have to find it themselves, work out how to use the tool, enter the data, and test it for bugs. If one designs a closed exercise, there is always someone who finds that the vocabulary is not appropriate, the level too advanced or simple, the texts too long, too varied or too similar. And if it is a modifiable template, the instructions may be too confusing, they may not anticipate certain problems teachers will encounter in trying to use them, the authoring tool may not be sufficiently flexible to allow the designer to create exactly the template desired. It is easy to see the negative side of any choice (there seems to be an endless string of sceptics only too eager to point them out to the designer), but it is the designerŐs task to remain creative and positive within the restrictions imposed by the various choices that must be made on the way. We chose to design a set of extension and revision drills and similar activities.

Subject area

Different teachers might choose to focus on different areas or combinations of areas. These may range from literature, to civilisation, history, society, art, pronunciation, linguistics, grammar, style, communication, or translation.

Teaching approach

The computer is a medium: it is not a methodology in itself, but reflects the methodology of the designer. It has qualities which can make it useful in discovery learning, communicative situational activities, immersion, testing, grammar-translation, audio- lingual, audio-visual, or games. In choosing to develop an activity to suit one pedagogical approach, one may severely limit one's scope for accommodating others.

In the process of developing closed, drill-like grammar activities and becoming better acquainted with other work in CALL, the present writer became very aware of the power of the computer as a generator of creative, stimulating, life-like activities, and had to make a conscious decision not to be enticed away from the task at hand, the merits of which he did not consider to be under threat just because other approaches also have merit. To focus on the formal is not to deny the merit of the creative and the situational-functional. On the contrary, the objective is to allow student to master various micro-systems on which they are required to draw for situational uses of language so that they become reflexes and their communication is not impeded by constant reflections on metalanguage. In a second-language learning environment, many of these forms are appropriated unconsciously, with students only ever encountering acceptable (if not strictly grammatically correct) forms, and developing an auditory echo (reinforcing syntax, gender, tense) so that they never have to hesitate as they hypothesise about which form to use in a given context. Just knowing you have truly mastered a particular point gives you a different and more positive attitude to communicating.

One must also decide whether the software is primarily for individual, small group or full class use, and the extent to which satisfactory operation is to be dependent on the availability of teacher monitoring and supervision.

Software autonomy

External factors can easily influence choices which ideally should be made solely on pedagogical grounds. The most obvious of these is "publisher power". Publishers are inclined to treat CALL software the same way they do audio tapes, video tapes, slides, wall-charts, flash-cards and games. It is something to enhance the marketability of the packaged foreign language course. Authors (or, given the scope of the task, teams of authors) are required to operate within strict budgetary constraints because it is the sale of the textbook and not the software which is likely to produce revenue for the company. Much foreign language software is little more than another band of pattern crocheted around the edge of a textbook rug. It is not there for its own sake, but to enhance the look of the product as a whole. It is heavily dependent on the method for thematic and lexical inspiration. Even if it could be sold separately, factors such as copyright insecurity, investment protection and market-edge militate against the tendency. Only the happy few have the opportunity of developing editor-endorsed materials. Thus, in CALL, the system often acts against increasing the scope and availability of software.

The main alternative is a modular approach where teachers/designers have an idea or a piece of material (lexical, morphological, syntactic, situational, functional, comprehension, cultural) which they know will be useful to a good many teachers/pupils and which can readily be plugged into virtually any methodology or manual or syllabus. Financial considerations cannot be ignored indefinitely, as there is a limit to most people's inclination or ability to be philanthropic and altruistic. One must decide whether and how to disseminate the product. And once money changes hands the issue of support responsibility arises.

Language content choices

The decision to create grammar review and extension activities is the catalyst for a host of language-related choices.

Our main criteria of selection were the regularity with which the point features in beginner French courses for adolescents or adults, regardless of methodology or of whether the point is treated explicitly or as part of a speech function; and the extent to which accurate, intelligible communication is affected when a student has not mastered that point. This produced the following basic list: Numbers, Alphabet and Spelling, Time, Dates, Personal Identification, Basic Expressions, Articles, Adjectives, Present Tense Verbs, the PassŽ ComposŽ, the difference between the PassŽ ComposŽ and the Imperfect, Comparison, Pronoun Objects, Indirect Speech, Infinitive Government, Relative Pronouns, the Present Subjunctive, Vocabulary. On reflection, the choices made provide a number insights into the designerŐs position regarding the methodology of foreign language teaching. These include:

• the view that some patterned activities which students master at different rates are best removed from the classroom in order to free up class time for activities requiring human interaction;
• grammatical accuracy is part of communicative skill;
• notions (such as time, date and numbers), conventional grammar points, and functions (such as personal identification) are all considered fundamental;
• teaching is enhanced if as many classroom activities as possible are conducted in French from the outset (this is why students are encouraged to master what are termed "Basic Expressions");
• students should not be deprived of opportunities and resources for learning vocabulary;
• some points can be accorded lesser priority because they are structurally simple and/or correspond closely to English usage (for example, the future tense, the imperative, adverbs), or because their use in speech is restricted and/or complicated (the future perfect, the imperfect subjunctive, the preterite, tense sequences).

Priorities

Software development is a very time-consuming activity and it is not possible for one person to produce ten or more pieces in parallel. That means that one language feature has to be treated first, and others must wait. Each developer will establish his or her priorities according to circumstances and conviction.

Subdivisions within a module

Having elected to deal witha given language point (grammatical or notional), one is then faced with the task of making the material accessible to students in terms quantity, concepts, and level of difficulty. The fact that activities are designed primarily for extension and review does not justify creating an indigestible, inaccessible, monolithic exercise which requires students to demonstrate comprehensive knowledge in each item. It is desirable for revision, like learning, to be staged. Perhaps the most rudimentary example of this principle is found in our treatment of Numbers. Obviously students wish to feel that they can cope with any number, but this does not mean that the best solution is to confront them with one activity covering 0 to 1,000,000 in one hit. Such an activity would be of little use to a student in the first year of secondary school or to an ab initio university student wishing to practise and revise after the first week of lectures. We therefore chose present the numbers in three stages: 0- 50; 0-100; 0-10000. Other arrangements would have been possible: 0-20, for example; or extending the upper limit to 999,000, although this alternative would have introduced problems at the level of storage space required for sound.

Examples of other subdivisions created to improve accessibility and flexibility are:

Articles:

Definite, Indefinite, Partitive, "ˆ" combin- ations, "de" combinations, General Review.

Adjectives:

Demonstratives, Possessives (further divided into mon, ma, mes; ton, ta, tes; son, sa, ses, leur, leurs; ton, ta, tes, votre, vos; notre, nos); Agreement Identification (activity requiring students to demonstrate awareness of the basic principles of adjective agreement); Attributive Adjectives.

Present Tense Verbs:

4 regular -er verbs; regular -er verbs; regular -ir verbs, regular -re verbs; the 5 most common irregular verbs (avoir, être, aller, faire, venir); reflexive verbs; semi-regular verbs; 10 sets of irregular verbs grouping them according to similarity of pattern in the present tense conjugation); and 2 different test activities covering all conjugation types.

Passé Composé:

Regular -er verbs conjugated with "avoir", the 16 most common verbs conjugated with "être", a mixture of the two categories. Regular -er verbs, regular -ir verbs, regular -re verbs, a mixture of the three categories.

Irregular verbs.

Verbs conjugated with both "avoir" and "être".

Reflexive verbs

with a direct reflexive pronoun, reflexive verbs with an indirect reflexive pronoun, a mixture of the two categories.

Negatives:

one exercise on the position of negative particles in the passŽ composŽ, another requiring transformation from the present affirmative in two stages. Interrogatives.

Pronoun Objects:

me, te, nous, vous with the present tense.
me, nous with the imperative.
me, te, nous, vous with the interrogative.
le, la, l', les with the present; lui, leur with the present; le, la, l', lui, leur with the present.
le, la, l', les with the passé composaeacute; lui, leur with the passé composé le, la, l', lui, leur with the passé composé.
le, la, l', les, en with the present.
lui, leur, y with the present and passé composé.
Position and order of pronoun objects with: the imperative, the present, the passé composé.

Indirect speech:

statements, yes/no questions, Wh-word questions, Qu'est-ce qui and Qu'est-ce que questions, Commands, with each of these five categories broken into two levels of difficulty for both the present and the past.
And a final set combining all types of reporting.

Decisions about staging are not limited to grammar exercises. Corresponding choices must be made in presenting speech functions or notions. Here, apart from establishing the desired degree or degrees of difficulty, consideration must be given in each activity to the relative emphasis, or combinations of emphasis to be placed on listening (recognition, discrimination), reading, writing and, where microphones and stored responses are possible, speaking skills.

Other considerations

Other ever-present considerations are:

• Should there be both practice and test modes, or just practice, just test?
• What level of vocabulary is appropriate to the language feature being treated?
• Should student performance be monitored?
• Should the score be stored or just made available to the student on completion of the activity then discarded?
• How many attempts should a student have at each item?
• Should this be fixed or variable?
• At which point(s) should a student be able to quit the exercise?
• Should on-line grammar always be available?
• Which language should instructions, feedback, grammar and other help be given?
• Should this always be in the same language within a unit, or can a mixture be used?
• Should there be a progression in the language of presentation (instructions, help, feedback) from source language to target language as the language features treated become more advanced?
• Must an answer be 100% correct (punctuation, spacing, spelling) to be acceptable?
• Can the computer cope with anything less than that, even if is desirable?
• How many items should an activity be built on?
• Should items be presented in a specific sequence or randomly?
• Should students be required to type in a full sentence as an answer, or phrases, or single words?
• Long stretches of text are more natural units of discourse, but they take longer to type, to retype and to check, are more likely to contain elements irrelevant to the grammar point being focused on, and are more likely to contain inconsequential errors which the computer will not accept.
• How much feedback should students be given?
• At what stage(s)?
• What is the boundary between a maximally informative screen and a cluttered one? When is animation (or sound, graphics, video) helpful, when is it a gimmick?
• How much computer literacy should be assumed on the part of the user?

There is a trade-off to be made between giving so little information that students feel frustrated because they cannot work out what to do next, and giving so much that instructions are an annoying hindrance, incessantly repeating advice on clicking, dragging, positioning the cursor, etc. which is in fact the province of a basic computer literacy course and which most students know intuitively, can pick up from their friends, and only need to be told once for it to become a reflex.

Conclusion

This article has raised and discussed scores of questions which one is confronted with in the process of designing CALL software, each of which raises other questions in turn.

By way of conclusion it would seem more appropriate to reflect on these choices rather than to reiterate them. Choices must be made at three levels: technical and logistic; pedagogical; and linguistic. They can relate to the platform; the combination and configuration of hardware and appendages required to run the software; the linguistic and cultural domain to be covered; the pedagogy underlying the design and presentation; the type of activity; the amount of external teacher involvement required; the scope for adaptation or modification; the relative emphasis to be placed on the four macro-skills; whether it is primarily to be a tool for teaching or research; the linguistic and social background of the learners; the size of the user group; whether it is essentially to supplement a course or to be the course; portability; and degree of independence from published textbooks.

In most cases it is not a matter of "right" and "wrong" choices. It is more a matter of whether what one is doing is realistic, practicable, desirable for the learner, and consistent with the intended teaching approach. Any choice one makes has ramifications which can manifest themselves at other levels and which contribute to the overall shape and feel of the software. Activities must be clearly defined, meet the needs of a specific group of learners, and their value or otherwise to potential users to be readily recognisable.

Most importantly, choices are just that: choices. You can do one thing or the other, rarely both. Each time one makes a choice, one imposes limitations which have effects all the way down the line, and attempting to take them into account in order to effect afterthought revisions can make for an extremely difficult upstream swim. It is therefore crucial that choices be made with full awareness of what one is not doing as well as of what one is doing. Having made the decisions and launched the software into the big wide world of users and critics, the designer is neither called on nor in a position to be constantly explaining and justifying the choices made. Whether you have created a wonder or a monster, you have to live with it.

Dr. Brian McCarthy is Associate Professor of French in the Department of Modern Languages at the University of Wollongong, Northfields Avenue, Wollongong, N.S.W. 2522.
His research interests are foreign language teaching methodology (French); CALL; software development; phonetics; and translation.
E-mail: b.mccarthy@uow.edu.au