Context Free Grammars

It is clear that for a sequential dialogue, the interaction between the user and the computer can be thought of as a conversation between the_two, and hence can be modelled in terms of the structure of the language used by the two parties. This to some extent can even be applied to graphical user interfaces, in which the selection of icons etc, can be viewed as basic tokens from which the language of the interaction is composed.

A grammar is a set of rules which define valid constructions within a language. Grammars are well understood within the computing community due to work in the areas of programming languages, hence the use of grammars for defining the dialogue between human and computer was perhaps an understandable approach to take. A grammar is usually defined using a meta-language such as Backus-Naur Form (BNF) [Naur63]. In BNF a grammar is defined as a set of rules defining non-terminal symbols of a parse tree for the language.

Using this approach to define the dialogue between a user and the computer is very one sided in that it only defines valid input sequences from the user. Command language interfaces are characterised by the user entering a

command in response to the system prompting the user. Hence a grammar based dialogue model has to be augmented to include the system side of the interaction. In the SYNGRAPH UIMS [Olsen83], the augmenting was done by associating Pascal code with each production. The need to define the system side of the interchange tends to make the dialogue specification far more difficult to read than the specification of a programming language in BNF. MIKE [Olsen86] and MIKEY [Olsen89] were later developments based on the same ideas.

Multi-party grammars [Shneiderman82] are also based on BNF with the following additions to the basic BNF structure:

• Non-terminals are labelled with a party; either human (H) or computer (C).

• Non-terminals can have a value associated with them.

• A default non-terminal can be defined, that will match any input string if no

other parse match is possible.

An example of a multi-party grammar for a n open file command is shown in Figure 3.6.

<CMD> : : = <H : OPEN><C : OPEN- ACK> <H : OPEN> : : = OPEN <H : FILENAME>

<C : O PEN - ACK> : : = [ <H : FILENAME> ] IS OPEN

Figure 3.6: An example of the use of multi-party grammar. (Non-terminals are identified by

< >)

The definition of languages using BNF is straight forward and a number of tools are available to support the implementation of parsers, for example Lex [Lesk75] and Yacc [Johnson75]. However the use of dialogue specification languages based on BNF is not without problems. One major problem is that representation based on meta-languages (ie. languages for describing other languages) such as BNF are "are almost unreadable to the average person" [Hartson89; page 25] . Comparisons of BNF and state based representations have shown that latter to be easier to use for dialogue specification [Guest82;Jacob83] .

For direct manipulation interfaces the user o f grammars suffers from major limitations. Interleaving a nd concurrency are important features of such interfaces. Unfortunately grammars are not able to cope with either. Consider interleaving, that is the ability for the user to switch between two or more dialogues as they wish, returning to an earlier dialogue at some future point, and then being able to carry on from where they had left off.

A B

Consider Figure 3.7 in which two separate dialogues, A and B are depicted. In order to carry out dialogue A the user must carry out actions a, b, c, and d (in order). Similarly dialogue .B requires the user to carry out actions e, f, g and h. Support for interleaving would allow the user to carry out the two dialogues in the fashion indicated in the diagram, that is by carrying out actions a, e, f, g, b, c, d, h; or indeed any other combination of action sequences that preserve the ordering of actions for each dialogue. It follows that in order to model this with a grammar, a large number of rules are needed since there are a large number of valid action sequences (66 in the example). Although it might be possible to develop a tool that would construct all the rules need to recognise all the valid action sequences, it would be extremely difficult to develop a corresponding parser that could do so within acceptable time limits.

Grammars are unable to model concurrency. It follows that grammars are not a reasonable alternative for direct manipulation interfaces.

It should be pointed out, however, that for a command line style of interface the use of a grammar may well be the best suited. To quote Green "the user interface designer should be able to choose the type of notation that best suits the application at hand" [Green86].

Despite the shortcomings identified above, it is usefu l to consider the specification of the brush shape dialogue using a grammar representation. The terminal nodes within the specification represent lexemes within the system, a lexeme being produced by a lexical analyser that has parsed the user actions and ·generated the corresponding lexical tokens. Within the brush shape dialogue there are six terminal nodes corresponding to each of the buttons within the dialogue box.

Terminal_Nodes :

{ SELECT_VTHIN, SELECT_VTHICK , S ELECT_HTHIN , S ELECT_HTHICK , OK , CANCEL }

The specification is the brush shape dialogue is given within Figure 3.8. In this example annotation for addressing feedback and semantic linkage has been omitted.

Pa intTask · · = Pa inting PaintTask

SetBrushShape PaintTask

SetBrushShape · · = Select_Thicknesses OK

I Select_Thicknesses CANCEL

Select_Thicknesses · · = Select_VThickness Select_Thicknesses

I Select_HTh ickness Select_Thicknesses

I NULL

Select_VThickness · · = SELECT_VTHIN

I SELECT_VTHICK

Select_HThickness : : = SELECT_HTHI N

I SELECT_HTHICK

Figure 3.8: Specification of the brush shape dialogue using a context free grammar.

Reviewing the grammar based specification of the brush shape dialogue shown in Figure 3.8, the following observations can be made:

clearly specified

Repetition is modelled using recursive productions. For example, the rule Select_Thicknesses captures any sequence of selecting and re-selecting vertical and horizontal brush thicknesses, including the option of the user not doing anything. The behaviour of the dialogue box is captured in that the model is only able to define sequential behaviour, and consequently the definition of PaintTask implies that the SetBrushShape task has to run to completion before the next task is undertaken.

not specified

This specification does not address:

• the user actions. The terminal symbols (shown in upper case in the

specification) would need to be defined within a lexical specification of the system.

• the mutually exclusive behaviour of the thickness selections within each

orientation. The production for Select_ Vfhickness for example states that the user can select thin or thick options, but does not state that selection of one causes the other to become deselected.

• feedback and semantic actions. As was seen in the SYNGRAPH example, grammars need to be augmented with this information.

• default selections. In order to define default selections it would be

necessary to add a special initialisation rule to the specification, for example:

init : : = SELECT_VTH IN SELECT_HTHIN

and record the corresponding effects within the augmentation for that rule.