Journal of Microcomputer Applications (1984) 7, 167-l 88

TUTORIAL

MICROTEXT: a new dialogue programming

language for microcomputers
P. G. Barker
Interactive Systems Research Group, Department of Computer Science, Teesside
Polytechnic, County Cleveland, UK

MICROTEXT is a new dialogue programming language that has recently been

developed by the United Kingdom’s National Physical Laboratory. This paper presents
an overview of the language, describes its mechanism of program creation and then
provides some examples of its use in the context of dialogue engineering.

1. Introduction
An interactive computer system is one in which its users are able to communicate directly
with (and hence, control the progress of) the computational tasks running within it.
Associated with this mode of computer usage is the idea of human-computer dialogue
(Gaines & Shaw, 1983). This involves a ‘to and fro’ movement of information from the
user to the computer and, likewise, from the computer to the user. Typically, the user
sends a message of some sort to the computer; the computer analyses this and responds
accordingly-amongst other things, this response usually involves transmitting a
feedback message to the user. Information exchange continues in this way until one or
other of the communicating partners terminates the dialogue.
In order to permit the specification and generation of interactive computer dialogues
special software tools are necessary. Of particular importance are the different types of
dialogue programming language (DPL) that are available. A DPL is a programming
tool that is specially designed to enable the human-computer dialogue engineer to:
(a) specify the rules that must be followed during information exchange,
(b) verify that these are being obeyed, and,
(c) control and sustain the progress of the dialogue.
Examples of dialogue programming languages include: APL (Gilman & Rose, 1974);
BASIC (Coll, 1982); IPS (Barker & Steele, 1983); PILOT (Barker & Singh, 1983); LOGO
(Byte, 19823); SMALLTALK (Byte, 198 1); and MICROTEXT (Barker & Singh, 1984).
A DPL must provide a wide range of facilities. In particular, they must cater for:
(a) information output to the user,
(b) message input from the user,
(c) message analysis (via pattern matching, etc.),
td) action taking,
(e) response archival, and
(f) dialogue monitoring.
MICROTEXT is an example of a dialogue programming system that can be used for a
wide variety of interactive computing applications. It is of particular importance within
computer-based learning situations since it can be used to generate, control and sustain
167
0745-7138/84/020167+22 $03.00/O 0 1984 Academic Press Inc. (London) Limited
168 P. G. Barker

instructional dialogues for use in a wide variety of teaching and learning situations.
Unlike IPS and PILOT (which are essentially line orientated), MICROTEXT is a frame-
based system. A program written in this language is composed of one or more units
called modules. Each module is, in turn, constructed from a series of VDU frames that
may be stored on a variety of magnetic media. Modules, and the frames they contain,
may be subsequently recalled from these media into memory and then displayed as and
when they are needed. The MICROTEXT system contains its own built-in frame-based
editing facility that is used to create and modify frames. In Section 2 a description is
given of the general structure of frames, the way in which the editing system operates and
the format of programs created using this dialogue programming language. Naturally,
because of space limitations, the material that is presented will take the form of an
overview. More detailed technical information may be obtained from the appropriate
language reference manuals (Bevan & Watson, 1982; Bevan & Watson, 1983).

2. General description of MICROTEXT

As we mentioned above each module in a MICROTEXT program consists of a series of
numbered frames. A frame is a unit of text that fits conveniently onto the CRT screen of
the VDU. Thus, a module called PGB.STA may consist of a series of frames numbered
according to the scheme depicted in Figure l(a). Here, frame numbers increase in
increments of 10 until the last one is reached (frame 500). Similarly, the module
PGB.MOl contains frames whose numbers increment by 5-the final one being
numbered 999. Frame numbers must be in the range l-999.
All frames have the same basic structure. Each one contains a frame number, optional
text for display to its user, comment lines, and/or control information that can be used to
specify the direction that the humancomputer dialogue should take. This logical
structure of a MICROTEXT frame is depicted in Figure l(b). The number of this frame
is 30 (notice how the frame number is preceded by an asterisk). When this frame is
executed it would cause the three lines of text that it contains to be displayed on the CRT
screen. The control lines in the last part of the frame would then halt execution of the
module (by use of the input operator ?) until the user types a reply. This response would
then be analysed by the last control line-the reply being used to determine which frame
is to be executed next. If the user replies with the word Tom then frame 100 would be
displayed; should the response be John then frame 200 would be shown; otherwise,
frame 300 would be selected.
The MICROTEXT system operates in such a way that it may function in any of four
basic modes: (1) command mode, (2) edit mode, (3) test mode, and (4) run mode. The
first three of these are used by the program author to create, modify and test software.
The fourth mode is used when users interact with this software. By default, command
mode is entered when the system is first loaded into the computer. Other modes may
then be invoked by keying-in appropriate commands through the microcomputer
keyboard. The nature of these commands will be discussed later.
When in command mode the physical CRT screen of the VDU is divided up into three
sections as shown in Figure l(c). The top line of the screen is the header line. The first five
spaces of this contain the frame number of the frame currently being displayed. The
remainder of the screen (except for the last two lines) is used to hold the text and control
information associated with the frame. The bottom two screen lines contain the status
PGB.STA
IO 20 30 40 500 -t---- Frame number
. . . . . . . . . . . .._...........
r-----------l
Hello I
What is your name? _c ~___ Text for display
PGB.MOI Is it Tom or John?

5 10 15 20 25 999 ?
. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .
Tom + 100, John -+ 200, + 300 -f-- Control information

(a)
L_J (b)

Column 20

*lOO = STUDNAME - Header line

. . . . . . . . . . . . . .. .. . . . . . . . . . . . . . . . . . . . .. . . . .. . . . . . . . . . . .
$LINE 15.20
Hello
&LINE 16.20 a Frame area Line 15 B Hello
What is your name? Line 16 B What is your name?
$COMMENT Reply stored I” studname
? TOM

COMMAND MODE DISK 0 PGBSTA f-- Status line

,,,,,,,.,,,.,,.........,...,~~.,..~,....,,.,,,,,,,,,,,
PRINT lo-300 f- Command line

(4 (d)

Figure 1. MICROTEXT module, frame and screen organization. (a) Module structure. (b) Logical frame organization. (c) VDU screen
organization -author’s view. (d) VDU screen organization-student’s view.
170 P. G. Barker

line and command line. The status line is not used when the system is in RUN mode.
However, in each of the other modes it displays: the current mode (COMMAND, EDIT
or TEST); the current storage device for the module; the current lesson and module
name; and the current frame number. The command line is used to display commands as
they are typed by the user (for example, PRINT 30) and for the display of error messages
(for example, NO ROOM IN MEMORY). Figure l(c) depicts the appearance of the
VDU screen as it would be seen by the program author when in command/edit mode.
When this frame is executed (by issuing a RUN command) the VDU screen appearance
would be similar to that shown in Figure l(d). This depicts how a user would see the
frame. The two lines of text commence at column position 20 within lines 15 and 16. On
the subsequent line the user has typed the reply TOM. Notice how a long horizontal line
is used as a prompt mechanism in order to indicate to the student when and where a
response is to be typed.

3. Program creation and modification

The programmer creates programs and frames by means of the MICROTEXT

command and edit modes of operation. This activity is often referred to as program
authoring. Command mode is used to create and name a module (using the NAME
command). Subsequently, the frames within the module may be archived onto flexible
disc (or cassette tape) for future use by issuing a SAVE command. The individual frames
from which a module is composed may be generated by (1) issuing a FRAME command,
and, (2) appropriate use of the MICROTEXT screen-editing system.
When in editing mode the program author may enter textual material into a newly
created frame template. Similarly, the contents of an existing frame may be rearranged
and modified in various ways. The MICROTEXT editor provides its user with a full
range of screen-editing facilities. These include standard cursor control keys and key
combinations to allow character (and line) insertion and deletion. In addition, provided
a suitable microcomputer is used, certain key combinations can be employed to produce
colour effects and generate Teletext control characters (Reis, 1976). These enable the
programmer to produce a variety of stimulating visual presentations. Once a dialogue
engineer has gained some familiarity with the editing system it is extremely easy to use.
In addition to the frame creation/recall command (FRAME), MICROTEXT
provides a number of commands to enable frame manipulation. The more important of
these include COPY (to make a copy of a frame), ERASE (to destroy one or more
frames), PRINT (to enable one or more frames to be printed on a printer), LIST (to
enable frames to be listed on the VDU), and, COMMENT (which converts a frame into
a comment frame). Comment frames provide a useful means of documenting a module.
Furthermore, the ability to convert an executable frame into a comment frame (and vice
versa) is a very useful tool for program debugging during MICROTEXT test mode. The
format of a complete program written in MICROTEXT is illustrated in Figure 2. It
contains two types of frame-comment and executable. Frame Cl is an example of the
former type while the remaining ones are all of the executable variety. Notice how
individual frames are each separated from one another by a horizontal line of dots.
These are automatically inserted by the editing system when the edit dialogue (used for
frame creation) is terminated.
 MICROTEXT: a new dialogue programming language 17 1

4. MICROTEXT facilities-an overview

As we described in the previous section, the editor is used to insert and modify all the
information contained within a frame. The contents of a frame (see Figures l(c) and 2) is
likely to include: (1) text for display to the user; (2) MICROTEXT run-time commands
(these all commence with a $ symbol); and (3) response test and branch instructions that
are used for dialogue control. Commands and instructions provide the facilities for:
(a) declaring, initializing and manipulating variables,
(b) obtaining responses from the user,
response analysis via pattern matching and value comparison,
I”d, branching to other frames,
(e) monitoring human-computer dialogues (via summary items), and,
(f) the provision of help facilities.
Each of these is briefly discussed below.

(a) Use of variables

MICROTEXT variables may be of two basic types: system- and programmer-defined.
Examples of system variables include: ANS (which always holds the current input
response from the user’s keyboard); RANDOM (which is used to store the result of a
reference to the MICROTEXT random number generator); and TIME (which is a
simple elapsed-time clock). Programmer-defined variables may be used to store text,
summary items (see below), numeric values, keywords to be checked, frame numbers
and so on. Appropriate sets of arithmetic and text operators are provided in order to
manipulate these variables in various ways. Some methods of using a numeric variable
are illustrated in Figure 2. In frame 2, the statement in the header line is used to initialize
the value of the variable SCORE to zero. Subsequently, in frame 15, the value of this
variable is incremented by 1. Another way of achieving a similar effect is shown in frame
25. Here, the user’s response is tested to see if it is equal to the value 8; if so, the value of
SCORE is incremented and a branch is made to frame 30. A similar method of
incrementation is used in frame 40. The final value of SCORE is printed out on the VDU
screen when it is referenced in frame 55. The value of a variable is printed out when its
name (enclosed within angular brackets) is present in a text display line.
Variables can also be used to hold text strings. Some simple uses of text variables are
illustrated in Figures 3-5. These examples show different ways of assigning text strings to
variables and later displaying their value. Of course, variables of this type can be used to
implement quite sophisticated text-handling applications similar to those that can be
written in other programming languages. MICROTEXT variables are expanded into a
line before the line is executed. They can also be used to replace any parts of the matching
and branching instructions.

(b) Output and input

The output of information from a frame is fairly straightforward. All lines of text
following a frame number and which are not MICROTEXT commands are displayed on
the screen of the user’s terminal. Output is either informatory or may take the form of a
prompt for user input.
Input from the user may be of several different types. An appropriate MICROTEXT
operator is used to specify which type of input the programmer wishes to use. For
example,
172 P. G. Barker

Cl
This is a simple CA1 lesson written Correct.
in MICROTEXT. It shows the frame A spider has 8 legs.
structure of a module and how to -60 RETURN 40
implement simple branching
.....................................
*2 (SCORE-O) Sorry. You're wrong.
This is a lesson about animals. A spider has 8 legs.
Do you wish to proceed? -60 RETURN 40
..... .. ............ ..........
;ES-5, NO+lOO, -2 *40
....................._...._........._ SJOIN
Name a creature with 100 legs
ZOIN ?
How many legs does an elephant have? centipede+45 (SCOREtl),-50
?= ............................. .....
(4-10 *45
4+15 Yes. You are correct.
>4+20 It is called a centipede
..................................... +55
*10 ............. ... ........
Wrong. Too few *50
KOMMENT Invoke a subroutine No. You are wrong.
+60 RETURN 25 It is called a centipede.
........................ ............ 60 RETURN 55
*15 ........... ..................
Correct. *55
$(SCORE+l) This is the end of the lesson.
160 RETURN 25 Your score was <SCORE>
.................................... -100
*20 . . . . . .._......_......._........._....~..
Wrong. Too many *El0
60 RETURN 25 Press RETURN in order to continue.
........................................ ?
*25
IJOIN . . . . . . . .._.._................_.._........
How many legs does a spider have? *100
?= SEND
&30 (SCOREtl) .,..... .............__._..._...........
+35
. .. .............. ...... .............. ...

Figure 2. A simple CA1 lesson written in MICROTEXT.

! denotes single character (or fixed length) input, and,

? denotes free format character string input.
The input of numeric values is facilitated by appending an= sign to these operators
(forming ! = and ? = , respectively). Field numbers (@O, @ 1, (92, etc) can be attached to
the above operators in order to associate input operations with particular fields.
Constructions of the type ? = @O, ! = @ 1, ? = @2 (and so on), can then be used to initiate
input to specific fields that are displayed on the VDU screen. By using various
combinations of these composite field input operators it is possible for the frame
designer to create quite sophisticated form-based input transactions. As we shall see
later, Figure 7 illustrates this approach to screen handling.
Some simple examples of the use of the input operators are illustrated in Figure 2.
Frame 2 uses ? to bring about free format text input-this mode of input is also used in
frames 40 and 60. In contrast, frame 5 uses the ?= combinations to specify numeric
input is to be used. During each of these input transactions the actual value typed by the
user is stored in the system variable ANS. It is important to remember that the value
contained within ANS is continually being updated as new input transactions take place.
Consequently, in order to save a particular user response for use later in the program the
programmer must assign the value of ANS to another variable or use an alternative
(previously defined) input variable. The former approach is straightforward and can be
achieved by an assignation of the form $(JACK = ANS) which assigns the value of ANS
 MICROTEXT: a new dialogue programming language 173

Cl This is an example of a modular *7n

CA1 lesson written in MICROTEXT $&IN
........ ....... ...... .... .. .... ... ... ... Would you like another go?
l10 =x ?
$CLEAR 'y'-75, 'yes'-75
BJOIN 'n'*80, 'no'-+0
Which lesson would you like to study? -85
a) history .... .... ................ .......... .. ... .
b) maths *75
c) computing OK. Here we go.
d) electronics $PAUSE 20
Tell me your answer. -10
........................... ......
'a'-6O,'b'-60,'c'~O,'d'-60
'history'+6l,'maths'+61 '80
'computing't61, 'electronics'+61 yioo Time to end
-20
..___.__.,,_...........................
*20 $JOIN *85
Sorry. I don't recognise your answer. YOU haven't given a correct answer
SRANDOM 3 Have another-go.
?=RANDOM -70
1+30, 240, 3+50 . .. .. . . . . .. . .. . .. . . . . .. .. . . . . . . . . .
. . . ..__..._...... . . *lOO SCOMMENT History lesson
*30 History lesson invoked.
Please try again. -RETURN
SPAUSE 20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .._._....
-10 *ZOO ICOMMENT Maths lesson
. . . .. . . . . . . .. . .. . . . Maths lesson invoked.
'40 -RETURN
Have another go. ..... ..I............._._..___._..

SPAUSE 20 *300 BCOMMENT Comoutina lesson

-10 Computing lesson inboked:
..I., .... -RETURN
*50
Try once more.
SPAUSE 20 *400 SCOMMENT Electronics lesson
-10 Electronics lesson invoked.
___.._...,._,_..,..........._.._........ -RETURN
l60 . . . . . .._.........................
S(REPLY="OK. Let's proceed.") *900
65 $END
_.,,.,,,_,,..,..,..,...............
'61
S(REPLY="Thankyou")
..,.....,,........._...............
*65
<REPLY>
SPAUSE 30
$CLEAR
?X
'a'+100 RETURN 70
'history'+100 RETURN 70
'b'.200 RETURN 70
'maths'-200 RETURN 70
'~'-300 RETURN 70
'computing'+300 return 70
'd'-400 RETURN 70
'eiectronicsQ%OO RETURN 70
. _...,...,.........,.... . ..... ...

Figure 3. Use of MICROTEXT subroutines.

to the variable JACK. The way in which alternative input variables are used is illustrated
in Figure 3. Here, the header line of frame 10 contains the phrase =X. This is used to
specify that the variable X is to be employed to store the user’s response to this frame.
The value of this variable is later analysed in frame 65 by the series of statements
commencing with ?X.

(c) Response analysis

MICROTEXT offers a range of facilities to enable user responses to be analysed.
174 P. G. Barker

Cl Arithmetic drill and practice. *20 (scoretl)

MICROTEXT version. Good. You are correct.
.................................... -25
*5 (score=O,repeats=O) .................. .. . . ....... .
.................................... '25
*lO BJOIN SLINE 20
$CLEAR Press RETURN to continue.
What value would you get when you ?
$RANOOM 12 . . . . . . . . . . . . . . . . .._......................
?-RANDOM *26 (repeats+:)
1+14 (ques="add 61 to 1032?",sans=1093) ?=repeats
2-14 (ques="multiply36 by 27?",sans=g72) <lo-lO,-+30
3+14 (ques="take 26 from 42?",sans=16) . . . . . . . . . . . . .._..........................
4-14 (ques-"divide64 by 16?",sans=4) *30
5+14 (ques="add 62 to 136?",sans=198) Your score was (score> out of 10
6+14 (ques="multiply23 by 7?",sans=l61) ?=score
7+14 (ques="take 62 from llO?",sans=48) <5-+35,5-40,>5-45
8+14 (ques="divide 125 by 5?",sans=25) .........................................
9114 (ques="add 62 to 36?",sans=98) *75
lo+14 (ques="take 16 from 321?",sans=305) You will have to try harder next time.
11+14 (ques="add 129 to 643?",sans=772) -+200
12+14 (ques="take 79 from 126?",sans=47) .. .. . .. ...................... ..........
. ... ... ...... .. .. .... .......... . .... *40
*14 You could do better!
BJOIN -200
<ques> . . . . . . . . . . . . . . . . . . . .._...................
?= *45
sans+20,-15 Well done. Keep up the good work.
............................... ..... -200
*15 . . . . . . . . . . . . . .._...._._..._..__.._.......
No. *200 BEN0
You should have typed <sans> ............._..._.......................
-25
............................... .....

Figure 4. Arithmetic drill and practice using MICROTEXT.

Various types of value comparison and pattern matching may be used. For example,
techniques are available to:
(1) ignore blanks in user input,
(2) match keywords only with complete words,
(3) specify that a keyword must prefix a string typed by the user,
(4) specify that a keyword must suffix a string,
(5) perform exact keyword matching,
(6) search for several keywords in any order,
(7) search for several keywords in a specified order,
(8) perform numeric range testing.
Some simple examples are shown in Figure 2.
In frame 2, the user’s reply would be tested to see if it contained the string YES or the
string NO. Similarly, the input to frame 40 would be examined for an occurrence of the
string CENTIPEDE. Numeric-value analysis is illustrated in frames 5 and 25. In the
former, the value typed by the user would be inspected to see if it was less than 4, equal to
4, or, greater than 4. Frame 25, however, would require an input value of exactly 8 for a
successful match.
MICROTEXT provides very sophisticated pattern matching facilities. Unfortunately,
we have only been able to illustrate the most elementary of these. The others are
described in more detail in the language reference manual (Bevan & Watson, 1983).

(d) Branching
As in other languages, branching in MICROTEXT may be of three different types:
 MICROTEXT: a new dialogue programming language 175

cl Letter
Guessing game.
*16 IJOIN
MICROTEXT Implementation.
File: les.no4 BHELP 900
..,.._..............,._.................
loose-ends <lo>
*2
verticals <ve>
*5
obliques tab)
* throng answers were recorded for these
horizontals <ho>
* letters. The student response is
+ recorded curves <cu)
in the right-hand column.
. . . . . . . . . . . . ..~......................
;hich letter is this?
*5 SJOIN
s(J=o) tie> cans?
;le>+40,+35 *
1 am going to give you a description
. . . . . . . . . . . . . . . . . . . . . . . . . . .,.........
of one of the letters of the alphabet.
: will give you the number of *35
verticals NO!
horizontals You have the wrong answer.
obliques You should have typed <le?
curves, and, +45
loose-ends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .._.....
from which the letter is composed. *40
You must guess the letter. Yes, you are correct.
Type GO or HELP when you are ready to It's the letter <le>
proceed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .._
,............,....,.,.................~. *45
*6 BHELP OFF
SHELP 900 Would you like another go?
? Type YES or NO.
'GO'-lO,-7 7
. .._._..._..._.......................... %'+55,'YES'+55
*7 'N'+999,'NO'-999
Please enter the word GO or HELP if -50
you wish to proceed. . . . . . .. . . . . . . . .. . . . . . . . . .. . .. . . . . . . . . . .
d *50
.,....,................................ That's not a valid reply
*In +45
$kANDOM 26 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .._.._._.
S(j=RANDOM) *55
7-i
J SHELP OFF
I-15 (le="A",obz2,ve=O,ho=l,cu=O,lo=2) 00 you need instructions?
_I
2-15 (1e="B",ob=O,ve=l,ho=O,cu=Z,lo=O)
3-15 (le="C",ob=O,ve=O,ho=O,cu=1,1o=2) 'Y'-5,'YES'+5
4-.15 (le="D",ob=O,ve=l,ho=O,cu=l,lo=G) 'N'+lO,'NO'+lO
5-15 (le="E",ob=O,ve=l,ho=3,cu=O,lo=3) . . . . . . . .. .. .. . . . . .. . . . . . . .. . . . .. . . . . . . .
C-15 (le="F",ob=O,ve=l,ho=Z,cu=O,lo=3) *I30
7.-15 (le="G",ob=O,ve=O,ho=l,cu=l,lo=3) Please answer YES or NO.
8-15 (le="H",ob=O.ve=2,ho=l,cu=O,lo=4) +55
g-.15 (le:“I”,ob=O,ve=l ,ho=Z,cu=O,lo=4) . . . ..~......~.._._......_..._......_..
IO-15 ~le:"J",ob=O,ve=1,ho=l,cu=l,l0=3)
*900
11>15 (le="K",ob=2,ve=l,ho=O,cu=O,lo=4)
ICOMMENT This is a HELP subroutine.
12-15 (le="L",ob=O,ve=l,ho=l,cu=0,lo=2)
Here is an axample
13-15 (le="M",ob=Z,ve=2,ho=O,cu=O,lO=2)
14-15 (le-"N",ob=l,ve=2,ho=O,cu=O,lo=2) =2
loose-ends
15.~15 (le="O",ob=O,ve~O,ho=O,cu=l,l~=O)
verticals =2
15-15 (le="P",ob=O,ve~l,ho=O,cu=l,lo=l)
obliques =2
17-15 (le="Q",ob=l,ve=O,ho=O,cu=l,lo=2)
horizontals =0
18-15 (le~"R",ob=l,ve~l,ho=D,cu=l,lo=2)
curves =o

"1
This represents the letter M.
?;;
I?.15 (le="S",ob=O,ve=0,ho=0,cu=2,lo=2)
. . . . . . . . . . .._.._.............._.........
*920
w.15 (le="T",ob=O,ve=1,ho=l,cu=O,lo=3)
21-15 (le:"U",ob=O,ve=2,ho=O,cu=1,lo~2)
Now you try
2'+15 (le="V",ob=Z,ve=O,ho=O,cu=O,lo=2)
-RETURN 10
23-15 (le="W",ob=4,ve=O,ho=O,cu=O,lo=2)
.._....._....,..................__,.,,..
24.-15 (le="X",ob=2,ve=O,ho=O,cu=O,lo=4)
?!%I5 (le="Y",ob=2,ve=l,ho=O,cu=O,lo=3) *999
?6..15 (le="Z",ob=l,ve=O,ho=2,cu=O,lo=2) End of game. Goodbye.
,_..._,,._,............................ BLINE 10
*15 SJOIN $SUMMARY
Have a go at this one:- $ENO
... ........ ...... .. ....... . .. . . . . . . . . . . . . . . . .. . .. . . . . . . . . . . . . . . . .. .

Figure 5. Simple letter-guessing game using MICROTEXT.

176 P. G. Barker

unconditional, conditional and subroutine invocation. The target (or destination) of any
branching operation (denoted by the + symbol) is always a frame number, a module
name (and frame number), or a variable whose value represents a frame number. In
Figure 2, frames 45 and 55 contain examples of unconditional branching. When frame
45 is executed two lines of text are printed on the user’s VDU screen and then a branch
(or jump) is then made to frame 55.
Conditional branching is always based on value comparison or pattern matching.
These operations are performed either on the current user input value or on some value
contained within a variable. The first of these possibilities is illustrated below:
*200
Name an animal.

‘CAT’+300, ‘DOG’+400, PIG+SOO, -600

In this example the user would be asked to name an animal. If the reply exactly matched
the string CAT a branch would be made to frame 300. Similarly, an exact response of
DOG would cause a branch to frame 400 while a response containing the string PIG (in
any position) would cause frame 500 to be invoked. However, if none of these options
are matched a branch to frame 600 would be made. Further examples of conditional
branching are illustrated in Figure 2 in frames 2, 5, 25, and 40. The second type of
branching based on value comparison is depicted in the following example:
*800
?JACK
‘CAT’ --+300, ‘DOG’ -+400
PIG+ 500
+ 600

In this case the value of the variableJACK is being tested (by means of a pseudo-input
operation). The value stored in JACK is compared with the options specified and
branching then made accordingly. Examples of this type of conditional branching are
depicted in Figure 3 (frame 65) and Figure 5 (frame 10).
Subroutines are used to provide a mechanism whereby a group of frames may be
executed in such a way that, after execution, a return is made to the frame following the
point of invocation-or, to some other specified point in the module. A subroutine is
invoked by means of a branch in which a RETURN is specified. This is illustrated
below:
*10
Hello.
What is your name?
+200 RETURN
.. ....... ... ....... .
$20
What is your age?
+ 200 RETURN
l
l
l
etc
 MICROTEXT: a new dialogue programming language 177

*200 =REP
Type your answer below:
?
l

a
0
etc
. . . .. . .. . .. . .. . . .. .
*300
+ RETURN

During frame 10 a branch is made to the subroutine frames commencing at frame 200.
The frames from 200 onwards are executed and a return is ultimately made (to frame 20)
when the RETURN statement in frame 300 is encountered.
If it is required to make a return to a point other than the immediately following frame
the branch statement is modified slightly. Thus, the MICROTEXT statement -+ 200
RETURN 60 would cause the subroutine at frame 200 to be invoked with a return to
frame 60 on termination.
Similarly, the statement -+ 200 RETURN 100 would cause the same subroutine to be
invoked with a subsequent return to frame 100. Examples of the use of simple
subroutines are given in Figure 2,3, and 5. In Figure 2 frame 60 is a subroutine frame. It
is invoked at various points in the program by the following statements:
+ 60 RETURN 25 (in frames 10, 15 and 20)
-+ 60 RETURN 40 (in frames 30 and 35)
-+ 60 RETURN 55 (in frame 50)

Conditional branching to different subroutines is illustrated by the statements contained

in frame 65 of Figure 3. A more substantial subroutine frame sequence is illustrated by
the help facilities coded in Figure 5. Here, frames 900-920 constitute the subroutine set.
The help subroutine is invoked implicitly (because of the effect of the $HELP command)
by statements in frames 6 and 16. Help facilities are discussed in more detail below.

(e) Dialogue monitoring

One of the most useful features of the MICROTEXT language is the summary facilities
that it provides. These enable the dialogue engineer to build up a summary of the
human-computer interaction that takes place during an interactive session. This can
then be archived on a disc file or printed out as a report at the end of the session. A
summary can therefore be used to provide valuable feedback information to the
dialogue designer. Items that are to be included in a summary are placed after response
tests and are prefixed either by a single (*) or double (**) asterisk. All items prefixed in
this way will be copied to the summary when the frame is used. As an example of the way
in which this works, consider the following frame:
*10
What is the capital of America?
?
WASHINGTON-,20, NEW YORK+30, -40
**capital: (ANS)
178 P. G. Barker

The last line of this frame represents a summary item; it would cause the user’s response
to be entered into the dialogue summary. If this reply happened to be WASHINGTON
then the entry made in the summary would be capital: WASHINGTON. Entries in the
summary can be made more or less verbose-as illustrated in the following examples:

(i) *100
Please type your name:
?
-200
**(ANS)
(ii) *200
What is the capital of England?
?
DURHAM+ZO, LONDON+30
**user claimed that (ANS)was
**the capital of England.

(iii) *300
Is Washington the capital city of the USA?

Y-+20 *user knows capital of USA

N-30 *user does not know USA capital
+300

The frame shown in the first example produces a minimal entry in the summary whereas
in the second frame the user’s reply is expanded quite considerably. In the third example,
the entry made in the summary will obviously depend upon whether the user replies with
a Y or N response. Another useful summary feature that the system provides is the
ability to make a trace of the frames executed; this can be achieved using the $TRACE
SUMMARY command. This facility is extremely useful when modules are being tested
and evaluated. Summaries may also be used to store variables which can be recalled later
in order to restart a presentation which, for one reason or another, was interrupted.
At any particular point in a module a summary may be displayed, archived or printed.
This is achieved from within a lesson by coding appropriate SUMMARY commands at
suitable points within the module. Some examples of such commands are presented
below along with the annotation that describes their effect:

(i) $COMMENT display summary on VDU screen

$SUMMARY
(ii) SCOMMENT print summary on printer
ESUMMARY PRINT
(iii) $COMMENT save summary in file S.SUMMARY
$SUMMARY SAVE

(iv) SCOMMENT save summary in file S.JACK

$SUMMARY SAVE S.JACK

(v) SCOMMENT save the summary in a file whose

$COMMENT name is the value of the
SCOMMENT variable FNAME
SSUMMARY SAVE FNAME
 MTCROTEXT: a new dialogue programming language 179

The way in which this facility may be used to produce a simple dialogue trace is
illustrated in the MICROTEXT implementation of the letter guessing game presented in
Figure 5-see frames 2, 16 and 999.
Undoubtedly, the summary facilities of MICROTEXT provide a very powerful
mechanism for monitoring user interaction with software modules. It is thus a very
attractive feature of this dialogue programming language.

(f) Hel/, facilities

Within interactive dialogues, situations often arise in which the user does not know what
to do next, and so, often requires additional assistance or help. Like IPS (but unlike
PILOT), MICROTEXT provides a special facility to enable the implementation of
aiding schemes and help systems. The facility is provided by means of the $HELP
command. This enables the dialogue designer to define a subroutine that will be invoked
if the user types the reply ‘HELP’ in response to an input prompt. The way in which this
facility is used is illustrated in frames 100 and 800 below:
*100
Type HELP if you need extra assistance.
SHELP 800
What is your name?

*I300
SCOMMENT A simple help subroutine
I would like you to type your SURNAME
followed by a comma and your CHRISTIAN
NAME. Here is an example:
BARKER, PHILIP
$PAUSE 100
+ RETURN

In the above example the help subroutine frame (number 800) is invoked only if the user
replies with the string ‘HELP’ when the input prompt is given. Any other response is
taken to be the user’s name.
Help facilities of the type described above enable the program author to design and
fabricate software which can be highly user-friendly. This is a very important
consideration when using computers for instructional use-particularly, for low age
groups or users that have an inherent fear of this type of technology.

5. MICROTEXT commands
An important feature of the MICROTEXT dialogue programming language is the wide
range of commands that the system makes available. These may be broadly classified
into two categories-direct and indirect. Those in the first category are issued directly by
the user when the MICROTEXT system is in command mode. Those in the second
category are used as embedded commands within a software module and are executed
only when the MICROTEXT system is operating in run mode. Run mode is initiated
from command mode by issuing a RUN command. When in this mode, indirect
commands (which all commence with a $ symbol) take effect and so may be used to
180 P. G. Barker

control the nature and progress of the dialogue that takes place between the user and the
computer. Some of the more important commands provided by the MICROTEXT
system are listed in Table 1.

Table 1. MICROTEXT commands

(b) Run mode

(a) Command
mode General Graphics and sound Port and device control

COMMENT $ALLOW $COLOUR $USET

CONTINUE $CAS $GCOL $UWAIT
COPY SCLEAR $PLOT $OUTRS*
ERASE $COMMENT $MOVE $INRS*
EXIT SEND $DRAW $INKEY*
EXTRA* $FIX $POINT
FETCH* $HELP $TRIANGLE
FRAME $JOIN $ORIGIN
FREE $LINE SPALETTE
HELP $MODE $CHARACTER
LIST $NEW $SOUND
LOAD $PAUSE $ENVELOPE
NAME $RANDOM $BEEP
NEW $SCROLL
PRINT $SUMMARY
RUN $TIME
SAVE $TRACE
SUMMARY
TEST
VARIABLES
(escape)
l Only available with the ‘professional’ version of MICROTEXT.

The direct commands are listed in section (a) of the table. The purpose of most of
these has already been outlined. In general, they allow: (a) frames and modules to be
manipulated in various ways; (b) transitions from command mode into other modes;
and (c) the provision of a number of important programming aids, such as program
debugging tools (see below), and mechanisms for inspecting summaries and the values of
variables.
In Table l(b) the indirect commands have been further subdivided into three groups.
Those in the right-hand column provide the programmer with a means of controlling
(and examining) the signal levels of the input/output lines that constitute the
microcomputer’s external I/O port. It also contains special commands for the control of
ancillary peripheral devices-such as video-tape recorders, slide projectors and so on.
Because of ongoing development of the MICROTEXT language (and advances in
technology generally) the set of commands in the right-hand column is continually being
expanded. The groups of commands in the central column of Table l(b) are only
available with certain microcomputer systems. Where they are available they provide
 MICROTEXT: a new dialogue programming language 18 1

facilities for the generation of sophisticated colour graphics and sound effects. By means
of these the software designer can greatly enhance the quality of frames and, of course,
the impact that they have on the user. Depending upon the type of hardware used, it is
possible to employ the high-resolution facilities provided by the CRT screen as well as
the low-resolution teletext block graphics. Obviously, the exact nature of the graphic
and sonic facilities that are available (and the way in which they are implemented) will
depend upon the type of microcomputer system that is used.
Several of the run mode commands listed in the left-hand column of Table l(b) have
already been described and their use illustrated in the example programs that have been
presented previously. They provide facilities to: control screen layout ($JOIN, $FIX,
$CLEAR, $SCROLL, $LINE, $MODE); perform case conversion @CASE); generate
random numbers @RANDOM); time events @TIME, $PAUSE); produce summaries
@SUMMARY); document the software @COMMENT); initialize variables and
summaries @NEW); control the use of help subroutines @HELP); monitor the flow of
control through a module @TRACE); and, control the interrupt options available to the
user during lesson execution (SALLOW). In addition to these commands, special
techniques exist to enable the programmer to utilize the operating system commands
belonging to the microcomputer upon which MICROTEXT is running. Some examples
of these ($*FX2,1, $*FX7,8, etc) and the way they are used are illustrated in frames 500.
510, and 8.50 of Figure 7. Naturally, these will be machine and implementation
dependent. Further details may be found in the appropriate language reference manuals
(Bevan & Watson, 1982, 1983).

6. Program debugging
In order to ensure that a MICROTEXT program runs correctly and produces the
intended results it should be extensively tested and debugged. This may be achieved by
running it in test mode. Entry into this mode takes place when the programmer issues a
TEST command; execution of the module may then commence from any specified
frame. Once the program is running in test mode its execution may be interrupted by
pressing a special key on the microcomputer keyboard. The system then enters into
interrupt mode and an interrupt menu is displayed within the frame command line on the
VDU screen. This takes the following form:
Cont Stop Back Goto Edit Vars $.
The programmer may now type in a single letter in order to indicate to the system what
action is to be taken. The significance of the options is as follows:
C causes the system to continue executing the module from the start of the current
frame;
S stops the execution and returns to command mode;
B makes the system go back to the beginning of the frame containing the previous
question;
G goes to a new user specified frame number;
E causes a transition into edit mode;
V causes variable names and values to be displayed on the VDU screen one at a
time; and,
182 P. G. Barker

$ prompts the user for a $ command (see Table 1).

The above options provide quite powerful facilities for testing software written in
MICROTEXT. Of course, when a module is operating in run mode it can also be
interrupted in a similar fashion. However, in this case the range of options available can
be limited by the use of the $ALLOW command.
Two other important debugging aids are worth mentioning: the COMMENT and the
$TRACE commands. The first of these may be used to convert an executable frame into
a comment frame. This therefore causes its execution to be suppressed. The reverse
effect-conversion of a comment frame back to an executable frame-can be achieved
by isuing a FRAME command. This type of interconversion capability provides a very
useful testing aid. The $TRACE command causes the MICROTEXT system to trace the
execution of frames while a module is running in test mode. Frame numbers can be
stored in the summary or displayed on the VDU screen. The trace facility is useful for
checking that frames are being executed in the intended order.

7. Some applications of MICROTEXT

We have been using MICROTEXT to implement a number of frame-based dialogue
systems. Three examples are described in this section. These relate to arithmetic drill and
practice, simple game playing and the control of an interactive video-disc system.
(a) Arithmetic drill and practice
Simple arithmetic drill and practice is a well documented technique for use with
interactive computer systems (Barker & Yeates, 1984). The arithmetic drill and practice
module shown in Figure 4 is fairly straightforward. However, the absence (within
MICROTEXT) of any form of array variable requires the use of a special mechanism for
variable initialization. This is achieved in frame 10. First, a random number in the range
1-12 is selected. Then, a series of arithmetic comparisons are used to select which branch
statement becomes operative-and hence the values assigned to the variables QUES and
SANS. Notice that the target of all branch statements in frame 14. After 10 questions
have been attempted the student is told his/her score and is then given an appropriate
feedback message.
(b) Simple game playing
Games are an extremely important application of interactive microcomputer-based
systems. In the letter-guessing game shown in Figure 5 the mechanism of variable
initialization used to assign values to LE, VE, HO, CU and LO is similar to that which
was employed in the previous coarseware module. A random number in the range l-26
is employed to select which branch statement is used for the initialization. Notice how
the initialization statements have to be split over two consecutive frames. This is
necessary because of the physical limitations imposed by the microcomputer VDU
screen-for the microcomputer used to develop this module only 22 lines were available
for the text of a frame. The special HELP facilities of MICROTEXT are used to provide
the user with additional assistance should this be necessary. Frames 2, 16 and 999
illustrate how ‘the MICROTEXT summary facility may be used to monitor certain
aspects of the humancomputer dialogue-in this case, the summary produces a list of
those letters which the user did not get correct.
 MICROTEXT: a new dialogue programming language 183

(c) Interactive video-disc control

The equipment needed to implement an interactive video-disc system is illustrated
schematically in Figure 6 (Byte, 1982a; Barker, 1983c; Duke, 1983). The microcomputer
system is connected to the video-disc player (Philips, 1982a, b) by means of a standard
serial RS232C interface (Stone, 1982). This interface is bidirectional. It enables signals to
be sent (a) from the computer to the optical disc, and (b) from the disc to the
microcomputer. The interconnection of the video-player and the Teletext TV set is
achieved via the aerial socket of the latter, using standard coaxial cable.
Programs running within the microcomputer act as a software interface to both the
program author and the end-user. In addition, these programs are used to (a) control the
mode of operation of the video-disc, and (b) produce special codes that may be passed to
the TV set (via the disc player) in order to generate Teletext graphics (Barker, 1983~).
These may be superimposed on top of the video frame images that originate from the
optical disc thereby producing very colourful and stimulating visual effects. The
software for controlling the interactive video equipment can be written in BASIC or
PASCAL-or whatever programming language is available on the microcomputer
system. However, as was mentioned above, we have been developing our software using
the MICROTEXT authoring facility.
At the time of writing this paper two versions of MICROTEXT were available-the
Professional and Domestic. The first of these differs from the second in several ways. For
example, the Professional version allows the user to extend the language and it also
provides additional commands for device and port control-see Table 1. All of the work
described in this paper has been conducted using the Domestic version of
MICROTEXT.

Teletext TV system

I I
\[
Philips VP705

Feedback signals
-
Control Information for the disc
‘1
plus teletext overlay lnformatlon
RS232C interface for the TV system
A-‘, RS232C (1200 baud)
1300 baud)

Figure6. A computer-controlled interactive video-disc system.

184 P. G. Barker

In our experiments a BBC microcomputer system (Coll, 1982) was used to control the
video-disc player. For convenience, we used the microcomputer’s RS423 serial port
(Stone, 1982) in order to achieve the video-disc interconnection. A listing of a simple
illustrative control program written in MICROTEXT is presented in Figure 7. This
module controls the video-disc system in which a way that it repeatedly shows the end-
user a pre-specified sequence of frames that are retrieved sequentially from the optical
disc. The starting frame number, final frame number, number of repeats and the delay
interval (in seconds) between each repetition is specified by the end-user by means of a
simple interactive dialogue. A simple form-based menu similar to that shown in Figure 8
is used to prompt the user for the necessary control information. The way in which the
colour effects are produced will be described in detail later. Once the user has entered the
starting-frame and finishing-frame numbers (see MICROTEXT frames 110 and 112 in
Figure 7) the program deduces the required direction of play (either forward or reverse).
It then selects the appropriate video-disc command (Philips, 1982a) for this mode of
operation: either N for forward play (see frame 140) or 0 for play in the reverse direction
(see frame 130). Frame 170 uses a series of concatenation operations in order to
construct a picture retrieve command (PdddddR) and a picture stop command
(PdddddS) for the video-disc player. In these commands, ddddd represents the actual
video-disc frame number involved in the specified operation.
As soon as the control commands have been constructed, they are sent as character
strings to the video player via the microcomputer’s serial input/output port. Frame 200
sends a Teletext header command to the TV set in order to initialize its storage buffer.
Frame 220 is then used to cause the video-disc read head to move to the required picture.
After a suitable delay period (frame 222), the presentation of pictures from the disc
commences when the start play command is issued (frame 225). The video player must
now be told the picture number that it is to stop at; this is achieved by MICROTEXT
frame 230. At frame 250, the number of repeat showings is checked. Provided that the
required number of repeats has not been shown the system pauses for the time interval
specified by the user (frame 270) before branching back to frame 200 in order to initiate
another repeat performance.
The outstanding feature of the demonstration program presented in Figure 7 is
undoubtedly the colour effects associated with the various frames that are displayed to
the user-an example is given in Figure 8. The MICROTEXT author controls the use of
colour by means of appropriate combinations of function keys. The microcomputer
keyboard contains 10 function keys (labelled FGF9) each of which has a special
meaning. Combinations of these keys can be used to specify the colours that are to be
used for (a) the text that appears on the screen, and, (b) the background against which it
appears. These colour specifications are coded on a line-by-line basis. Coding colour
requirements is therefore extremely simple. If the MICROTEXT author types the
function key FO followed by F2 this will cause any subsequent text typed on that line to
appear in green against a black background. In order to specify the colour of the
background upon which text appears, a special control code combination is used-F2
followed by FO. Thus, if the author now types the following sequence:

ml m II THE CAT SAT HERE -1

\ /(
Text colour (red) Carriage return
\ ’ New background command
Background colour (yellow)
 MICROTEXT: a new dialogue programming language 185
- _ .-__.
il '170
I” SCOMMENT Construct commands for the BCOMMENT Wait for acknowledgement
rliTh,s program my be used
MICKOIEXT $COMMENT control of the wdeo disc. SCDMMENT signal from the video disc.
***to show d series of frames from an S(SF="P"S<NUMl>&"R") ;$I;?:' Select RS423 port ior rnpu:
**#optical disc. $(LF="P"&CNUM2>&"S") l

*#lit shows the sequence repetitively . . . . . . . . . . . . .._..._.._.........-...... %COMMENT Select baud rate
*."w,th a t,me deiay between each *zoo J*FX7.R
'r*show,rq ;;;M,:NT Send teletext header command
II f-610,-800

*,,J- ..” _... ;400 R&TURN 220

**/ANS> __
'5,fl
x3MMENT firan‘hto inltlallsatlon code ........ . .. . .. SCOMMENT Disable RS423 Port and
-hjC RETURN 100 SCOMMENT enable Inout from kevboard
'220 $NEW SUMMARY S'FX2.0
,I,U $CLW $MMENT Send start conanandt0 disc *RETURN
I:
-400 RETURN 222 +a00
'*(ANS> SCOMMENT Failed to get positive
SCOMMENT acknowledgement from the video
:*r EE(TERSTARTING FRAME NUkIBER@l..... *222 SCOMENT disc.
#I SCOMMENT Wait for acknowledgenent #FAILED TO GET POSLTIVE ACKNOWLEDGEMENT
OCOMMENT from the video disc aFROM THE VIOEO DISC
I*’ EllTERLAST FRAME NUMBER ez.....
-500 RETURN 225
IS SEND
*a( ENTER NUMBER OF REPEATS 83.. _....__...,..._....,..._........~......
xi ‘225 $NEW SUMMARY '850
SCOMMENT Put video disc Into play mode ICOMMENT Initiallsation routine for
11(*INTERVAL BETWEEN REPEATS @4..
IY I(REP=REP-A),, BCOMMENT video disc using a BBC
IS J$:;;INTI 0 ) SCOMMENT microcomputer 8s.controller
Pd SCOMMENT Select RS423 port for output.
S” -400 RETURN 230 S'FX5.2
i-,x l*<P:~s> SCOMMENT Select ba"d rate:
_,_.....__,...__...,._............- S.FX8.7
‘1I3 =NUM, "230 INEW SUMMARY SCOMMiNT Initlallse teletext varldblr:
aCOMMENT Get start~"g frame ICOMMENT SEND LAST FRAME NUMBER TO S(TTEXT="T/HCL")
:,j, ICOMMENT THE VIDEO DISC +.ETURN
r,,r..;EI;ML...'.......'.............,'. ?LF
-400 RETURN 240 900
iCOMMENT Get flnishlng frame **CANS> 1x
!I: .._,.._.............,,.__.,,....,.... “XI TASK FINISHE
. 1"
'240
'114 =REP $ENU
SCb:IMENTWait for acknowledgement
SCOMMENT Get number of repeats
:;r? SCOMMENT from the video disc
-500 RETURN 250
';I6 =INT
.,._..,...._.................
,;,hME!,T Get t,nieInterval '250
:REP
,..................,.... .,,...,...................
*1,c '260
S(KEPT=REP)
~$J~~E;~PT-REP'
ii;",",:="""'-""Ml)
#1
i~'30.0-135,.140
#~riOONE> REPEATS WERE PERFORMED
,.. II""
*ih
SPAUSE 20
-go0
.._..........................
*270

*135
SLINE lb #I
###BEEN AROUND THE LOOP (DONE, TIMES
It:,THE STARTING AND LAST FRAME NUMBERS
###(REP, TIMES STILL TO GO AROUND
W** ARE THC SAME. @PLEASE RETYPE THEM bX
YX
BPAUSE (SEC:
j?ktlSE10
-200
$UNF:X
.._,..,,..,,..
-*loo
l400
iijc! .. ,... SSUM1+ARYPRINT
ICLEAR
S(SlARTm"h")
-,:I: -RETURN
.. . . . .. .

Figure 7. MICROTEXT program for video-disc control.

it would cause the string ‘THE CAT SAT HERE’ to appear on the screen in red letters
against a yellow background.
In Figure 7 the positions of the colour control codes are denoted by the # symbols
which appear at the beginning of lines contained within certain of the MICROTEXT
frames. Notice that in some frames (for example, frame 135) certain lines contain
function key combinations in positions other than at the start of a line. This has the
effect of causing a colour change from the point within the line at which the code
186 P. G. Barker

specification occurs. Thus, the last text line in frame 135 commences with white letters
but finishes with cyan ones at the end.
Undoubtedly, these simple key combinations provide the MICROTEXT author with
an easy means of producing impressive colour effects. Of course, Teletext graphic
characters (Reis, 1976) can also be employed in order to generate a wide variety of
graphic effects. These can be relayed to the Teletext TV and combined with images that
originate from the video-disc. Quite spectacular visual (and sonic) effects can therefore
be produced using this type of system.

8. Conclusion
MICROTEXT offers a very straightforward solution to many of the problems presented
by frame-based dialogue programming. A major advantage of this language is its
relative ease of learning. Indeed, once potential program authors have acquired its basic
rudiments it becomes very easy for them to generate effective software. Within the
MICROTEXT system there are particularly good facilities for (1) testing and debugging
software, (2) monitoring human-computer dialogues, and, (3) producing colourful and
graphically orientated frames. However, the language does have a number of minor
limitations-for example: arithmetic is restricted to integers; there is only a limited range
of arithmetic operators ( + and - ); there are no array variables (but these can be
simulated); the facilities for conditional statement execution are not as good as those
available in other languages (such as IPS and PILOT); and, at present, there is only a
relatively small number of standard built-in functions and commands for controlling
ancillary devices. Despite these limitations, however, MICROTEXT can be used to
create quite effective dialogue programs for use on microcomputer systems.
Undoubtedly, once dialogue engineers have experienced this language they will find it
an extremely useful and productive programming facility. Of course, it must be
emphasized that certain programs that have been used for illustration and discussion are

t
3 Lines (red background)

ENTER STARTING FRAME NUMBER 15000

ENTER LAST FRAME NUMBER 15500

9 Lines (yellow background
with blue text)
ENTER NUMBER OF REPEATS 07

ENTER INTERVAL BETWEEN REPEATS 25

t
3 Lines (red background)

Figure 8. Form-based input menu for video-disc control.

 MICROTEXT: a new dialogue programming language 187

not as elegant and efficient as they could have been. These attributes have been sacrificed
in favour of ease of exposition. Therefore, the shortcomings of the programs presented
here should not be interpreted in terms of limitations imposed by MICROTEXT.

Acknowledgements
The author is indebted to Tim Skipper for programming many of the test modules used
during the investigation of the MICROTEXT system. He would also like to thank: (a)
Robert Watson, Nigel Bevan and Dianne Murray of the National Physical Laboratory;
and (b) Ravinder Singh of the UK’s National Computing Centre for their help and
many useful suggestions. Teesside Polytechnic is gratefully acknowledged for the
provision of financial resources to enable this work to be undertaken.

References
Barker, P. G. 1983~. Frame programming in BASIC. Working Paper, interactive Systems
Research Group, Department of Computer Science, Teesside Polytechnic.
Barker, P. G. 19836. Dialogue programming with PILOT. Electronics and Computing Month[v, 3
(3), 78-80 (Part 1); Issue 5, 70-72 (Part 2).
Barker, P. G. 1983~. Video disc programming for interactive video. Wireless World, 89 (1574).
44-48.
Barker, P. G. 1984. MUMEDALA-an approach to multi-media authoring. British Journal of
Educational Technology, 15 (l), 4-l 3.
Barker, P. G. & Singh, R. 1982. Author languages for computer based learning. British Journal qj’
Educational Technology, 13 (3), 167-196.
Barker, P. G. & Singh, R. 1983. A practical introduction to authoring for computer assisted
instruction. Part 2: PILOT. British Journal of Educational Technology, 14 (3), 17+200.
Barker, P. G. & Singh, R. 1984. A practical introduction to authoring for computer assisted
instruction. Part 3: MICROTEXT. British Journal of Educational Technology. 15 (2), 82-106.
Barker, P. G. & Steele, J. 1983. A practical introduction to authoring for computer assisted
instruction. Part I: IPS. British Journal of Educational Technology, 14 (I), 26-45.
Barker, P. G. & Yeates, H. 1984. Zntroducing Computer Assisted Learning. Englewood Cliffs, NJ:
Prentice-Hall. (to be published).
Bevan, N. & Watson, R. 1982. MZCROTEXT Reference Manual (V2.OC Preliminary edition).
National Physical Laboratory, UK.
Bevan, N. & Watson, R. (Eds) 1983. MZCROTEXT for the BBC Microcomputer. Cambridge:
Acornsoft Ltd.
Byte 1981. SMALLTALK, Special Edition of Byte: The Small Systems Journai, 6 (8).
Byte 1982a. Znreractive Videodiscs, Special Edition of Byte: The SmaN Systems Journal, 7, (6).
Bvte 19823. LOGO, Special Edition of Byte: The Small Systems Journal, 8 (8).
Coil, J., 1982. The BBC Microcomputer User Guide. London: British Broadcasting Corporation.
Duke, J. 1983. Interactive Video: Implications for Education and Training. CET Working Paper
No. 22, Council for Educational Technology for the Unitid Kingdom.
Gaines, B. R. & Shaw, M. L. G. 1983. Dialogue engineering. In Designing for Human-Computer
Communication (M. S. Sime & M. J. Coombs, eds), pp. 23-53. London: Academic Press.
Gilman, L. & Rose, A. J. 1974. APL: An Interactive Approach. New York: John Wiley.
Philips 1982a. Philips VP705 Professional Laservision-Operating Instructions, Publication No.
PRD-4044.
Philips 19826. Philips VP705 Professional Laservision-Product SpeciJication, Publication No.
PRD-4042.
188 P. G. Barker

Reis, C. W. B., (Ed.) 1976. Specification of standards for broadcast Teletext signals. In I&t
Technical Review, No. 2, 3rd Edition, pp. 76-89.
Stone, H. S. 1982. Microcomputer Interfacing. New York: Addison-Wesley.

Philip Barker is a Principal Lecturer in the Department of Computer Science at Teesside

Polytechnic. He is a graduate of the University of Wales, a Member of the IEEE, and a Fellow of
the British computer society. His research interests lie in the area of human-machine interaction.
He has undertaken a number of studies of the user interface with computer systems. The research
topics in which he is currently interested include: author languages for computer assisted
instruction (CAI), application of CA1 to the problems of the disabled, query languages for data
base systems, intelligent interfaces and image processing for video-disc systems. Dr Barker has
recently published a book entitled Computers in Analytical Chemistry. His latest book, Introducing
Computer Assisted Learning, is soon to be published by Prentice-Hall.