Exhibit 1016 – Part 2
`
`Exhibit 1016 — Part 2
`
`

`
`Dialogue structures —forms, commands and hybrids
`
`111
`
`reporting errors immediately may be distracting but immediate confirmation
`of a coded value as a result of a validation may also be desirable. As a rule of
`thumb, in cases where the input comes from a source document, validation is
`deferred to the end of the form to avoid disrupting the keying process; where
`there is no source document, validation is immediate.
`If any errors are encountered, the dialogue does not redisplay a new blank
`form; the form with the previous answers is shown with any erroneous items
`indicated. In the human-human analogy, you only get a new form if you have
`made such a complete mess of the previous one that it is simpler to start again
`from scratch.
`As with the Q&A and menu structures, an individual answer may represent
`either selection from a list of possible replies or an arbitrary data value. It is
`traditionally entered as a text string but, as we saw in Chapter 4, a selection
`input may be made by scrolling round a supressed menu; this is analogous to
`‘delete as appropriate’ on clerical forms.
`
`5.2.2 Design Criteria
`
`Forms are a natural mechanism for the entry of transaction data since a
`transaction, by definition, comprises a relatively standard set of data values.
`Thus, the structure is particularly appropriate where the source of the data is
`an existing clerical form. In the example of Fig. 5.1, the dialogue knows in
`advance precisely what data items are required since a field is defined in terms
`of content, slot and attributes.
`The criteria discussed in Section 4.3.2 for Q&A apply to the phrasing and
`display of the individual questions on the form. Answer fields should be
`clearly differentiated from the rest of the form by boxing with a particular
`attribute or by delimiting them with ‘decorators’ such as the brackets in the
`example of Fig. 5.1; the remainder of the screen should be protected so that
`input echo is restricted to these areas. The fact that the screen contains a
`number of questions imposes additional requirements which complicate the
`design of the screen layout; layout considerations are discussed in Chapter 7.
`It is essential that the form displayed on the screen should match any
`clerical form from which information is to be taken. It need not have exactly
`the same physical appearance, indeed this can result in a very cluttered screen,
`but all input items must appear in the same relative order and have the same
`format as the source data. The reasons for this are obvious if you consider the
`input process.
`
`

`
`112
`
`Chapter 5
`
`Often, all the items required cannot be displayed on a single screen but
`must be broken into sections which are displayed on successive screens. It is
`essential that this breakdown preserves a logical grouping so that related items
`are not split over different screens. An existing clerical form will provide
`strong clues as to where such breaks should occur; Chapter 7 provides an
`example of this process.
`The forms structure is highly supportive. Where a physical form provides
`the source of the input, little additional support is required from the dialogue.
`Since the user is required merely to transcribe the information, the screen can
`be relatively full, with the questions merely terse captions. The minimum
`requirement is that the user can read his input to check it.
`Where there is no corresponding physical form, a user will read the screen
`form to determine the input required. The screen must therefore be less full
`and the questions more explanatory. Help and error messages should be
`specific to a particular question and the user should be able to request help in
`response to any question on the form. Support can also be provided by
`including format details in the questions or answer fields, e.g.
`
`Invoice Date (dd/mm/yy)[
`
`] or Invoice Date [
`
`/
`
`/
`
`]
`
`It is important not to over-format the input in such cases; the address format
`
`No & Road [
`District
`[
`Town
`[
`County
`[
`
`]
`]
`]
`]
`
`admits only of a typical suburban address whereas address styles vary widely
`depending on location. With one particular public utility,
`it
`is almost
`impossible to book a service if you live on a farm — their computerised
`booking system insists that every house has a number and will not proceed
`further until the number is input!
`A potential problem occurs where a clerical form contains additional fields
`which are not required to be input. Such areas on the clerical document
`should be clearly distinguished from those containing data to be input. A
`clerical form may also contain optional items, or items which are completed
`only if a given value is entered in an earlier field; ideally, these should occur
`at
`the bottom of the form. If this is not possible,
`the system should
`automatically skip over any question, corresponding to these optional items,
`which does not require an answer and should provide confirmation that it has
`done so.
`
`

`
`Dialogue structures —forms, commands and hybrids
`
`ll3
`
`5.2.3 Implementation
`
`Like the menu structure, the form structure has two main stages: a single
`
`display of the form followed by repeated requests for input until the form is
`complete. The form may be complete either when the user enters a specific
`form terminator or, if no such terminator is defined, when all the questions
`have been answered.
`A form can be defined as a set of output fields. Unlike a menu, however,
`there is no single way of subdividing this set into subsidiary structures which
`will define any form. There may be fields which, in some forms, perform the
`role of a ‘form header’ or ‘form trailer’; there are fields in Fig. 5.2 which
`obviously fulfil this role. There are other output fields which specify captions;
`although these represent questions to the user, they have no significance to the
`dialogue process. There are also various other outputs such as subheadings
`and ‘decorators’ which define the form’s outlines. We might consider all these
`output fields to be ‘background’ items which define the shape of the form.
`Thus a form can be described by a data structure of the type described in
`Fig. 5.3. Note that a simple boxing of the form could be accomplished merely
`by adding an attribute, boxed, to the FormDIB definition; see Question P1 of
`Chapter 4. Our FormFie1dListType definition allows a more flexible use of
`decorators.
`
`Fil Definition
`
`Content:
`
`[
`
`I51!!!
`
`Foreground[
`Bold (y/n)
`[
`
`]
`]
`
`Background
`Blink(y/n)
`
`[
`[
`
`F2 =he1P
`
`Fig. 5.2. An input form.
`
`Fcrml-‘ie1dL:lstType = array[1..MaxFomF1e1ds] of Fie1dType:
`1-"ormDIBtype - record
`NumberOfFormF:l.e1ds : byte:
`Form1"ie1dL:l.st
`: FormF:Le1dListType:
`and:
`Fig. 5.3. A form Dialogue Information Block (FormDlB).
`
`

`
`114
`
`Chapter 5
`
`The form in Fig. 5.2 can then be created by the program fragment:
`with FormDIB do
`begin
`Formoutline:='back=hlue,fore=wbite';
`TLCornet:=chr(20l);
`TRCorner:-chr(187);
`BLCorner:=chr(200):
`BRCorner:-chr(18B):
`horizontal:=chr(205); vertica1:=cbr(186):
`bar:=": space5:=":
`for k:=1 to 47 do
`begin
`bar:-concat(bar,horizontal)7
`spaces:=concat(spaces,'
`');
`end;
`Number0fFormFie1ds:=15;
`CreateFie1d(FormFieldList[1],concat(TLCorner,bar,TRCorner),
`2,lO,49,FormOut11ne);
`CreateFie1d(FormFie1dList[2],
`concat(vertica1,
`‘
`,vertica1),
`3,10,49,Form0ut1ine):
`CreateFie1d(FormFie1dList[3],concat(vertica1,spaces,vertica1),
`4,10,49,Form0ut1ine);
`createFie1d(FormFie1dL1st[4],
`concat(vertica1,
`'
`Content:
`,vertica1),
`5,10,49,Form0ut1ine);
`
`Field Definition
`
`[
`
`CreateFie1d(FormFie1dList[15],concat(BLcorner,bar,BRCorner),
`16,1o,49,FormOut1ine):
`end:
`
`The form can be displayed on the screen by the procedure DisplayForm
`illustrated in Fig. 5.4.
`
`procedure Disp1ayForm(FormDIB:FormDIBtype);
`var k : byte;
`begin
`clearscreeni
`with FormDIB do
`begin
`for k:= 1 to Number0fFormFields do
`Disp1ayFie1d(FormFie1dList[k]);
`end:
`end:
`(DisplayForm)
`
`Fig. 5.4. Defining and displaying a form.
`
`

`
`Dialogue structures — farms, commands and hybrids
`
`115
`
`What parameters are required to define the ‘foreground’ of the form? The
`foreground represents the answers which the user supplies to the questions on
`the form. The display of the questions themselves has been taken care of
`implicitly in the form background; as with the menu structure, a question will
`not normally be redisplayed when a particular answer is requested. There is
`no possibility of implementing a form in ‘teletype’ mode. However, it is
`conceivable that some indication, other than the input echo, of the current
`question may be displayed. For example, the question or a subheading might
`be highlighted. We will allow the possibility of an explicit question when each
`answer is requested.
`Thus, to process the user’s answer to the question requires the same
`parameters as in the Q&A or the menu structures, ie. those parameters which
`were specified in the QandA_DIB data structure. Since the values of these
`parameters are likely to be different for different questions, there will be a
`separate QandA_DIB for each question within the fonn. The foreground of
`the form is represented by a set of QandAJ)IBs as in Fig. 5.5.
`
`- array[1..MaxQuestions] of QandA_DIBtype;
`QandAListTypa
`QandASet_DIBtypa - record
`Numherofouestions : byte;
`QandAList
`: QandAListType;
`Currentquestion
`: byte;
`and:
`
`Fig. 5.5. Dialogue Information Block for form input.
`
`In practice, there are more efficient storage mechanisms than the structures
`comprising arrays of arrays of fields which we have used, e.g. arrays of
`pointers or linked lists. We will continue to use array structures for list
`structures in the descriptions because of their conceptual simplicity.
`A ControlDIB must be initialised with values which control how the input
`will be handled by the input/output processes for each Q&A step; the need for
`consistency dictates that these values will be the same for all items on the
`form. Additional control characters are needed to allow the user to skip over
`a question, to go back to a previous question and to hand the completed form
`back to the dialogue process. These values occupy three of the previously
`undefined elements ofthe Contro1DIBtype data structure as illustrated in Fig.
`5.6.
`Paz'ntNextField and P0intPriorField allow the user to scroll around the
`
`questions on the form; AcceptFarm provides a facility for the user to confirm
`completion of the form by pressing a specific key. If the ReadField process
`receives any of these characters, it terminates immediately and returns the
`
`

`
`116
`
`Chapter 5
`
`controlbtatypa - record
`cantrolauttar
`rubout
`Echoswitch
`Aceeptrield
`ReqnestAhort
`Requestflelp
`PointNextTarget
`PointPriorTarget
`AcceptTarget
`‘
`Polntflextfiald
`PointPriorF1e1d
`Acceptrorn
`tesarved4
`and;
`
`: byte;
`: byte:
`: offoni
`: byte:
`: byte:
`: byte:
`: byte;
`: byte;
`: byte;
`: byte:
`: byte;
`: byte:
`: Setofnytei
`
`Fig. 5.6. The ControlDIB with forms controls.
`
`control character in ControlBuffer so that the dialogue process can take any
`necessary action. If both PointNextField and PointPriorField are null, the
`user is constrained to answer the questions in order; if AcceptForm is null, the
`dialogue will assume that the form is complete when the last question in the
`set has been answered.
`The user also proceeds to the next question when he completes the current
`one. A question can be completed in two ways: manual skip requires the user
`to enter an explicit terminator character for each answer field; auto skip
`proceeds to the next question as soon as the answer field slot is filled. The
`ReadField process supports both these mechanisms. If ControlDIB contains
`a non—nul1 value for AcceptField, this value must be entered to terminate
`input —- a manual skip mechanism. If AcceptFie1d is null, the input will
`terminate when answer.slot.width characters have been entered — an
`autoskip mechanism.
`Manual skip is to be preferred unless the vast majority of the input is of a
`fixed length, in which case the need to type fill characters is minimal. What is
`to be avoided at all costs is a combination of the two, i.e. where a skip to the
`next field occurs either when the last input position is filled or when a skip
`character is input. Users will get into the habit of typing a skip character at the
`end of each input and will do so even where it is of maximum length, causing
`a double skip. This inconsistency is precluded with our single ControlDIB
`which controls all input throughout the form. There is another problem with
`auto skip which concerns the editing of input: if the user is going to make a
`typing mistake, he had better do it before the last character!
`A procedure, FormlnputIV, which performs immediate validation of any
`input which represents selection from a targetlist is illustrated in Appendix I.
`
`

`
`Dialogue structures - forms, commands and hybrids
`
`procedure FormInputDV(var QandASet_DIB:QandASet_DIBtype;
`var Contro1DIB:Contro1DIBType);
`var complete : booleant
`begin
`with controlDIB,QandAset_DIB do
`begin
`complete:-false;
`repeat
`Arbitrarynata(QandAList[currentquestion],Contro1DIB):
`QandALiet[currentouestionj.ErrorF1ag:-off;
`if equal(controlnuffer,RequestAbort)
`or equal(controlaurfer,AcceptForm)
`or ((Currentouestion=NumberofQuestions) and (AcceptForm=0))
`complete:=true
`else
`(test for scroll back)
`if equal(contro1Buffer,PointPriorFie1d) then
`if currentquestion-1 then currentquestionz-Numberofouestions
`else currentquestion:=CurrentQuestion-1
`(test for scroll forward)
`else
`it equal(conttolbufter,Pointnextrield) then
`it Currentouestion-Numberofouestions then currentQuestion.=l
`else currentquestion:-currentQuestion+1
`else (proceed to next outstanding question)
`begin
`while (currentquestion<-Numberofouestions)
`end
`(QandAList[currentquestionj.ErrorF1ag=off) do
`Currentquestion:=CurrentQuestion+17
`if Currentouestion>Number0fQuestions than
`it Acceptrorm-0 then complete:-true
`else CurrentQuestion:=l;
`end:
`if not equal(ControlBuffer,RequestAbort) then
`ControlBuffer:=0;
`(because it has been actioned)
`until complete:
`end:
`end: {FormInputDV)
`
`then
`
`Fig. 5.7. Input to a form with deferred validation.
`
`We will consider here a procedure, FormlnputDV illustrated in Fig. 5.7,
`which performs deferred validation. If validation is to be deferred until the
`form is completed, each input must be treated as an arbitrary data Value, i.e.
`each input field is accepted via procedure ArbitraryData (Fig. 4.5).
`When the Formlnput procedure returns, the user’s response to question k
`will be contained in QandAlist[k].answer.content. The dialogue must then
`invoke validation of each of these answers and, if an error is encountered, set
`the ErrorF1ag and ErrorMessage in the QandA_DIB for QandAList[k].
`This procedure is called repeatedly until all errors are eliminated as
`illustrated by the following program fragment:
`for k:=1 to Numberofquestions do
`begin
`(ensure each question is asked the first time through)
`(it's an error initially since he hasn't entered anything)
`QandAList[k].ErrorFlag:=on;
`(but there is no error message to display)
`QandAList[k].ErrorMessage.content:='
`':
`end:
`
`

`
`118
`
`,
`
`Chapter 5
`
`CurrentQuestion:=1;
`complete : -false,-
`repeat
`FormInputDV(QandASat_DIB,Contro1DIB)7
`if equal(Contro1Buffer,RequestAbort) then
`comp1ete:=true
`else
`begin
`NoErrors:=true:
`for k:-1 to Numberofouestiona do
`begin
`(validate answer k
`if invalid then
`set ErrorF1ag:=on for QandAList[k]
`set Errornessage content for QandAList[k]
`if NoErrors then
`NoErrors:=fa1se
`CurrentQuestion:=k)
`
`end:
`if Nofirrors then comp1ete:=true;
`and:
`until complete;
`
`Note that the process illustrated in Fig. 5.7 allows the user to change any of
`the answers, not just those that were flagged as invalid. This reflects clerical
`form filling; if you are handed back a form to correct, you can change
`anything on it. By default, the dialogue will request the next outstanding
`answer —- the next one with ErrorFlag set on. To ensure that all answers will
`be requested the first time through, the dialogue initially sets the ErrorFlag to
`‘on’ in each question.
`
`5.2.4 Summary
`
`Many interactive systems have a requirement for data entry via a standard
`sequence of questions. The form structure suits such usage, which is common
`in accounting and order processing applications. It is quicker than Question
`and Answer, it can handle a wider range of inputs than menus, and it can be
`used by any level of user. Most people are familiar with the concept of filling
`in forms even if they claim to abhor doing it! Because it has a sequential rather
`than a tree structure it is less appropriate for option selection.
`Another area where form filling has been used is to specify the parameters
`for querying databases. The mechanism is called Query by Example. The fields
`on which the database can be searched are displayed as column headings on
`a form. The user enters in each column the values on which he wishes to
`
`search. The values input in a given column are ‘ORed’ and the columns are
`‘ANDed’, so that an input of:
`
`

`
`Dialogue structures — forms, commands and hybrids
`
`119
`
`would select all SECretaries in LONdon, BIRmingham or MANchester and
`who are classed as having skills A or C. It eliminates the problems caused
`when parentheses must be used to cater for different precedence in the logical
`operators, e.g.
`
`(grade=SEC) and ((loc=LON) or (loc=BIR) or (loc=MAN))
`and ((skill=A) or (skil1=C))
`
`Multiple choice menus are also a type of form filling. With such a menu, the
`user is presented with a list of options but is not restricted to a single selection;
`he may make zero or more selections from it. Figure 5.8 illustrates such a
`menu which is presented to the user of a Terminal Emulator package, a
`program which enables a microcomputer to be used as a dumb terminal. Each
`of the options on the list represents a terminal characteristic which may be set
`or unset by the user. To change a characteristic, the user scrolls to the relevant
`option and types ‘y’ to set it, or ‘n’ to unset it. Thus the menu illustrated in Fig.
`5.8 is effectively a form with five questions, each of which expects a yes/no
`answer; the questions have a default answer and so he need not answer each
`explicitly. This structure is typical of multiple choice menus. Note that, as
`with most forms, the user can continue to scroll around the options until he
`presses the AcceptForm key, function key 1 in this case.
`
`Terminal Configuration
`
`Local Echo
`Local Print
`Auto Linefeed
`Auto LineWrap
`VTIOO Emulation
`
`press Fl to exit
`
`[Y]
`[N]
`[Y]
`[N]
`[Y]
`
`Fig. 5.8. A multichoice menu.
`
`

`
`120
`
`Chapter 5
`
`5.3 The Command Language Structure
`
`5.3.1 Features
`
`The command language structure is almost as commonplace as the menu
`structure, primarily because it has been a very common style for computer
`operating systems. It is at the opposite end of the spectrum from the menu
`structure. The use of the term ‘command’ reflects the parade ground analogy
`upon which it is based; the user is the drill sergeant and the system the
`subservient private. The private speaks only when he is spoken to. When the
`drill sergeant speaks he supplies in a single command all the information
`required to carry out
`the task he wants accomplished. This involves
`identifying the task and possibly supplying any data values which the task
`requires. For example
`
`— task requiring no data values
`‘Halt’
`‘Peel me a grape’ — task and associated data values
`
`or
`
`Traditional command language dialogues operate in teletype mode. The
`system says nothing except to display a constant prompt (such as the
`ubiquitous ‘drive>’ of most microcomputer operating systems) to indicate its
`readiness to obey. Each command is entered on a new line, and is usually
`terminated by a ‘carriage return‘ or ‘enter’ character.
`
`A>clir
`
`A>pip h:=a:*.com
`A>mode com1:9600,e,7,1,p
`
`The private does not question an order; if told to do something stupid, he
`proceeds to try to do it. Command languages basically adopt the same
`approach and assume that the user knows what he is doing. There may not be
`many cases of soldiers marching off a cliff because the sergeant said ‘right
`wheel’ instead of ‘left wheel’ but there are many cases where, for example, a
`old version of a file has overwritten a new version because the user got the
`copy command wrong.
`If a command is impossible to carry out, the private may say so without
`identifying the particular part which is impossible. Similarly, when further
`processing of the input line is impossible, a command language structure gives
`up, usually with a fairly non-specific error message, and the whole input must
`be repeated. For example,
`
`

`
`Dialogue structures —f0rms, commands and hybrids
`
`121
`
`A>dri a.*.com
`
`Bad command or filename
`
`(what is invalid?)
`
`5.3.2 Design Criteria
`
`Like the menu structure, a command language is appropriate for Input
`Control messages; it can, however, cater for a very wide range of options at
`any point in the dialogue, and does not require the background tasks to be
`hierarchically structured. Hence,
`it
`is appropriate to applications like
`operating systems where the background tasks form a flat structure of equal
`but distinct tasks, a sort of primaeval soup in which the tasks float like
`croutons waiting to be speared with a command fork!
`
`Although it can support a relatively large set of commands, in practice the
`number in common usage is normally limited to reduce the load on a user’s
`memory. Command language is
`the least supportive structure, and is
`appropriate to experienced and frequent users. Initial training is necessary
`before a user can use the system and he will only discover the full range of the
`system’s facilities by external instruction rather than by using the system itself.
`Furthermore, since the system has no way of knowing what the user wishes
`to do, it is difficult to provide help facilities other than of a very general
`nature.
`
`Because of the load imposed on a user’s memory by the structure, it is
`important
`that
`the command identifiers are chosen so as to have a
`commonsense interpretation and to be easy to remember. Naming of the
`commands, or even positioning of command keys, can provide perceptual
`clues to aid memory. Thus the cursor positioning commands in WordStar
`reflect their layout on the keyboard.
`
`Q W
`
`R T
`
`ctl+E = up a line
`
`ctl+A = word left
`ctl+S = char left
`
`ctl+F = word right
`ctl+D = char right
`
`Z
`
`C V
`
`ctl+X = line down
`
`This naturalness has not always been obvious in the command dialogues
`which have been implemented; it is doubtful whether many people who did
`not work with DEC equipment in the 19605 would immediately associate the
`PIP (standing for Peripheral Interchange Program) command of CP/M with
`a copy operation. The UNIX operating system provides some even more
`exotic examples.
`
`

`
`122
`
`Chapter 5
`
`The daigner must guard against excess functionality resulting from an
`attempt to cater for every possible combination of task requirements with a
`single command line; that is, against developing a multiplicity of different
`commands, often performing overlapping functions. Such attempts at
`‘helpfulness’ often result in a bewildering array of command keywords and
`syntaxes, most of which are seldom used and which confuse the majority of
`users.
`
`The dialogue must handle data messages. This is typically done in a
`command language structure by means of compound input messages where
`the command keyword (input control) is followed by a parameter list (input
`data). For example:
`
`PIP newfile=oldf1le
`
`contains the command keyword ‘PIP’ identifying a copy task and the
`parameter list ‘newfile=oldfile’ specifying that the contents of the file named
`‘oldfile’ are to overwrite the contents of a file named ‘newfile’, or to create
`‘newfile’ if it does not already exist. A parameter list may be expressed in one
`of two formats: positional parameters or parameter keywords.
`The meaning of a positional parameter value is defined by the relative
`position it occupies in the command string. Thus, in the example
`COPY thisfile newfile
`
`the first parameter is the ‘source file’ (the file to be copied), and the second
`parameter is the ‘destination file’ (the new file to be created). A delimiter such
`as a comma, a slash or a number of spaces is used to separate one parameter
`from another.
`
`With parameter keywords, each parameter value is preceded by a
`predefined identifier which specifies its meaning. Thus, in
`COPY SOURCE=thisf1le DESTINATION=newfile
`
`the kewords SOURCE and DESTINATION identify which filename is
`which.
`
`Positional parameters reduce the volume of input, but it is obviously
`essential that the values are entered in their correct order. Since rather
`
`unpleasant results can arise if you get the source file and the destination files
`the wrong way round, it is unfortunate that two widely used operating
`systems (CP/M and MS-DOS) use different orders in their respective copy
`commands! Positional parameters become particularly trying when the
`parameter list is long; some operating system commands take a dozen or
`
`

`
`Dialogue structures — forms, commands and hybrids
`
`123
`
`more parameters. When parameters can be omitted by entering two
`separators
`together at
`the appropriate position,
`this complexity is
`compounded.
`
`Parameter keywords reduce memory load in one respect since order is no
`longer significant, and optional parameters can simply be omitted;
`it
`introduces another load, however, by requiring the user to remember more
`keywords, and the designer to invent ‘meaningful’ names for them. This
`approach also requires more processing by the system to cater for the
`recognition of keywords, and the flexible order.
`In many command languages, the parameter list may also contain switches
`which alter the way in which the command is interpreted. Switches normally
`may occur anywhere in the parameter list and are denoted by an identifier; the
`prefix ‘—’ is used in UNIX and the prefix ‘/’ in MS-DOS. Thus, in UNIX
`(MS-DOS), a short form directory listing is invoked by the command
`
`ls mydirectory
`
`(dir mydirectory /w)
`
`and an extended directory listing with file sizes and dates by
`
`ls -l mydirectory
`
`(dir mydirectory )
`
`Many command languages support macros as a means of providing
`increased functionality in a single input without increasing the number of
`commands. A macro consists of a series of separate command strings stored
`as individual lines in a text file, called a Submit file in CP/M, a Batch file in
`MS-DOS and a shell script in UNIX. When the file name is entered, the
`individual command strings of the macro are executed one after another, as
`though they had been typed at the keyboard. Symbolic parameters may be
`specified in the command lines of the macro; these are replaced by the actual
`values entered as parameters of the macro when it is invoked. Thus if an MS-
`DOS macro called CLG.BAT contains the lines:
`
`pas %1.pas
`link %1.obj
`%l
`
`entering the command line ‘clg myprog’, will cause the execution of
`
`pas myprog.pas
`link myprog.obj
`myprog
`
`

`
`124
`
`Chapter 5
`
`5.3.3 Implementation
`
`There is an obvious similarity between a command input and form input. A
`Command input can be considered as supplying a series of answers to a series
`of implicit questions. Thus the input
`
`A>copy FromFilename ToFilename
`
`could be considered as answers to the implicit questions
`
`command 2 copy
`source
`: FromFileName
`destination : ToFileName
`
`Like the form, there must be some criteria for deciding that the user has
`completed the input; for a command, CarriageReturn acts as the terminator.
`However, unlike the form, the set of questions is not known in advance. It is
`not known until the particular command has been identified or, in some cases,
`which variant of the particular command. For example, the MS-DOS mode
`command comes in three different flavours:
`
`to set the screen mode
`mode {integer}
`mode coml:{BaudRate},{Parity},{DataBits},{StopBits},{Timeout}
`to configure the serial port characteristics
`mode lptl:={Pl|ysical}
`to assign a physical port to the screen echo
`
`The input process for a command language is usually compared with the
`parsing of a program statement by a compiler or (more accurately) an
`interpreter. Although the basic syntax of an input is very rigid, there may be
`several variants of a command and there is often a good deal of freedom
`about things like how many, if any, spaces may appear in it. The software to
`implement it is considerably more complex than that required for the other
`structures. Instead of matching a single response, the dialogue process must
`first split the command into its constituent parts (called tokens), and carry out
`a greater number of matching operations to determine what option is
`required, and what data values are being passed to which parameters.
`Figure 5.9 shows possible pseudo-code to implement a Command
`Language structure. GetResp0nse gets a string of characters from the
`keyboard, ending with a terminator character. The ReadField process could
`be used to accomplish this. GetToken gets the next token from ‘Response’. If
`GetToken is applied four times to a Response of ‘PIP newfi1e=oldfile’, it will
`successively return the tokens ‘PIP’, ‘newfile’, ‘=‘, and ‘oldfile’.
`
`

`
`Dialogue structures —forms, commands and hybrids
`
`125
`
`repeat
`Display BarePrompt
`GetResponse
`Matched:=true
`
`Set ValidTokens to possible commands
`while Matched and Morelnput
`GetToken
`
`Match Token against ValidTokens
`if not Matched
`
`Display ErrorMessage
`else
`
`Set ValidTokens to permitted values of next parameter
`endif
`endwhile
`
`if Matched check if Complete
`until Matched and Complete
`Fig. 5.9. Pseudo-code for a command language structure.
`
`5.3.4 Summary
`
`A command language is potentially the quickest and most flexible of all
`structures, and the majority of ‘natural language’ dialogues are basically
`command language structures with a very extensive vocabulary. Experienced
`users enjoy the feeling of controlling the system rather than being controlled
`by it. However, it offers little support and even experienced users find it
`difficult to utilise the full power; most are familiar only with the very limited
`subset of facilities which they use regularly.
`In fact many of the desirable aspects of a command language may be
`mimicked with the Q&A structures and processes discussed in the preceding
`sections. We will return to this topic in Chapter 9.
`
`5.4 Hybrid Dialogues
`
`It should now be apparent that the four basic dialogue structures are not
`totally distinct but are in fact all variations of the Question and Answer
`structure.
`
`A menu structure is Question and Answer modified so that a first level help
`
`

`
`126
`
`Chapter 5
`
`message, the menu, is displayed automatically before the option selection
`question is asked. A form filling structure displays a sequence of questions,
`the form, all at once, then asks for answers one at one time. A command
`language structure, particularly where positional parameters are used,
`is
`Question and Answer in which the user makes extensive use of ‘answer
`ahead’, i.e. supplies the answers to a series of implicit questions in response to
`a standard first question, the command prompt. These structures might be
`referred to as:
`
`Menu
`
`Form
`Command
`
`:
`
`:
`:
`
`help—ahead
`
`question-ahead
`answer-ahead
`
`Recognition of this fact provides some clues as to how a computer dialogue
`might adapt to different environments; we expand on this in Chapter 9. It also
`provides reasonable guidelines as to where each version of the Q&A structure
`might best be used.
`A menu structure will be appropriate in cases where:
`
`-
`
`the range of possible inputs is sulficiently small that they can be explicitly
`displayed;
`° the user needs the possible inputs to be displayed.
`
`This suggests that a menu should be used where a user who is
`inexperienced, or who is mainly using a pointing technique, is choosing from
`a limited range of values, i.e. typically in selecting a task process.
`A command language structure will be appropriate in cases where:
`
`the number of input values is small enough to be remembered;
`°
`' a limited number of responses is sufficient both to identify the task required
`and to supply its data.
`
`This suggests usage by experienced users where there is a fairly flat
`hierarchy of task processes with limited data input requirements.
`A Form structure will be appropriate in cases where:
`
`a standard sequence of inputs can be predicted
`
`suggesting usage for the entry of transaction data.
`The basic Question and Answer structure is a reasonable compromise for
`various levels of user. It can be used to substitute for all of the above, but will
`
`be particularly appropriate where:
`
`

`
`Dialogue structures — forms, commands and hybrids
`
`127
`
`0 the range of input values is too great for a menu structure or too complex
`for a command language;
`- the next question to be asked depends on the reply to the current question.
`
`An obvious problem with the simple classification above is that, even with
`a give