ICT4LT Module 3.2

CALL software design and implementation


Contents


Aims

This module discusses the process of creating a multimedia CALL package, with particular emphasis on the design process. The main part of this module looks closely at the template approach to authoring and is based on the authors' personal experiences in creating multimedia CD-ROMs for language learning.

This Web page is designed to be read from the printed page. Use File / Print in your browser to produce a printed copy. After you have digested the contents of the printed copy, come back to the onscreen version to follow up the hyperlinks.


Authors of this module

Ana Gimeno-Sanz, Universidad Politécnica de Valencia, Spain.

Graham Davies, Thames Valley University, UK.

Additional material provided by Paul Bangs, Language Technology Consultant, UK.


1. First considerations

Designing and creating a multimedia CALL package is an extremely demanding task, calling upon a range of skills and meticulous attention to detail. Such is the complexity of computer programs these days that it is highly unlikely that a single person will have all the necessary skills to undertake a CALL development project alone. Team work is therefore essential, and each member of the team must have some understanding of the roles of the other members of the team: see Section 2 on the composition of the team. The language teacher who joins a software development team, for example, does not have to possess computer programming skills but he/she must have some understanding of basic programming concepts. Similarly, those responsible for the programming do not have to have a knowledge of foreign languages, but they need a good understanding of Natural Language Processing: see Module 3.5, Human Language Technologies (HLT).

Once the decision has been taken to create a multimedia CALL package it is essential to consider:

A needs analysis taking into account both the learners' needs and the needs of the teachers/tutors who will be using the software should also be carried out. The results of a detailed survey will help determine not only the language contents and level the target group is particularly interested in, but also the most appropriate pedagogical approach to follow and the solutions that technology can offer them to enhance their learning process.


2. Personnel and tools

The subject specialist - usually a language teacher - is the key member of CALL project development team. He/she is responsible for providing the content and pedagogical input. Most CALL development projects require more than one subject specialist. The term content provider is also used to describe this person's function in the team.

The team must have at least one member who is capable of using an appropriate authoring tool, e.g.

A language teacher can achieve good results with a dedicated CALL authoring program, but the multipurpose authoring packages mentioned above require a considerable degree of programming expertise in order to get the best results. A language teacher can achieve reasonable results with such packages if he/she is willing to persevere, but the time taken to learn a complex package such as Director will probably outweigh the benefits. The team should therefore include a programmer who is familiar with the chosen authoring tool. Alternatively, the programmer may feel more at home writing in a high-level programming language such as Visual Basic or C++, both of which the average language teacher would not consider using. Unless the language teacher decides to go it alone - which is inadvisable - a CALL development project requires, at the very least, close collaboration between language teacher and programmer. The programmer, acting on the language teacher's advice, will create a set of templates that form the basis of the multimedia CALL package that will be developed. The advantage of this template approach to authoring, which is described in Section 4, is that the subject specialist does not have to do any actual programming. The programmer designs the templates, and the subject specialist provides the content.

An important factor to bear in mind at an early stage is graphic design. A program may be very well designed content-wise and it may run very smoothly, but it will fail to achieve its aim if careful graphic design is not taken into account. It is highly desirable to call upon the services of a qualified graphic designer to produce pictures and icons, and to advise on fonts, colour, screen layout, etc: see Section 3. Such a person will be familiar with packages such as Adobe Illustrator and Adobe Photoshop. Graphic designers often have a background in photography. If not, the services of a professional photographer will be required - or, at the very least, a very good amateur photographer.

A sound engineer and video technician will be required if the package is to contain substantial amounts of sound and video. They should be familiar with software tools for manipulating sound and video.

Finally, it is highly desirable to seek the advice of an instructional designer. Developing a CALL package is more than just putting a text book into a computer. An instructional designer will probably have a background in cognitive psychology and media technology, and will be able to advise the subject specialists in the team on the appropriate use of the chosen technology: see Levy (1997:66-68).

As already indicated, team work is vital for the development of multimedia CALL packages. It consists of several discrete stages: e.g. concept design, pedagogic principle design, instructional design, interactive design (see Sims 1996), programming, resource acquisition and processing, integration, testing and piloting, and delivery and distribution/marketing. Developing a multimedia CALL package is therefore a task that should not be undertaken lightly. How this works in practice is illustrated with reference to 14 case studies of CALL courseware development projects in Blin, Chénik & Thompson (1998), which are analysed under the following headings:

This publication is essential reading for anyone considering embarking upon a CALL development project.


3. General program design principles

The first part of this section (3.1 to 3.6) is concerned mainly with general pedagogical issues and stylistic issues. It is based to a large extent on the following document, which was originally produced for the guidance of members of the TELL Consortium:

Davies G., Hickman P. & Hewer S. (1994) Style guidelines for developers. Hull: The TELL Consortium, University of Hull.

The ICT4LT project gratefully acknowledges the TELL Consortium for permission to reproduce the key points of the document in sections 3.1 to 3.6. For further information on The TELL Consortium, see http://www.hull.ac.uk/cti/tell. See also Laurillard (1993a).

The second part of this section (3.7 to 3.14) has been written by Ana Gimeno-Sanz and is concerned mainly with the functionality of multimedia courseware.

Contents of Section 3

3.1 The learner

  1. The learner needs clear instructions on how to start the program. Documentation should include a quick-start sheet.
  2. The energy of the learner should be devoted to the content of the materials and not to understanding how to use them.
  3. The learner should be able to navigate the program efficiently. A well-designed program will make the answers to the following questions available to the learner throughout his/her work session:
  4. It is important to achieve consistency in commands and keywords that are used in instructions and explanations, so that the learner's attention is directed to the task itself rather than to an understanding of the terminology. There must be consistency in terms of:
  5. The learner may need to access dictionaries and help on the contents of the program and on using the system.
  6. The learner may need to make use of a notepad as an extension activity - which should be available via a mouse click.
  7. The program - and each discrete section of a program - should include a brief statement of objectives, preferably numbered or bulleted points laid out clearly on screen.
  8. The level of difficulty of the program should be clear to the learner: e.g. Beginner, Elementary, Intermediate, Advanced.
  9. Where appropriate, a pre-test should be provided to enable the learner to determine that the material in the program is at his/her right level.
  10. The program should have an inbuilt default route, but the learner should be able to override the default route if he/she wishes. The learner should be able escape from the program at any point.
  11. A preferences menu may be provided: e.g. allowing the learner to choose screen colours and turn "beeps" on or off, etc.
  12. If the learner quits the program before completing it should be possible to re-enter at the point where he/she gave up.
  13. The learner should be able to choose the language of the on-screen instructions. In some programs the language option may be pre-set by the teacher.
  14. The length of strings that the learner is required to type in interactive exercises should be limited to, say, 15 characters in order to minimise typing errors and to facilitate response analysis. An exception to this rule is an activity in which the learner makes notes that will not be subjected to computer analysis.

3.2 The teacher

  1. The teacher needs a reference manual containing:
  2. Information should be provided on how the content relates to existing national or international examinations and curricula.
  3. It is helpful to indicate how many hours of tuition the program contains.
  4. Options should be offered that enable the teacher to set up the program for a particular group of learners. This may include specifying the route the learners take, recording and outputting results (tracking), or allowing the teacher to amend the data contained in the program and input new material.

3.3 Writing for the screen

Writing for the screen is quite different from writing for a book. Jakob Nielsen writes:

Reading from computer screens is about 25% slower than reading from paper. Even users who don't know this human factors research usually say that they feel unpleasant when reading online text. As a result, people don't want to read a lot of text from computer screens: As a result, people don't want to read a lot of text from computer screens: you should write 50% less text and not just 25% less since it's not only a matter of reading speed but also a matter of feeling good. We also know that users don't like to scroll: one more reason to keep pages short. [...] Because it is so painful to read text on computer screens and because the online experience seems to foster some amount of impatience, users tend not to read streams of text fully. Instead, users scan text and pick out keywords, sentences, and paragraphs of interest while skipping over those parts of the text they care less about.
Be Succinct! Writing for the Web, Alertbox , 15 March 1997: http://www.useit.com/alertbox/9703b.html

See also:

It is important, therefore, to make reading of explanations and instructions in computer programs as easy as possible. Brevity is important. Concise text compensates for decreased reading speed.

  1. As a general rule it is advisable to use:
  2. The learner should not be expected to remember parts of explanations or instructions from a previous screen. Cognitive overload is common in extensive hypertext systems, which require the learner to carry over unnecessary information from one screen to another.

3.4 Typefaces and fonts

The terms typeface and font (also fount) are often confused or interchanged. Typeface is the name given to the style of a particular set of letters, numerals, symbols and punctuation marks. Font refers to a complete collection of letters, numerals, symbols and punctuation marks that have common characteristics, including their style and size.

  1. As a general rule it is advisable to limit the number of different fonts that appear on screen. The two commonest - and perfectly acceptable fonts - are:
  2. The acceptable minimum font size for screen text in a serif font is 12-point. This applies particularly to continuous body text in a serif font, e.g. Times New Roman or Garamond. A 10-point sans serif font is still easily legible, e.g. Arial and Helvetica are generally larger than Times New Roman. Anything less than 10-point causes eye-strain - apart from brief subtitles supporting an icon.
  3. A skilled graphic designer can use a variety of typefaces on screen. Unskilled designers will probably make a mess if they try to use too many different typefaces. No more than two typefaces should appear on screen at once: e.g. one serif, e.g. Times New Roman, and one sans serif, e.g. Arial.
  4. It is inadvisable to use exotic or unusual fonts. They can be hard to read and may not be available on the user's system.
  5. A serif font is preferred for body text. A sans serif font is preferred for brief messages and titles.
  6. Titles should be bold and centred and at least one point larger than the body text to which they refer.
  7. Underlining should be avoided. Bold or colour should be used to emphasise a word or phrase.
  8. Large chunks of text in capital letters are unacceptable. But capitals are fine for headlines, warnings, etc.

3.5 Colours

Colour needs to be used with caution! Overuse of colour makes information more difficult to process because the user slows down to think about what the colour means.

  1. It is important to ensure good contrast between text and background, e.g. dark text on light background or vice-versa. Dark on light is preferable for text: see next point.
  2. Subtle colours should be used for background wherever possible, i.e. pastels rather than saturated tints. Plain backgrounds should be used - no spots, vertical lines or horizontal lines, etc.
  3. The brighter colours of the palette should be avoided, because bright colours can cause after-images.
  4. Complementary colours must not be combined. Colour-blind users cannot distinguish them and people with normal sight may also have problems: e.g. they may appear to vibrate. Complementary colour combinations to be avoided are:
  5. The three primary colours, i.e. red, blue, yellow, should not be combined. A "bleeding" effect can occur with any pair of these colours. Some people notice the effect more than others.
  6. Colour should be standardised according to window/screen type, e.g.

3.6 Programming issues

  1. The software should run on standard hardware and should not require non-standard soundcards, unusual graphics cards, special drivers, etc.
  2. All on-screen text, commands and keywords should be held in text files outside the program wherever possible. This also applies to image files, sound files and video files.
  3. The content of the program must be checked for possible breaches of copyright. Copyright clearance is required for all authentic texts, pictures, sound recordings, video sequences, software code, etc. There are no automatic special concessions for educational users as far as the dissemination of copyright material is concerned, regardless of whether it is distributed free of charge or sold on a commercial basis. See our General guidelines on copyright.

3.7 Deciding on courseware features

Once we know the content requirements, language level and learning needs of our target group, we must decide what the general courseware features aim to be. We may be designing materials for autonomous learners, in which case we will include as many tools as possible in order to support self-access learning, e.g. by providing reference materials such as grammar notes, explanations of the functions of language, cultural context of the target language, a sound-enhanced dictionary or glossary, self-assessment tests, notepad, etc. Or we may be designing a tutor-guided package in which, in addition to the tools mentioned above, we will include tools that support the teacher, such as a teacher's guide, detailed student assessment reports, tracking devices, etc.

One of our basic aims when designing a multimedia CALL package should be to provide learners with all the necessary tools that will encourage language awareness and enable them to discover the intricacies of language use for themselves.

3.8 Log-on, menus and hierarchy

First, we must consider what the functions of the entry screens are going to be. For example, we may wish to include:

The log-on screens will lead to a main menu screen, which will indicate the way in which the program contents have been organised, as well as being the gateway for the learner to choose the route s/he is going to follow. It is important to offer a default route to guide learners through the program, but without forgetting that one of the advantages of multimedia courseware is precisely its non-linear access to the materials:

The modern approach stresses the importance of guidance rather than control, offering the student a default route through the program as an alternative to browsing, and building in intrinsic rather than extrinsic feedback, so that the learner has a chance to identify his/her own mistakes. (Davies (1997:38) citing Laurillard (1993a))

See Section 8, Module 2.5, headed How to factor feedback into your authoring, on the distinction between intrinsic feedback and extrinsic feedback.

It is essential that a clear indication is given of what the program contains and how big it is. Students and teachers are used to flipping through text books and gain a good idea, with just a first glance, of what the book contains, but in multimedia courseware this is normally not the case because most of the contents tend to be hidden. To illustrate two different ways of presenting contents and structure, let us have a look at the main menu screens of Español Interactivo and Español en marcha.

In Español Interactivo, as we can see below, the contents are organised into five modules (Figure 1), each dealing with a given topic and each module is in turn divided into four study units (Figure 2), each relating to a particular sub-topic. Having chosen a unit, the learner is offered the learning goals underlying that unit and is presented with the activity contents screen (Figure 3).

Figure1 Figure2 Figure3
Figure 1: Modules
Figure 2: Units
Figure 3: Activities

Each activity contents screen within the program is arranged according to four main sections (video, language functions, grammar and vocabulary), and the activities within each section are related to the main topic underlying that study unit. Organised thus, it is intended that learners will follow the suggested progressive order and focus on the language components being practised in a given section. Thus the language skills to be practised are sequenced without stripping the language of its context.

Figure4
Another more direct way of presenting the contents to learners can be found in Español en marcha. Here, after selecting the support language, the main menu page displays five main sections - culture, video, vocabulary, grammar and conversation - and the exercises are arranged according to their primary focus, although in many cases they are interrelated. Each of these menu items gives access to a contents page listing all the activities. This method of arranging contents is generally preferred by teachers who intend to use the package as a complementary aid to their regular classes, since it allows them to visualise the contents of the program in a more straightforward way than the previous example, which is more learner-centred.
Figure 4: Main menu screen in Español en marcha

When designing multimedia language courseware we must bear in mind what technology has to offer and how to make the most of it to the advantage of our students. Great care must be taken in drafting the global structure of the courseware, taking into account all the links, resources, utilities that we are going to include - all of which have to be consistent throughout the program. The hierarchy of all the elements must be clearly structured to serve two basic aims:

  1. to allow the programmer and graphic designer to visualise the entire program,
  2. to allow the language specialist to balance the contents, whether these are reference sources or activities. A common way to go about this is by creating a tree diagram specifying each of the elements integrating the hierarchy.

A hierarchical structure will also be indispensable to determine the program's navigation system. Due to the intricate structure of CALL courseware, menus and sub-menus have to be clearly specified and back tracking options given so that our learners do not get lost in the program maze. To this end a pull-down menu item or an icon should represent the following four actions:

3.9 Reference materials

It is always advisable to allow access to all the reference materials at any point in the program. Among the more common items that are included, we might find:

Linking these reference sources to the activities can be achieved very easily by including icons on the exercise screen that will call up a particular reference item. In the example below we can see a number of button icons representing four reference books. These can be accessed either from within an exercise to respond to a particular question which may arise during the study process, in which case an additional window opens up instantly revealing the relevant explanation (which also saves time in having to look up an item in an index page), or they can be approached individually as self-contained sources in their own right and comprise their own navigation system by means of hypertext links. In writing these reference materials we should aim at including only what is relevant and appropriate for the course level and avoid superfluous explanations or lengthy discourse that does not match the linguistic features exploited in the program.

Figure5 Figure6
Figure 5: Grammar exercise taken from
Español Interactivo
Figure 6: Detail of reference sources

 

3.10 Utilities

The utilities provided in the program must also be consistent throughout. There are, of course, a large number of items that prove useful to learners. These can be presented either by means of icons discretely located on the screen or as a pull-down menu such as the ones found in any Windows-based program. Among the more useful ones are:

Figure7
Figure 7: Icons representing program utilities in Español Interactivo

It is inadvisable to use an excessive number of button icons, which might end up overcrowding the screen, and we recommend that icons always appear in the same place throughout the program. The graphical user interface must be as simple and as intuitive as possible.

3.11 Student recordings, audio and video

It is always beneficial to provide some sort of recording device - often referred to as a media player - that will allow learners to record their own utterances and compare them with pre-recorded models or provide graphical representations of their language input. Some of the more entertaining activities are those where students can insert their own recorded versions of a dialogue, for example, and listen back to their own version in an attempt to simulate “real life” communication: v. the Encounters series of CD-ROMs. See Section 2.2.1, Module 2.2 , headed Media players, for further information on media players.

Interactive exercises can be based on audio fragments, accompanied by illustrations or pictures, or complete video sequences. They can focus on pronunciation practice at word, sentence or discourse level. Creating exercises based on dialogues and requesting students to play the role of one of the characters is one way of simulating authentic communication in a CALL program. These exercises are also very appropriate for pair work or collaborative learning - e.g. we can request two students to record themselves and recreate a given dialogue completely. Simulations between more than two or three characters are inadvisable to avoid interference on language retention.

Below are two examples taken from Valencià Interactiu. Figure 8 illustrates the recording device linked to all the interactive exercises, and Figure 9 shows the video recording "studio" linked to video simulation activities. The utterances recorded by students can be stored, for the learner's future reference or for the tutor's supervision, in the temporary file directory, although tutors must be reminded to delete these files now and then in order to save space on local hard drives.

Figure8 Figure9
Figure 8: Activity audio recording utility
Figure 9: Video synchronised audio recording utility

A student recording device - or media player - in a CALL package should include such functions as:

CD-ROMs and DVDs allow the storage of large amounts of audio, so we should take advantage of this and include as much sound as possible in our courseware. It is highly beneficial to expose learners to authentic language. Audio can be included in innumerable ways, with or without text reinforcement, to present instructions, feedback, glossaries etc., and will enhance the program features considerably. Small amounts of audio can be recorded digitally and stored as an audio file in a variety of different formats, e.g. .WAV or .MP3. The .WAV format takes up a good deal of storage space, however, but .MP3 is a compressed format that is far less greedy in terms of the space it occupies. The minimal audio specifications for reproduction on a standard PC would be: a sampling rate of 11.025kHz mono and a 16-bit resolution. See Section 2.2.3.3, Module 2.2, headed Sound recording and editing software.

An important factor concerning audio is the quality of the sound recordings. We recommend recording large amounts of audio at a professional studio with professional actors - which can work out cheaper than working with amateurs who may have to do numerous retakes over several days. When writing the materials, it is important to keep careful track of which texts have to be spoken by a female or male voice - or in different accents, e.g. British or American English.

The cost of video production can in many cases be decreased by using chroma key background settings in a studio rather than filming on location. This also has the advantage of allowing more control over the sound quality and avoiding unwanted noise from cropping in. Video can sometimes be replaced by using a sequence of synchronised still pictures and audio. The effect for language learning purposes can be remarkable and it is considerably cheaper.

3.12 Feedback

One of the advantages of multimedia technology is the computer's immediate response to a touch of a key or a mouse click, which is very useful when dealing with feedback in reaction to the learner's performance in completing an activity or exercise. Learners, we have observed, tend to find it encouraging to read or hear immediate positive feedback when they have completed an exercise successfully. A considerable variety of text, audio or text and audio messages can appear/be heard at random and graded according to learner achievements. In a number of exercises feedback can be programmed depending on the number of attempts and a specific score given to each of these. We can include appropriate feedback for a "correct answer", a "partially correct answer", an "incorrect answer", or even exercise-specific feedback when a combination of options is required in order to complete an exercise successfully. An adequate way of offering positive feedback, for example, could be to have the audio file of a particular exercise play when a correct answer is given. Feedback, of course, has to be meaningful - and, if possible, intrinsic rather than extrinsic. See:

If extrinsic feedback is used it should always be clear what kind of mistake has been made, and the feedback should provide not only awareness as to where the mistake lies, but also how to improve the learner's performance. Wherever possible, one should avoid abrupt statements such as "No", "Incorrect, try again", but instead provide constructive criticism and try to anticipate and predict our learners' behaviour when completing an activity. This may be achieved by carrying out - prior to the design stage - an error analysis based, for instance, on L1 interference.

See Laurillard (1993a) and Bangs (2003).

3.13 Progress reports

Simple activity-based progress reports, or more elaborate student assessment reports, are of great value for both autonomous learners as well as for tutors intending to supervise their students' work. A simple scoring device indicating the number of correct answers out of a total can become a challenge that some students find motivating. In addition to the scoring device, we may choose to include a chain of score-dependent comments also aiming to encourage the learner to progress further.

Figure10 Figure11
Figure 10: Student assessment - session report
Figure 11: Student assessment - activity report

Figure 10 is an example student assessment report taken from Español en marcha. The report summarises:

It also includes a table, indicating for every session:

Figure 11, also taken from Español en marcha, illustrates a more detailed activity-based report. In addition to the information described above, the learner or the tutor can further scrutinise the results achieved in a given exercise and instantly see where the difficulties may lie. For the benefit of autonomous learners, a link from a given activity report to that particular activity is beneficial as it saves time in having to search for it through the contents menus.

Students are very keen on testing themselves and enjoy the challenges of being given a time limit. Another other useful way of monitoring learner performance is to create activities that are time dependent. These activities are especially suitable for pre- and post-level achievement tests. A choice of time limits can also be given for a set number of questions in order to provide different levels of difficulty.

3.14 Exercises

When designing exercises for a CALL program we must ensure variety, coherence, and consistency. Our materials must be based on sound pedagogical principles and firmly grounded on the methodology/ies we have chosen to follow. An attractive graphical user interface will enhance these qualities. We should try to avoid simply transforming typically textbook-type exercises onto a screen and instead try to be as creative as technology (and the programmer) will allow us. Because technology moves so fast it is essential to look ahead towards the future and try to envisage what the new trends might bring about in computer assisted language learning.

One thing to bear in mind when writing exercises is that many of the more traditional activities such as multiple-choice and gap-filling exercises can be designed to function according to several modalities. For instance, a gap-filling exercise could also be designed as a multiple-choice exercise if the learner has to fill in a blank from a list of given options, or as a drag-and-drop exercise if the learner has to select an item from a given list and drag it into a blank space. It is therefore advisable to combine as many different modalities of a sole exercise type in order to avoid repetitions that could perhaps result in our learners' boredom. See Section 3, Module 2.5, headed A sideways look at authoring protocols for language learning. To put it schematically and focusing only on how an activity operates, a simple gap-filling exercise at word level in a given sentence, for example, could appear on screen in any one of the following ways:

  1. Audio feedback. Learner types a whole word in a blank space. Learner hits enter key to check answer. If correct, audio recording is heard (positive feedback). If incorrect, appropriate negative feedback.
  2. Learner types a whole word in a blank space, choosing from a given list. If correct, audio recording is heard (positive feedback). If incorrect, space goes to blank again. Negative feedback.
  3. Out of a number of options, learner drags and drops choice into blank space. If correct, audio recording is heard (positive feedback). If incorrect, space goes to blank again. Negative feedback.
  4. Multiple choice: learner clicks on appropriate word from a given list. If correct, word appears in sentence and audio is heard (positive feedback). If incorrect, negative feedback.
  5. Learner clicks on blank space and a window displays a number of options. Learner moves pointer to select option. Selected word fills blank space. If correct, audio is heard (positive feedback). If incorrect, negative feedback.

In open input exercises (See Section 5.9 below) where learners are requested to type in text (i & ii above) rather than choosing from a number of options - (iii), (iv) & (v) above - it is acceptable to allow learners to make mistakes as long as we provide appropriate feedback and encourage a further attempt - which is a process similar to that found in spellcheckers where incorrect/unknown words are highlighted but not automatically corrected for us.

Although the above modalities belong to a sole exercise type - filling in a blank - the learner is under the impression that the exercises are completely different. Using a combination of these therefore contributes towards variety and diversity in our materials. The choice of one or another modality will, of course, depend on the primary objective of the activity itself. We should always ask ourselves what the learner will gain in terms of language acquisition. If we cannot find a suitable answer to this question, then the activity must be reconsidered.

Consider, for example, modality (i) above. This type would be appropriate if it followed an "observation activity" - a passive activity in the sense that we may request the learner to observe, for instance, a grammatical structure (e.g. comparing both forms of the verb "to be" in Spanish, ser and estar), and then ask him/her to participate more actively, to further explore the use and meaning of language, and to write the appropriate form of either verb, providing perhaps a hint but with no options to choose from. Here we are asking the learner to actually write, allowing him/her to make mistakes, and to put some effort into memorising all the possible verb forms. If the learner has to write the word in response to an audio stimulus, s/he will additionally have to listen, interpret and then react by writing the correct verb form. This modality is better suited for more advanced language practice.

In examples (ii) to (v) above, there is no initial audio stimulus. Instead the audio sequence becomes the positive feedback when the correct answer has been given. This does not mean that there is no stimulus for the learner to react to. We could obviously include sound or illustrations to prompt our learner. The difference, however, between modality (ii) and modalities (iii), (iv) and (v) lies in the fact that in the former the learner again has to write (and there is therefore more at stake), whereas in the other three a mere choice of option is requested. These modalities are better suited to lower level language practice. In Section 5 we discuss different exercise types in more detail.

The many combinations of elements available in multimedia - text, audio, graphics and video - allow writers to create appropriate exercises/activities that suit a particular learning need. Computer assisted language learning is particularly suited to a communicative approach to language acquisition. Language can be presented both in terms of its structures (grammar, vocabulary, etc.) as well as in terms of its communicative functions: thus, our students will be able to learn linguistic structures, establishing relationships between structural and communicative functions in order to develop communication strategies in the target language. The functional and structural content of the courseware can be designed to encourage a range of communicative skills, bearing in mind that these are carried out within a specific social and cultural context.


4. The template approach to authoring

This section looks closely at the template approach to designing and creating a multimedia CALL package. Templates are also meantioned in Section 6, Module 2.5, headed Language-specific tools for a multimedia age. The approach descibed in this module is rather different, in that templates themselves can be developed by the programmers to cover a more dedicated range of functions. But the principle is still the same - content and functionality are separated, so that the subject specialist - known in technical jargon as the content provider - and the programmer can work independently for a large part of the development process, provided that a solid design document has been produced from collaboration at the earliest possible stage.

The task of the content provider in a CALL development project is not just to write texts in the target language. His/her job includes a range of other tasks: e.g. to write items for a range of different exercise types, to specify pictures that should accompany texts and exercises, to write scripts for audio and video recordings, to specify how the learner should progress through the program, etc. Some of these tasks clearly go beyond the simple provision of materials, and concern pedagogical issues. This falls under the heading of instructional design.

The task of the programmer is to make everything happen according to the wishes of the content provider/instructional designer. It is therefore essential that the designer spells out in precise detail what is to appear on screen and what should happen as the learner interacts with the program - in other words, a full description of what is known in technical jargon as an event. The programmer can advise on the feasibility of certain events, indicating to what extent the content provider's wishes can be carried out within the budget and time constraints of the project. The designer and programmer have to agree on the exercise types, reference materials and overall functionality of the courseware. This is best done by creating an instructional design document at an early stage. The main interactive design that the programmer will use is based on this document. To this end a set of templates have to be worked out, into which the content provider slots the texts and other resources (feedback, help notes, etc.), and clarifies to the programmer how the different building blocks of each event are to be assembled. A template looks rather like a form that has to be filled in, providing the programmer with the essential information that he/she needs in order to assemble the building blocks - known in technical jargon as assets. The assets of a CALL package might consist of:

These assets are normally created and held outside the program itself. For example, a word-processor might be used to write texts and exercise items, and photographs might be taken with a digital camera, manipulated with a graphic design package, and stored in JPG format. The advantage of holding the assets outside the program is that they can easily be altered without the intervention of the programmer. The content provider may, for example, find a number of typing errors in a text. These can be corrected in a word-processor and then the revised text file can be handed over to the programmer for incorporation into the program. Similarly, the graphic designer may need to crop or retouch a photograph, or even replace it with a completely different photograph for a particular event - all of which can be done without constantly referring to the programmer. The task of producing different language versions is also made easier, as translators can simply create a new set of text files in the required new target languages.

A system of labelling all the events and assets has to be agreed, each event and asset being given a unique label, i.e. a name and/or number, so that it is clear what is being referred to. As an example, a labelling system could perhaps consist of:

This makes the label look something like E5100310.wav, meaning this is the 10th audio file in Exercise 3 of Lesson 10 in Module 5, in an English language package. It is advisable to keep the labelling system down to eight characters to avoid incompatibilities with some programs and operating systems.


5. Template examples

In the course of the initial process of consultation, the content provider and programmer will draw up a list of activities and exercise types. These may include:

The above list of templates is only a small selection of the many templates that linguists/content providers and computer programmers might use in order to design a CALL package. The authors of this module are aware of over 30 possible combinations of elements (audio, text, graphics and video) in a CALL program. By making discrete use of this huge choice it is possible to create attractive exercises and activities that enhance the interactive quality of the final product, avoiding repetitive and monotonous exercises that decrease students’ motivation. All the elements that comprise a multimedia package are interconnected, so the templates must contemplate every single feature that appears on the screen at a given moment, e.g. links to and from exercises to reference materials, media to be included, etc.

The following descriptions illustrate the type of template design documents that can be developed for rapid integration of content. These may take many forms, but those shown here are typical.


5.1 Multiple-choice exercises

Virtually all CALL packages include multiple-choice exercises, which may take a variety of forms, e.g.

The combinations of question and answer can also take several different forms:

Multiple choice exercise types can also differ considerably according to the nature of the feedback presented.

Sample multiple-choice (single-selection) exercise taken from Español Interactivo:

Espanol_Interactivo1

This exercise belongs to Module 2 En la ciudad, Unit 2 En el mercado, where situations dealing with "going shopping" are practised. Here, the difference between both forms of the pronoun "you" in Spanish are being distinguished.

The default mode is with no text. There is an audio stimulus to prompt the learner (e.g. Buenos días, ¿tiene tomates?) to click on one of the two options provided -"tú" or "usted"- according to the form heard in the audio. Once the appropriate option is selected, positive feedback is offered as we hear the salesman respond to our question and a picture of the requested item appears on the shop counter. Instructions are given in audio although written versions, both in the support language and the target language, are available by clicking on the help button icon.


5.2 Gap-filling exercises

Virtually all CALL packages include gap-filling exercises - which may take a variety of forms, e.g.

Sample gap-filling template taken from Español en marcha:

Template type: Gap-filling (learner types text)

Identification label: G5_11

Back menu: ind_gram (Grammar exercises index screen)

Section: Gramática

Exercise: Hemos llegado esta tarde

Instructions: Escribe en el recuadro el pretérito perfecto del verbo correspondiente. Cuando hayas completado correctamente todos los huecos, oirás el diálogo. Pulsa sobre el icono de "volver a escuchar" para oír el texto de nuevo. Consulta el libro de gramática para repasar la teoría. Acuérdate de acceder al "estudio de grabación" para practicar tu pronunciación.

Text with gaps:
1.
Oficial: Lo siento, pero el el tren [GAP 1] hace 35 minutos.
Pasajera: No es posible. [GAP 2] esta mañana y un compañero suyo me [GAP 3] que el tren salía a las seis.
Oficial: Lo siento mucho, pero no puedo hacer nada.

Correct answers:
1.
Gap 1. ha salido
Gap 2. he llamado
Gap 3. ha dicho

Positive feedback:
- After each gap is successfully completed: randomised positive audio reinforcement.
- After whole sequence is successfully completed: audio sequence is played.

Negative feedback: Wrong answers will be slotted in gap but highlighted in blue for learner to select and retry.

Number of tries: Unlimited by reselecting gap.

Pictures/graphics:
1. Young lady speaking to train station official.

Picture/graphic source(s):
1. G5_1101.bmp

Audio source: To be heard as positive feedback
1. G5_1101.wav

Icons on screen:
-
Activity-specific: Start, next, replay audio, cancel selection, show answer
- Program-specific:
Close
Video
Notepad
Dictionary
Progress report
Recording studio
Help
Grammar
Functions
Culture
Exit

Grammar notes: Link to page 24 in grammar book.

Functions: Link to index page.

Culture: Link to index page.

Programming instructions: All 10 dialogues will be available in "recording studio" for learner to practise pronunciation.

Screen layout:

En_Marcha


5.3 Language lab and prompted speaking activities

This type of exercise became possible with the advent of the MPC and now features in most CALL packages. Early language-lab exercises on MPCs were based largely on traditional three-phase and four-phase drills but more imaginative exercises have been designed: e.g. the role-plays in Encounters and the exercises using Automatic Speech Recognition (ASR) in Talk to Me and Tell me More - see the following Web pages for descriptions and screenshots of these CD-ROMs:

For further information on ASR see:

Language lab activities are useful when we want students to record their own voice and compare it with a pre-recorded model. The recorded model may range from isolated words, sentences or larger units of meaning such as exchanges in a dialogue. An interesting type of prompted speaking activity was developed in France Interactive, combining a video sequence and student voice recording. The template takes the following form:

Template type: Prompted speaking

Identification label: S00000

Associated activity: To indicate the exercise that this activity is based on and provide the appropriate link.

Section/Module: To indicate the section or module that this exercise belongs to in relation to the whole course.

Lesson/Unit: To indicate the lesson or unit that this exercise belongs to within a given section/module.

Activity/Exercise: Name of activity/exercise as it will appear on screen.

Instructions: Text/audio/text & audio instructions to carry out exercise. Aim of exercise. Learning goal. Tips.

Audio/Video script: Text of audio or video script.

Audio/Video source: Audio or video source file corresponding to complete script.

Pictures/graphics: Accompanying pictures/graphics to illustrate audio script when a video source is not used.

Picture/graphic source(s): Source file of accompanying pictures/graphics.

Icons on screen:
- Activity-specific: These will refer to the necessary icons to record, play and compare student recordings such as those described in Section 3.10 above.
- Program-specific: Any other icon which has to appear on screen such as: close window, exit program, etc.

Pull-down/icon menu items:
Dictionary
Print
Progress report
Use of language notes
Advice

Use of language notes: To be provided here, or reference made to an appropriate link.

Advice: In the form of learning strategies to help learner. To be provided here.

Programming instructions: Comments to help the programmer understand how the exercise works.

Screen layout: Draft of screen layout taking into account all the elements to appear.


5.4 Clickable text on screen

Clickable text on screen is a useful feature of CALL packages, allowing the student to call up a dictionary or grammar notes simply by clicking on words and phrases on screen. In the Encounters series of CD-ROMs the program code (which was written in Authorware) was designed to read a script in which each line of the dialogues presented to the learner was annotated. Composing the scripts was a straightforward process, using a standard word-processor. The following is a node of information from one of the scripts:

... und nehmen Sie die dritte Straße rechts.
... and take the third street on the right.
g7_5.wav
nehmen, Sie, die, dritte
24, 24, 10, 42

The first and second lines of the above script contain the German text of one line of a dialogue and its translation into English, which the student can call up by clicking on a “translation” button at the top of the screen. The third line is a reference to the sound file containing the spoken German text, which the student can hear by clicking on a loudspeaker icon to the left of the line of dialogue. The fifth line contains the words that are to be annotated, and the sixth line contains references to the notes that will appear on screen if the student clicks on any of these words. Thus, clicking on either nehmen or Sie will call up Note 24 on the imperative forms of verbs, which is part of a large text file of grammar and background notes. The number 24 is simply a pointer to the appropriate place in the file. Again, the grammar and background notes were composed by the content provider in a word-processor. Here is the actual Note 24:

Imperative forms of verbs: Sie and ihr forms

The imperative familiar plural is formed thus:
Take the 2nd person plural (ihr form) of the present tense and remove the word ihr:

Infinitive

Present

Imperative

bringen

ihr bringt

bringt!

sprechen

ihr sprecht

sprecht!

The formation of the imperative formal (when saying Sie) is simple:
Take the Sie form of the present tense and turn the words around.

Infinitive

Present

Imperative

gehen

Sie gehen

gehen Sie!

nehmen

Sie nehmen

nehmen Sie!

Similarly, a click on die will call up Note 10 on the accusative case, and clicking on dritte will call up Note 42 on ordinal numbers. Some of the notes relate to background and usage rather than grammar, e.g. the note on greetings:

Greetings

guten Tag is one of the most frequently used forms to greet people.

Others include:
guten Tag! - hello, good day, good afternoon
grüß Gott! - hello, etc. (mainly used in South Germany and Austria)
guten Morgen - good morning
guten Abend - good evening
grüß dich! - hi! (informal)
hallo! - hi! (informal - and "hello" on telephone)
servus! - hello or goodbye (common in the South)

guten is often left out - as in English "morning" instead of "good morning".

Whilst the process of creating the scripts and grammar and background notes for Encounters was very straightforward, requiring no programming expertise on the part of the content provider, such a structure could be error-prone, and this could be avoided by the creation of a graphical interface or sets of boxes into which a node (see above) could be inserted.


5.5 Clickable image on screen

A recent example of this type of activity can be found in wordPROF, whereby the learner clicks on various parts of the screen, e.g. calling up items of vocab to be learned. One of the first packages to implement this kind of activity was Just Grandma and Me in Broderbund's Living Books series, first published in 1993. A later package in the Living Books series, The Tortoise and the Hare, developed the technique even further. See Section 3.4.2, Module 2.2, headed CD-ROMs for young learners.

This exercise type may be used when students are requested to click on a number of "hot spots" on a picture or image or click on a number of picture items, in reaction to a written or audio stimulus. For example, an activity to practise locations, where a map is displayed, and after hearing an audio stimulus, the learner has to click on a specific place/item on the map. A less active modality of this exercise type is useful for introducing new vocabulary - having learners click on a picture or a selected area of a larger image with the effect of an audio fragment being heard and, optionally, its written version being displayed.

Sample clickable image template and exercise taken from Español Interactivo:

Template type: Clickable image on screen

Identification label: M3U3F1

Back menu: Activity menu screen in Module 3, Unit 3 (M3U3)

Module: Módulo 3 - Estamos aquí

Unit: Unidad 3 - ¿Hay algún supermercado?

Exercise: ¿Sabes dónde voy?

Audio instructions: Averigua a qué ciudad se dirige este personaje. Escucha las indicaciones y después haz clic sobre las ciudades de destino.

Text and audio stimulus:
Item 1.
Me dirijo hacia el este por la Nacional III desde Madrid y cuando llego a Valencia cojo un barco que me lleva a la ciudad elegida. ¿Sabes dónde voy?

List items:
Item 1: Palma de Mallorca

Audio responses:
Item 1: Madrid - Palma de Mallorca

Picture/graphic(s): Map of Spain

Picture/graphic source: M3U3F101.bmp

Audio source: M3U3F101.wav

Number of tries: Unlimited

Correct answers: Same as audio responses.

Feedback: Text/Audio/Text & audio

Icons on screen: Start, next, replay audio, close window, exit program

Icon menu items:
Functions
Grammar
Dictionary
Help
Show text
Notepad
Sound off
Progress report
Recording studio

Grammar notes: Link to index page.

Functions: Link to page 39.

Interactivo_Image2

Programming instructions: Audio and script available in "recording studio".

Screen layout:

Interactivo_Image3


5.6 Matching exercises

In this type of exercise learners have to match two lists of items in any of the following combinations:

The association of elements can be carried out by moving the second list of items to match the first list or, alternatively, both lists may remain static on the screen and matched by clicking consecutively on one and another item and indicating correct match by means of, for example, arrows or simply playing an appropriate audio sequence. The matches can of course be one-to-one (single-selection) or one-to-many (multiple-selection). The above combinations provide a considerable number of variations so as to allow writers to create a fair amount of entertaining as well as didactically efficient activities.

Sample single-selection matching exercise taken from Valencià Interactiu:

Valencia_Interactiu2

This exercise belongs to the section devoted to past-times, Jocs. It is the second part of an exercise that introduces the meaning and use of certain idioms: "Frases fetes". The learner clicks on an item from the list on the left, hears it, and has to match it with the appropriate meaning from the column on the right by dragging it over the screen and aligning it with the selected idiom on the left hand side. If the match is correct, the learner immediately hears a randomised positive audio reinforcement and the selection fades to indicate that the option is no longer active. Incorrect matches are indicated by hearing a randomised negative reinforcement.


5.7 Drag-and-drop exercises

Drag-and drop exercises are key feature of many CALL packages. Strictly speaking these are computer interactions rather than exercise or template types in themselves, as virtually any type of exercise can be presented as a drag-and-drop activity, e.g.

Sample drag and drop exercise taken from Valencià Interactiu:

Valencia_Image2 Valencia_Image3

This exercise belongs to the grammar section, and is the first in a series of five activities devoted to distinguishing vowel sounds. The screen on the left above shows the entry screen. The student sees before him/her pictures representing the word that has to be dragged into an appropriate box according to its vowel sound. If successfully completed, the picture is transformed into its written form and a voice pronounces it. If unsuccessfully completed, negative feedback is provided. Unknown words can be looked up in the dictionary, and the grammar book can be consulted upon request.


5.8 Reordering exercises

Reordering, or putting a number of items in their correct sequence, can take several different forms:

Sample reordering exercise taken from Español Interactivo:

Interactivo_Image4

This exercise, Ordena la frase, belongs to Module 3, Estamos aquí, Unit 4, Ciudades y pueblos. It is designed to practise word order at sentence level. Instructions to carry out the activity and its aim are heard on entering, as well as being available in the help window. The learner is requested to move the stepping stones (words/expressions) so that our mascot Flaudio can walk across them. Positive feedback is provided by means of an animation - Flaudio successfully walking across the stepping stones - and the audio sequence is played. Help is given by listening to the sentence, which can be replayed as many times as required. The solution can be called up by clicking on the " tick" button icon. Access to all reference materials is provided, including the dictionary to look up unknown words.


5.9 Open input exercises (free text entry)

Open input exercises, also known as free text entry exercises, have become less popular in recent years. The programming skills that featured in programs such as CLEF and TUCO in the late 1970s and early 1980s seem to have been lost in the mists of time. Both these packages contained open-input gap-filling exercises, and the programs were cleverly designed to analyse the student’s input and to respond to mistakes. Nowadays it seems that most CALL programs embody a point-and-click-let's-move-on-quick approach, without expecting the learner to reflect on his/her errors.

CLEF has recently been revamped in a new Windows version: http://www.camsoftpartners.co.uk/clef.htm. In an exercise on French verbs in CLEF the expected answer might be je voudrais. If the student types "je voudrait", he/she receives a message indicating that there is something wrong with the ending, giving the student a chance to identify the error - if necessary by consulting verb conjugation tables.

TUCO was programmed to respond to certain types of anticipated errors. For example, if the student wrote "Ich setzte mich auf das Bank", the computer would respond by indicating that the case of the definite article was correct after a verbal phrase of movement towards a location but that the gender was wrong.

The designers of CLEF and TUCO had to anticipate possible errors and write a range of appropriate comments depending on the nature of the error – quite a tedious job, but one which can be carried out by the content provider using an appropriate template. It is, however, possible for a competent programmer to write a generic input analysis routine so that certain kinds of errors are automatically picked up.

Missing diacritics can be dealt with by a very simple input analysis routine. If the anticipated answer to a question is "café" and the learner types "cafe", the input analysis routine picks up the missing accent and gives the learner feedback such as "You have missed out an accent" or highlights the "e" as requiring a diacritic.

Simple spelling errors can easily be handled by a computer program, even when there is a range of acceptable answers. This is a key feature of Camsoft's GapKit. GapKit is able to match the student’s input with a range of possible alternative answers, homing in on the correct answer that most closely matches the student’s input. Let’s suppose that there are two possible answers to a question: Stuhl or Sessel (“chair” or “armchair”). If the student types “Stul” the program will automatically recognise that the student is aiming at the first alternative answer, Stuhl, accepting the first three letters as correct and indicating that the ending is wrong. If the student types “Kessel”, the program will recognise that the student is aiming at Sessel and indicate that only the first letter is wrong. If the student types “Sassel”, the program will indicate that only the second letter is wrong. The teacher who provides the content for GapKit does not have to do anything other than type the questions and a set of alternative answers. The program does the rest. This automatic analysis technique also works with short phrases, but the results can be unpredictable with longer phrases or complete sentences - see the next paragraph.

Now we get on to the clever stuff - all of which was embedded in CALL programs written back in the 1980s. If the student is asked to transform a sentence and input the whole transformed sentence as an answer, then you need a more sophisticated input analysis routine to pick up all the possible errors and to accept correct alternative answers. One approach is to parse the learner's input automatically, which works to a limited extent. Attempts have been made to develop automatic parsers - intelligent tutoring systems - that analyse the student’s input and indicate to what extent it is correct: see Section 8, Module 3.5, headed Parser-based CALL, and Heift (2001). Parsers have their limitations, however. For example, a parser could perceive the sentence “Beautiful green ideas sleep furiously” as grammatically correct even though it does not make a lot of sense. Another approach is to anticipate alternative answers, but there may be hundreds of these. Authoring programs such as Wida Software's Testmaster were able to handle a range of alternative answers way back in the 1980s, with the minimum of effort on the part of the teacher. Let us look at an example exercise:

Rewrite the following sentence, beginning with the words This is the first time
I have never had this kind of food before.

There are numerous grammatically and semantically correct answers to the above exercise that might be accepted by the teacher, e.g.

This is the first time that I've had this kind of food.
This is the first time I have ever eaten this kind of food.
This is the first time that I've tasted this kind of food.
This is the first time I have tried this sort of food.

Most of the acceptable answers can be anticipated by the teacher by expressing them in a string that might look like this:

This is the first time (that) I ['ve/have] (ever) [had/eaten/tasted/tried] this [kind/sort/type] of food.

The above string reflects the following table in which there are compulsory elements, optional elements and alternative elements within the answer.

Compulsory Optional Compulsory Alternatives Optional Alternatives Compulsory Alternatives Compulsory
This is the first time that I 've ever had this kind of food
have eaten sort
tasted type
tried

The appearance of such a string will vary according to the programming language or the authoring system used to produce the open-input exercise. Among existing programming languages, Perl is generally acknowledged as being quite efficient in string-handling, and its "regular expressions" are also available to other languages, e.g. Javascript. Teachers who use Javascript to author their own exercises may be interested in the routines developed by Joseph Rézeau to automatically generate valid answers from regular expressions: http://pagesperso-orange.fr/joseph.rezeau/eao/developpement/expandRegexpToString.htm

The above string (This is the first time...) is listed among the provided examples and you'll see that it generates no less than 96 acceptable answers!


5.10 Branching dialogues

Branching dialogues are a common feature in many CALL simulations. Such packages usually contain dialogues in which a character on screen interacts with the language learner, who plays a role in a dialogue or series of dialogues that can branch in different directions depending on the learner's responses. The learner chooses from a set of given responses in multiple-choice format, as open-input from the learner would obviously be difficult to analyse.

Expodisc is a simulation offering basic training in Spanish for exporters and covering both practical business language and social language skills. The learner is invited to prepare and participate in an export sales trip to Madrid. The learner