- Email: [email protected]
The Design and Evaluation of a Micro-Computer Based Authoring System for Trainers
Copyright {e IFAC Training for Tomorrow Leiden , The Netherlands. 1983
THE DESIGN AND EVALUATION OF A MICRO-COMPUTER BASED AUTHORING SYSTEM FOR TRAINERS N. Bevan and R. Watson National Physical Laboratory, Teddington, Middlesex, England
Abstract. An authoring system has been designed with the major criterion of ease of use, rather than ease of implementation. The microcomputer version, called Microtext, combines a frame-structured authoring language with a full-screen editor. The ability to switch immediately between running a lesson in student mode and editing material in author mode, makes it very easy for people without previous programming experience to produce their own training material. The evaluation highlighted the need to adjust established conventions within computer science to meet the needs of people new to computers. Keywords. Author languages; computer-aided instruction; human factors; programming languages; training; teaching; educational aids. makes it complicated to implement computer based training applications which are primarily concerned with presenting and manipulating information on the screen, and checking responses given by the user. The purpose of a specialised authoring system is to package the power of the computer in a form which is appropriate and convenient for implementing computer-based training material. For example, obtaining a student answer and then branching if it contains a specific word should be simple in an authoring system, but in a conventional language requires a complicated combination of instructions.
WHY AN AUTHORING SYSTEM? Much computer-based training material is written using conventional programming languages. There are, however, a wide range of specialised authoring systems on the market, which are designed to simplify the task of producing computer-based training. What are the advantages of these authoring systems, and why do some people choose not to use them? Using conventional languages, it is necessary for an expert to convey his knowledge to the trainer, who structures it as a dialogue, and then passes it to a programmer for implementation:
An authoring system will incorporate a method of inputting text and instructions in author mode, and a method of presenting text and executing instructions in student mode. It should both improve the productivity of the experienced programmer, and make the computer more accessible to non-programmers. A good system will enable courseware to be produced in a form which is accessible to the trainer and instructor for comment and amendment. It may even be possible to dispense with specialist programming skills altogether and to combine the roles of trainer and programmer into a single Author:
EXPERT I
'\V
TRAINER
<------> INSTRUCTOR
~
A,-
I I
I
Y
Y
I
PROGRAMMER
TRAINEE PROGRAM
This is a good division of skills in a well-organised and well staffed department, but any feedback from the instructor must be passed back to the trainer who consults the programmer to arrange implementation. This procedure for making alterations may be inconvenient, and the original intentions can easily become distorted.
EXPERT ~
AUTHOR
<------> INSTRUCTOR .1} I I
"
TRAINEE Most conventional languages have been designed primarily for calculation and data manipulation, and to handle text line-by-line. This
PROGRAM
189
N. Bevan and R. Watson
190
This arrangement can significantly simplify the organisation of a computer based training department, by reducing the number of individuals required to write and evaluate new training material. The author can respond immediately to feedback from the instructor, without having to wait for the programmer to implement suggestions. It may also be possible for instructors to tailor the training material to their own individual requirements. However, all languages impose constraints. Thus for example the awkwardness of string handling in FORTRAN means that FORTRAN programmers will, whenever possible, design their interactive applications to ask questions with numeric answers. Similarly the user of an author language will bend his application to make it convenient to implement within the constraints of the language he is using. This bending may not be deliberate, but the result of structuring the problem to use the particular range of facilities which are provided, and with which the author becomes familiar. This tailoring of applications can make comparison of different authoring systems very difficult, as an application written using one language will almost certainly be optimised to take full advantage of the peculiarities of that language. Just as the best translation of poetry is not a literal one, so the translation of a training application will require fundamental rethinking. The most extreme case is the author who writes in assembly language on a microcomputer. If he aspires to produce applications which use the machine in a dynamic and creative way, emulating the best computer games, the applications will almost certainly be totally unimplementable in any other context. The enormous productivity gains to be obtained from a good authoring system normally justify the inevitable constraints. What is important is to ensure that there is an appropriate compromise between productivity and the range of application of the system. APPROACHES TO AUTHORING Some computer-based training material is still written in assembly language, and adherents of this approach maintain that this is the only way to gain access to the full power of the machine. It is true that certain dynamic simulations are very hard to implement in any other way, although it may be much simpler to use a system which supports assembly language subroutines, rather than write the complete application in assembly language. Training material is often written using the "standard" language for a particular computer, since it is familiar to the programmers, and supports a wide range of features on the
machine. On microcomputers this language is usually BASIC, and on larger scientifically oriented machines it is frequently FORTRAN. These conventional languages present a number of problems. As indicated above they make certain common training requirements unwieldy to implement, and may therefore encourage a poor style of training. They may also be inappropriate for the implementation of large packages of material. In languages such as BASIC large programs can evolve a dense spaghetti-like structure which is difficult to understand and inefficient to execute. One solution is modular programming, but this is discouraged by the difficulty in many systems of passing variables between a series of linked programs. Once the requirement for a specialised authoring language has been established, there is still the problem of choosing which particular style of authoring system is appropriate. The different approaches to authoring can be divided into several categories: 1. Statement-oriented systems modelled on existing languages; 2. Prompting and menu-driven systems; 3. Systems offering a choice of fixed templates; 4. Frame-oriented systems. Statement-oriented Systems Typical examples of this approach are PILOT (Yob, 1977) modelled on BASIC, STAF (Ayscough, 1981) based on FORTRAN, and COMBAT (Mills & AlIen, 1982) modelled on PASCAL. The aim of these systems is to provide the power of the original language enhanced by features designed specifically for CBT. This generally makes them far more productive than an ordinary language, but only suitable for programmers who can grasp and manipulate traditional programming concepts. Prompting and Menu-driven Systems The intention of these systems is to provide guidance to the author at every step in the authoring process. Prompting systems such as Easywriter (Brown, 1982) prompt the user at every stage, and store the result in an intermediate form for execution. Authoring is easy provided the application fits within the constraints of the system. The end result can be very simple material which is not amenable to alteration. More sophisticated menu-driven systems such as WISE (Wicat Systems, 1982) give access to almost all features of the system from menus.
The Design and Evaluation of a Micro-Computer This greatly simplifies the production of potentially sophisticated material, although the enormous wealth of menus is initially intimidating, and may eventually prove unwieldy. Template Systems Template-based systems such as APT in TICCIT (Hazeltine, 1979) organise training around a number of forms representing pre-defined instructional strategies, into which specific material can be placed. The power of these systems depends to some extent on the range of templates, and the extent to which editing of existing material is supported. The major drawback is that training material is channelled into preconceived notions of appropriate presentation strategies. This limits the flexibility available to the author, and restricts the range of application of the system. Frame-oriented Systems The Prestel viewdata service in the UK is a simple example of a frame-based system. The major advantage of viewdata has been the standardisation of the screen format and communications interface, and the consequent wide availability of compatible systems and terminals. The very simplicity of the standard software makes it easy to use, and relatively easy to set up. But the programming facilities provided are rather primitive by normal CBT standards, limited to presentation of complete screens, and acceptance of numerical answers. Some private viewdata implementations have been considerably enhanced to provide the features necessary to support training applications. Viewdata holds the frames of text separately from the control structure which defines branching between frames, although the frame numbering convention does not aid understanding of how an application works. Other systems, such as ICL's internal training system (Clarke, 1982), name the frames of text, and reference these from a sophisticated control language. The total separation of text and control structure can encourage the use of general purpose frames rather than individualised dialogues. The Microtext system described below incorporates the control information at the top and bottom of each frame, in order to combine the simplicity of a frame oriented approach, with the readability of a simple programming language. Microtext is essentially a frame-structured language.
J9 J
ORIGINS OF MICROTEXT Microtext evolved from Mickie, the medical interviewing computer, (Bevan, Pobgee and Somerville 1981), developed in the 1970s. The aim of the Mickie system was to simplify the use of computers, both for the doctor/ programmer and patient/user. Mickie applications were originally written in BASIC, but as the programs grew larger, a data structure was adopted to store the text and minimal control information separately from the BASIC program which administers the questionnaire. Each block of text containing a question is numbered, and followed by the numbers of the blocks to which a branch can be made. The user's response determines which of the blocks is selected. This format of text and block numbers defines a separate language called Questext, which is easy for doctors and other non-computer professionals to set up using a conventional screen editor. Questext was extended to cater for educational and training applications with more varied requirements, and the resulting system called Edutext. It was successfully used for a variety of applications, but as the facilities were enhanced it became apparent that the Edutext interpreter written in BASIC was becoming too slow. A decision was taken to rewrite the interpreter in assembly language, so that it could be used on a range of small microcomputers. This microcomputer implementation has been called Microtext. STRUCTURE OF MICROTEXT The over-riding design aim of Microtext is to make simple things simple to do, so that an author can in a few minutes learn how to set up a simple branching presentation. At the same time Microtext incorporates a wealth of more sophisticated features so that as an author gains experience he can implement more complicated applications tailored to specific needs. Microtext has been designed to allow the author to concentrate on the content and flow of his material, and the authoring process is centered around editing frames of text on the screen. Microtext has diverged from many other authoring languages in attempting to make ease of use rather than ease of implementation the ultimate criterion for system design. The end result is a pragmatic compromise with a simple and concise syntax for the most frequently used facilities, complemented by plainlanguage commands to exploit specialised features.
192
N. Bevan and R. Watson
The language is unusual in that it has a frame-structured syntax. The unit of a frame is one which is easily understood, and in Microtext incorporates control information at the top and bottom. The example below shows the frame number at the top, followed by the text area, and a response checking region:
*1 Which is the most popular language used on microcomputers. ?
MICROTEXT-?2, BASIC-?3 ~
B: Neutral
{
{ text { {
C: Earth
(prompt) (responses) (end)
?
A
~
40, B
~
20, C
~
30
In this example the header line contains just the frame number prefixed by "*". This is followed by free-format text. The text is terminated by the line starting with "?", which prompts the user for a response. This is followed by checks for answers A, B, or C, which branch to frames 40, 20 and 30 respectively. The frame is terminated by a row of dots. This principle can be extended to more complex applications. The author will often choose to design his material using a flowchart. An illustrative example is shown below: I
I
---------------------->: Which is the most popular language used on microcomputers ?
MICROTEXT 2
No, it is a new language
(other)
BASIC 3
4
: Yes, well: : done
: No, BASIC : : is the most : : popular
I I
5
4
(response -? frame) (default branch)
(header)
*10 What is the brown wire in a mains cable used for? A: Live
(frame number 1)
I I
:<-----------
: That is the end : : of this lesson This example requires 5 frames. Each box on the flowchart is given a number, and then the text in each box is written as a frame of Microtext:
*2 No, Microtext is a relatively new language. -? 1
(go back to frame 1)
*3 (SCORE=5) Yes, well done. -? 5
(set the SCORE to 5)
*4 (SCORE=O) No, BASIC is the most popular. It is not. -? 5
(set the SCORE to 0)
*5 Your score so far is.
(ANS contains answer)
(contents of SCORE)
That is the end of this part of the lesson. -? 10 (next frame) **Score on languages **is. (copy to report) Microtext will display the text of the first frame, and then wait for the user to answer the question. If the answer is MICROTEXT it will branch to frame 2, if BASIC to frame 3, and if any other answer is given it branches by default to frame 4. Frames 2, 3 and 4 all branch on to another frame without waiting for any further user input. The last frame displays the value of the score, and also contains an item prefixed by ** which will be stored in the summary of the user's performance. The lesson continues with frame 10. DESIGN PRINCIPLES A major feature of the Microtext system is the integrated editor and language interpreter. This means that one can immediately switch between seeing the text in student mode, and editing both the text and control structure in author mode. A full screen editor is provided, and it is thus very easy for unskilled people to make minor changes to material. Text typed in by the author normally looks exactly the same as it will when it is presented to the user.
The Design and Evaluation of a Micro-Computer In student mode, the interpreter presents text and graphics on the screen, and accepts responses from the user. In the simplest applications the user will be responding to multiple choice questions , or just pressing keys with labels such as YES, NO and DONT KNOW. To avoid the complication of instructing the user to remember the RETURN key, Microtext can accept single character input, as well as longer responses. The performance of users can be monitored by incorporating summary items at the bottom of each frame. These contribute to a plain language report which can be archived, or printed at the end. Microtext has been designed to be easy to write and easy to correct. Errors associated with syntax and branching which are easy to make in a conventional language, are kept to a minimum in Microtext. The errors which do occur are almost always self-evident on the screen when the material is run. When the author is testing frames ambiguous syntax and other likely errors are highlighted for possible correction. In student mode defaults are taken whenever possible, to minimise the chances of the system failing. Variables can be used in Microtext to hold answers, to calculate scores, and to adjust presentation to individual requirements by modifying both the text and branching sequence. Although numeric values can be manipulated, the conventional distinction between numeric and string variables is rather artificial in the context of text presentation. Consequently all variables are of the same type, and both numeric and string operations can be performed on them as appropriate. Another innovation is to avoid the concept of variables as parameters, and expand the contents of variables directly into the line buffer. This means that variables can be used to replace or modify any part of the text or language syntax. This is particularly powerful when tailoring general purpose subroutines to precise requirements (although it is not a feature which should be used in haste!). A detailed specification of the Microtext system will be found in the Appendix.
193
Initial Barriers One of the most difficult problems to overcome when anyone is faced with a totally new environment is initial confusion and disorientation . Microtext is very easy to use once the basic principles have been grasped, and these can be explained in a few minutes. The problem with any new system occurs when users who cannot obtain personal assistance have to rely on the system itself and the associated documentation . Two steps were taken to remedy the situation . First an elementary introduction for beginners was written and a package of demonstration programs supplied. Secondly it was decided to incorporate built in help for the author. There had been initial reluctance to do this in view of the memory limitations on a microcomputer, but the solution was to incorporate a HELP OFF command to recover the space once the author became more experienced. System Modes It is particularly important that people new to programming grasp the distinction between writing a program, and running a program. In Microtext there are four distinct system modes: Command mode for file handling and entering other modes, Edit for writing text, Test for testing material, and Run for running in student mode. These modes were initially indicated by status messages on the bottom of the screen, and two manuals were provided: a guide to writing programs using the editor, and a guide to the language syntax which was obeyed when the programs were run. Many users had difficulty understanding the distinction between the modes, and the difference between the two manuals. Again both the documentation and system were improved. The manuals were rewritten grouping use of the system into functional units rather than arbitrary modes. On the screen the distinction between modes was highlighted by using a different colour status line for each mode. The system mode was then self-evident without even needing to read the information contained on the line. In the case of student mode the status line was dispensed with altogether, to give the author the freedom to use the whole screen in any way he wished.
EVALUATION Other Human Factors Evaluation of Microtext started early in 1982 and although only expected to take a few months, the cycle of alterations and enhancements lasted almost a year. A wide spectrum of authors including teachers, trainers, programmers, and students, reported their reactions. Although these were generally very favourable, some areas of difficulty were encountered:
In some cases it was necessary to adjust established conventions within computer science to meet the needs of the non-computer professional. For instance the modes of the system were originally called Edit, Text, Run, and Debug, but these were changed to Command, Edit, Run and Test, respectively. Error messages were reworded to remove jargon, and row and column numbers were altered to start at 1 rather than O.
N. Bevan and R. Ivatson
194
Many other changes were made to improve the robustness and user-friendliness of the system. For instance, protection was incorporated to warn the author if he attempted to take any action which would lose an edited module that had not been saved. The minimum abbreviations of commands was altered to ensure that commands causing deletions were always longer than other similar commands.
Mills & AlIen (1982). COMBAT system. Mills & AlIen Communications Ltd, London, UK. Wicat Systems (1982). WISE system. Systems Ltd, Birmingham, UK. Yob, G. (1977). 3, 57-63.
FUTURE PLANS The latest version of the system, Microtext V2.1, is now available on BBC and CBM microcomputers, and will be available for CP/M machines in late 1983. It includes commands to control peripheral equipment such as video-tape recorders and slide projectors. Although this version caters for a very wide range of users, the evaluation suggested that professional users require a larger and more sophisticated system covering a broader spectrum of applications. It is intended to produce a version called Microtext Plus, incorporating many detailed improvements in functionality and adding some significant new features. These will include floating point arithmetiC, the ability to name frames, an interactive graphics editor, and the ability to incorporate expert system techniques using production rules. CONCLUSION Microtext has demonstrated that it is possible to implement a very sophisticated system within the constraints of a 32K byte microcomputer, and experience so far suggests that it will prove a useful tool in a wide range of computer based training applications. Microtext is an example of tailoring the machine and its language to the needs of the user, rather than expecting the user to adjust to the arbitrary requirements of the machine. It is to be hoped that it will take its place in a future populated by a mass of machines adapted to the needs of the individual, rather than a mass of individuals adapted to the needs of the computer. REFERENCES Ayscough, P.B. (1981) . STAF Author Guide. Leeds University, UK. Bevan, N., P. Pobgee, and S. Somerville (1981) . MICKIE - A microcomputer for medical interviewing. Int. J. Man-Mach. Stud., 14, 39-47. Brown R.L. (1982). Easywriter. Manchester, UK.
Hazeltine (1979). Authoring Procedure for TICCIT. Hazeltine Corporation, Mc Lean , Va., USA.
NCC,
Clarke, M. (1982). Beyond Authoring Systems (paper presented at CBT 82) . ICL Ltd, Stevenage, UK.
PILOT.
Wicat
Creative Computing,
ACKNOWLEDGEMENTS The Microtext development group at the National Physical Laboratory also includes Steve Collins, Tony Mansfield, and Dianne Murray, and the implementation was carried out in conjunction with David Parkinson of Ariadne Software Ltd. APPENDIX:
DETAILED SPECIFICATION
Microtext Authoring Systems are available for the BBC Model B and the CBM 4032 and 8032 microcomputers with disk or tape. The Authoring System incorporates a combined editor and interpreter: The Microtext Language Interpreter presents text and graphics on the screen, and accepts responses from the user. The screen can be divided into fixed and rolling parts, and responses can be prompted for at any position on the screen. Response matching includes single character or keyword analysis, with optional numeric validation and range checks. Help menus can be supplied. Text is stored as a series of linked frames, and presentation and branching can be modified by the state of internal variables modelling the capabilities of the user. A concise textual summary of the interaction can be printed or archived as necessary. Commands exist to control peripherals such as a slide projector or video-tape recorder. The BBC implementation includes full colour and graphic support. The Microtext Editor allows an author to create and modify Microtext modules. The full screen editor incorporates character and line insert and delete, and frames can be created, copied, and printed, and complete modules can be loaded or saved to tape or disk. Modules can be run in test mode which includes status information and warnings of error conditions. Execution can be interrupted and variables or frames examined or modified before continuing. The Publishing System enables applications using Microtext to be published in a secure form by producing a Delivery System which integrates the interpreter with an encoded application.
The De si gn and Eva luation of a Mi cro-Computer DISCUSSION SUMMARY The standard version of Microtext occupies 14 k bytes on the 6502. The systems runs in the BBC, CMB and Apple micros. Versions are being developed for CP/M and other machines based on PASCAL. Microtext can be extended to include commands to control peripheral equipment such as a video disc. Microtext is marketed separately for each machine, at prices ranging from £ 50 to £ 300. A design feature of the Microtext language is to allow instructors to modify lessons written by other people. Even the learner can modify or write his own material, if the author so wishes. The text and control information can be listed on the printer with the PRINT command. An overview of the structure of the lesson can also be printed separately.
195
THE DESIGN AND EVALUATION OF A MICRO-COMPUTER BASED AUTHORING SYSTEM FOR TRAINERS N. Bevan and R. Watson National Physical Laboratory, Teddington, Middlesex, England
Abstract. An authoring system has been designed with the major criterion of ease of use, rather than ease of implementation. The microcomputer version, called Microtext, combines a frame-structured authoring language with a full-screen editor. The ability to switch immediately between running a lesson in student mode and editing material in author mode, makes it very easy for people without previous programming experience to produce their own training material. The evaluation highlighted the need to adjust established conventions within computer science to meet the needs of people new to computers. Keywords. Author languages; computer-aided instruction; human factors; programming languages; training; teaching; educational aids. makes it complicated to implement computer based training applications which are primarily concerned with presenting and manipulating information on the screen, and checking responses given by the user. The purpose of a specialised authoring system is to package the power of the computer in a form which is appropriate and convenient for implementing computer-based training material. For example, obtaining a student answer and then branching if it contains a specific word should be simple in an authoring system, but in a conventional language requires a complicated combination of instructions.
WHY AN AUTHORING SYSTEM? Much computer-based training material is written using conventional programming languages. There are, however, a wide range of specialised authoring systems on the market, which are designed to simplify the task of producing computer-based training. What are the advantages of these authoring systems, and why do some people choose not to use them? Using conventional languages, it is necessary for an expert to convey his knowledge to the trainer, who structures it as a dialogue, and then passes it to a programmer for implementation:
An authoring system will incorporate a method of inputting text and instructions in author mode, and a method of presenting text and executing instructions in student mode. It should both improve the productivity of the experienced programmer, and make the computer more accessible to non-programmers. A good system will enable courseware to be produced in a form which is accessible to the trainer and instructor for comment and amendment. It may even be possible to dispense with specialist programming skills altogether and to combine the roles of trainer and programmer into a single Author:
EXPERT I
'\V
TRAINER
<------> INSTRUCTOR
~
A,-
I I
I
Y
Y
I
PROGRAMMER
TRAINEE PROGRAM
This is a good division of skills in a well-organised and well staffed department, but any feedback from the instructor must be passed back to the trainer who consults the programmer to arrange implementation. This procedure for making alterations may be inconvenient, and the original intentions can easily become distorted.
EXPERT ~
AUTHOR
<------> INSTRUCTOR .1} I I
"
TRAINEE Most conventional languages have been designed primarily for calculation and data manipulation, and to handle text line-by-line. This
PROGRAM
189
N. Bevan and R. Watson
190
This arrangement can significantly simplify the organisation of a computer based training department, by reducing the number of individuals required to write and evaluate new training material. The author can respond immediately to feedback from the instructor, without having to wait for the programmer to implement suggestions. It may also be possible for instructors to tailor the training material to their own individual requirements. However, all languages impose constraints. Thus for example the awkwardness of string handling in FORTRAN means that FORTRAN programmers will, whenever possible, design their interactive applications to ask questions with numeric answers. Similarly the user of an author language will bend his application to make it convenient to implement within the constraints of the language he is using. This bending may not be deliberate, but the result of structuring the problem to use the particular range of facilities which are provided, and with which the author becomes familiar. This tailoring of applications can make comparison of different authoring systems very difficult, as an application written using one language will almost certainly be optimised to take full advantage of the peculiarities of that language. Just as the best translation of poetry is not a literal one, so the translation of a training application will require fundamental rethinking. The most extreme case is the author who writes in assembly language on a microcomputer. If he aspires to produce applications which use the machine in a dynamic and creative way, emulating the best computer games, the applications will almost certainly be totally unimplementable in any other context. The enormous productivity gains to be obtained from a good authoring system normally justify the inevitable constraints. What is important is to ensure that there is an appropriate compromise between productivity and the range of application of the system. APPROACHES TO AUTHORING Some computer-based training material is still written in assembly language, and adherents of this approach maintain that this is the only way to gain access to the full power of the machine. It is true that certain dynamic simulations are very hard to implement in any other way, although it may be much simpler to use a system which supports assembly language subroutines, rather than write the complete application in assembly language. Training material is often written using the "standard" language for a particular computer, since it is familiar to the programmers, and supports a wide range of features on the
machine. On microcomputers this language is usually BASIC, and on larger scientifically oriented machines it is frequently FORTRAN. These conventional languages present a number of problems. As indicated above they make certain common training requirements unwieldy to implement, and may therefore encourage a poor style of training. They may also be inappropriate for the implementation of large packages of material. In languages such as BASIC large programs can evolve a dense spaghetti-like structure which is difficult to understand and inefficient to execute. One solution is modular programming, but this is discouraged by the difficulty in many systems of passing variables between a series of linked programs. Once the requirement for a specialised authoring language has been established, there is still the problem of choosing which particular style of authoring system is appropriate. The different approaches to authoring can be divided into several categories: 1. Statement-oriented systems modelled on existing languages; 2. Prompting and menu-driven systems; 3. Systems offering a choice of fixed templates; 4. Frame-oriented systems. Statement-oriented Systems Typical examples of this approach are PILOT (Yob, 1977) modelled on BASIC, STAF (Ayscough, 1981) based on FORTRAN, and COMBAT (Mills & AlIen, 1982) modelled on PASCAL. The aim of these systems is to provide the power of the original language enhanced by features designed specifically for CBT. This generally makes them far more productive than an ordinary language, but only suitable for programmers who can grasp and manipulate traditional programming concepts. Prompting and Menu-driven Systems The intention of these systems is to provide guidance to the author at every step in the authoring process. Prompting systems such as Easywriter (Brown, 1982) prompt the user at every stage, and store the result in an intermediate form for execution. Authoring is easy provided the application fits within the constraints of the system. The end result can be very simple material which is not amenable to alteration. More sophisticated menu-driven systems such as WISE (Wicat Systems, 1982) give access to almost all features of the system from menus.
The Design and Evaluation of a Micro-Computer This greatly simplifies the production of potentially sophisticated material, although the enormous wealth of menus is initially intimidating, and may eventually prove unwieldy. Template Systems Template-based systems such as APT in TICCIT (Hazeltine, 1979) organise training around a number of forms representing pre-defined instructional strategies, into which specific material can be placed. The power of these systems depends to some extent on the range of templates, and the extent to which editing of existing material is supported. The major drawback is that training material is channelled into preconceived notions of appropriate presentation strategies. This limits the flexibility available to the author, and restricts the range of application of the system. Frame-oriented Systems The Prestel viewdata service in the UK is a simple example of a frame-based system. The major advantage of viewdata has been the standardisation of the screen format and communications interface, and the consequent wide availability of compatible systems and terminals. The very simplicity of the standard software makes it easy to use, and relatively easy to set up. But the programming facilities provided are rather primitive by normal CBT standards, limited to presentation of complete screens, and acceptance of numerical answers. Some private viewdata implementations have been considerably enhanced to provide the features necessary to support training applications. Viewdata holds the frames of text separately from the control structure which defines branching between frames, although the frame numbering convention does not aid understanding of how an application works. Other systems, such as ICL's internal training system (Clarke, 1982), name the frames of text, and reference these from a sophisticated control language. The total separation of text and control structure can encourage the use of general purpose frames rather than individualised dialogues. The Microtext system described below incorporates the control information at the top and bottom of each frame, in order to combine the simplicity of a frame oriented approach, with the readability of a simple programming language. Microtext is essentially a frame-structured language.
J9 J
ORIGINS OF MICROTEXT Microtext evolved from Mickie, the medical interviewing computer, (Bevan, Pobgee and Somerville 1981), developed in the 1970s. The aim of the Mickie system was to simplify the use of computers, both for the doctor/ programmer and patient/user. Mickie applications were originally written in BASIC, but as the programs grew larger, a data structure was adopted to store the text and minimal control information separately from the BASIC program which administers the questionnaire. Each block of text containing a question is numbered, and followed by the numbers of the blocks to which a branch can be made. The user's response determines which of the blocks is selected. This format of text and block numbers defines a separate language called Questext, which is easy for doctors and other non-computer professionals to set up using a conventional screen editor. Questext was extended to cater for educational and training applications with more varied requirements, and the resulting system called Edutext. It was successfully used for a variety of applications, but as the facilities were enhanced it became apparent that the Edutext interpreter written in BASIC was becoming too slow. A decision was taken to rewrite the interpreter in assembly language, so that it could be used on a range of small microcomputers. This microcomputer implementation has been called Microtext. STRUCTURE OF MICROTEXT The over-riding design aim of Microtext is to make simple things simple to do, so that an author can in a few minutes learn how to set up a simple branching presentation. At the same time Microtext incorporates a wealth of more sophisticated features so that as an author gains experience he can implement more complicated applications tailored to specific needs. Microtext has been designed to allow the author to concentrate on the content and flow of his material, and the authoring process is centered around editing frames of text on the screen. Microtext has diverged from many other authoring languages in attempting to make ease of use rather than ease of implementation the ultimate criterion for system design. The end result is a pragmatic compromise with a simple and concise syntax for the most frequently used facilities, complemented by plainlanguage commands to exploit specialised features.
192
N. Bevan and R. Watson
The language is unusual in that it has a frame-structured syntax. The unit of a frame is one which is easily understood, and in Microtext incorporates control information at the top and bottom. The example below shows the frame number at the top, followed by the text area, and a response checking region:
*1 Which is the most popular language used on microcomputers. ?
MICROTEXT-?2, BASIC-?3 ~
B: Neutral
{
{ text { {
C: Earth
(prompt) (responses) (end)
?
A
~
40, B
~
20, C
~
30
In this example the header line contains just the frame number prefixed by "*". This is followed by free-format text. The text is terminated by the line starting with "?", which prompts the user for a response. This is followed by checks for answers A, B, or C, which branch to frames 40, 20 and 30 respectively. The frame is terminated by a row of dots. This principle can be extended to more complex applications. The author will often choose to design his material using a flowchart. An illustrative example is shown below: I
I
---------------------->: Which is the most popular language used on microcomputers ?
MICROTEXT 2
No, it is a new language
(other)
BASIC 3
4
: Yes, well: : done
: No, BASIC : : is the most : : popular
I I
5
4
(response -? frame) (default branch)
(header)
*10 What is the brown wire in a mains cable used for? A: Live
(frame number 1)
I I
:<-----------
: That is the end : : of this lesson This example requires 5 frames. Each box on the flowchart is given a number, and then the text in each box is written as a frame of Microtext:
*2 No, Microtext is a relatively new language. -? 1
(go back to frame 1)
*3 (SCORE=5) Yes, well done. -? 5
(set the SCORE to 5)
*4 (SCORE=O) No, BASIC is the most popular. It is not
(set the SCORE to 0)
*5 Your score so far is
(ANS contains answer)
(contents of SCORE)
That is the end of this part of the lesson. -? 10 (next frame) **Score on languages **is
The Design and Evaluation of a Micro-Computer In student mode, the interpreter presents text and graphics on the screen, and accepts responses from the user. In the simplest applications the user will be responding to multiple choice questions , or just pressing keys with labels such as YES, NO and DONT KNOW. To avoid the complication of instructing the user to remember the RETURN key, Microtext can accept single character input, as well as longer responses. The performance of users can be monitored by incorporating summary items at the bottom of each frame. These contribute to a plain language report which can be archived, or printed at the end. Microtext has been designed to be easy to write and easy to correct. Errors associated with syntax and branching which are easy to make in a conventional language, are kept to a minimum in Microtext. The errors which do occur are almost always self-evident on the screen when the material is run. When the author is testing frames ambiguous syntax and other likely errors are highlighted for possible correction. In student mode defaults are taken whenever possible, to minimise the chances of the system failing. Variables can be used in Microtext to hold answers, to calculate scores, and to adjust presentation to individual requirements by modifying both the text and branching sequence. Although numeric values can be manipulated, the conventional distinction between numeric and string variables is rather artificial in the context of text presentation. Consequently all variables are of the same type, and both numeric and string operations can be performed on them as appropriate. Another innovation is to avoid the concept of variables as parameters, and expand the contents of variables directly into the line buffer. This means that variables can be used to replace or modify any part of the text or language syntax. This is particularly powerful when tailoring general purpose subroutines to precise requirements (although it is not a feature which should be used in haste!). A detailed specification of the Microtext system will be found in the Appendix.
193
Initial Barriers One of the most difficult problems to overcome when anyone is faced with a totally new environment is initial confusion and disorientation . Microtext is very easy to use once the basic principles have been grasped, and these can be explained in a few minutes. The problem with any new system occurs when users who cannot obtain personal assistance have to rely on the system itself and the associated documentation . Two steps were taken to remedy the situation . First an elementary introduction for beginners was written and a package of demonstration programs supplied. Secondly it was decided to incorporate built in help for the author. There had been initial reluctance to do this in view of the memory limitations on a microcomputer, but the solution was to incorporate a HELP OFF command to recover the space once the author became more experienced. System Modes It is particularly important that people new to programming grasp the distinction between writing a program, and running a program. In Microtext there are four distinct system modes: Command mode for file handling and entering other modes, Edit for writing text, Test for testing material, and Run for running in student mode. These modes were initially indicated by status messages on the bottom of the screen, and two manuals were provided: a guide to writing programs using the editor, and a guide to the language syntax which was obeyed when the programs were run. Many users had difficulty understanding the distinction between the modes, and the difference between the two manuals. Again both the documentation and system were improved. The manuals were rewritten grouping use of the system into functional units rather than arbitrary modes. On the screen the distinction between modes was highlighted by using a different colour status line for each mode. The system mode was then self-evident without even needing to read the information contained on the line. In the case of student mode the status line was dispensed with altogether, to give the author the freedom to use the whole screen in any way he wished.
EVALUATION Other Human Factors Evaluation of Microtext started early in 1982 and although only expected to take a few months, the cycle of alterations and enhancements lasted almost a year. A wide spectrum of authors including teachers, trainers, programmers, and students, reported their reactions. Although these were generally very favourable, some areas of difficulty were encountered:
In some cases it was necessary to adjust established conventions within computer science to meet the needs of the non-computer professional. For instance the modes of the system were originally called Edit, Text, Run, and Debug, but these were changed to Command, Edit, Run and Test, respectively. Error messages were reworded to remove jargon, and row and column numbers were altered to start at 1 rather than O.
N. Bevan and R. Ivatson
194
Many other changes were made to improve the robustness and user-friendliness of the system. For instance, protection was incorporated to warn the author if he attempted to take any action which would lose an edited module that had not been saved. The minimum abbreviations of commands was altered to ensure that commands causing deletions were always longer than other similar commands.
Mills & AlIen (1982). COMBAT system. Mills & AlIen Communications Ltd, London, UK. Wicat Systems (1982). WISE system. Systems Ltd, Birmingham, UK. Yob, G. (1977). 3, 57-63.
FUTURE PLANS The latest version of the system, Microtext V2.1, is now available on BBC and CBM microcomputers, and will be available for CP/M machines in late 1983. It includes commands to control peripheral equipment such as video-tape recorders and slide projectors. Although this version caters for a very wide range of users, the evaluation suggested that professional users require a larger and more sophisticated system covering a broader spectrum of applications. It is intended to produce a version called Microtext Plus, incorporating many detailed improvements in functionality and adding some significant new features. These will include floating point arithmetiC, the ability to name frames, an interactive graphics editor, and the ability to incorporate expert system techniques using production rules. CONCLUSION Microtext has demonstrated that it is possible to implement a very sophisticated system within the constraints of a 32K byte microcomputer, and experience so far suggests that it will prove a useful tool in a wide range of computer based training applications. Microtext is an example of tailoring the machine and its language to the needs of the user, rather than expecting the user to adjust to the arbitrary requirements of the machine. It is to be hoped that it will take its place in a future populated by a mass of machines adapted to the needs of the individual, rather than a mass of individuals adapted to the needs of the computer. REFERENCES Ayscough, P.B. (1981) . STAF Author Guide. Leeds University, UK. Bevan, N., P. Pobgee, and S. Somerville (1981) . MICKIE - A microcomputer for medical interviewing. Int. J. Man-Mach. Stud., 14, 39-47. Brown R.L. (1982). Easywriter. Manchester, UK.
Hazeltine (1979). Authoring Procedure for TICCIT. Hazeltine Corporation, Mc Lean , Va., USA.
NCC,
Clarke, M. (1982). Beyond Authoring Systems (paper presented at CBT 82) . ICL Ltd, Stevenage, UK.
PILOT.
Wicat
Creative Computing,
ACKNOWLEDGEMENTS The Microtext development group at the National Physical Laboratory also includes Steve Collins, Tony Mansfield, and Dianne Murray, and the implementation was carried out in conjunction with David Parkinson of Ariadne Software Ltd. APPENDIX:
DETAILED SPECIFICATION
Microtext Authoring Systems are available for the BBC Model B and the CBM 4032 and 8032 microcomputers with disk or tape. The Authoring System incorporates a combined editor and interpreter: The Microtext Language Interpreter presents text and graphics on the screen, and accepts responses from the user. The screen can be divided into fixed and rolling parts, and responses can be prompted for at any position on the screen. Response matching includes single character or keyword analysis, with optional numeric validation and range checks. Help menus can be supplied. Text is stored as a series of linked frames, and presentation and branching can be modified by the state of internal variables modelling the capabilities of the user. A concise textual summary of the interaction can be printed or archived as necessary. Commands exist to control peripherals such as a slide projector or video-tape recorder. The BBC implementation includes full colour and graphic support. The Microtext Editor allows an author to create and modify Microtext modules. The full screen editor incorporates character and line insert and delete, and frames can be created, copied, and printed, and complete modules can be loaded or saved to tape or disk. Modules can be run in test mode which includes status information and warnings of error conditions. Execution can be interrupted and variables or frames examined or modified before continuing. The Publishing System enables applications using Microtext to be published in a secure form by producing a Delivery System which integrates the interpreter with an encoded application.
The De si gn and Eva luation of a Mi cro-Computer DISCUSSION SUMMARY The standard version of Microtext occupies 14 k bytes on the 6502. The systems runs in the BBC, CMB and Apple micros. Versions are being developed for CP/M and other machines based on PASCAL. Microtext can be extended to include commands to control peripheral equipment such as a video disc. Microtext is marketed separately for each machine, at prices ranging from £ 50 to £ 300. A design feature of the Microtext language is to allow instructors to modify lessons written by other people. Even the learner can modify or write his own material, if the author so wishes. The text and control information can be listed on the printer with the PRINT command. An overview of the structure of the lesson can also be printed separately.
195