ROBART 1(ID:5686/rob001)Dialogue grammar based on BNFDialogue grammars based on BNF Phyllis Reisner, IBM Research Laboratory, San Jose, CA Related languages
References: in IEEE Trans. Software Eng., vol. SE-3, May 1977 view details Beyond Simple BNF We originally chose a BNF-like notation to describe the ROBART action languages because it is commonly used for describing other kinds of languages and has several properties that we liked. (It is relatively compact, is easy to manipulate automatically, and can describe an infinite language with a finite set of rules.) It soon became apparent, however, that a straightforward BNF-like notation was not the ultimate choice. We wanted a notation that would 1) describe all and only the legal strings for the user and 2) show the structure of the language with as few nearly redundant rules as possible. These turned out to be somewhat contradictory requirements unless we introduced the stratagem of "semantic restrictions" to prevent the generation of illegal strings. Without the semantic restriction given in the footnote for rule 9, for example, selecting box, then describing circle would be a permissible string. We could describe all and only the legal strings by a very lengthy grammar which listed each shape and by then redundantly having a rule for selecting and describing each one. But such a description would lose the general structure -- that most shapes are constructed in similar ways. On the other hand, we could write a more terse grammar than the one we have presented, showing more of the general structure, but at the expense of more semantic restrictions. For example, if we had one general rule saying that any shape had to be selected and described (rather than rule 9 for discrete shapes, and rule 68 for continuous ones), we would then need a semantic restriction to prevent selecting a discrete shape and describing a continuous one. A simple, straightforward BNF notation is clearly usable now. We can write two different forms of grammars, a lengthy "legal string grammar" -- of possible use in providing feedback to users about incorrect action sequence -- and a "structure revealing grammar" to locate design inconsistencies. However, in the long run better notational schemes need to be found or devised which reveal both structure and legal strings. While some pattern revealing formalism is required, and while BNF is an obvious first choice to explore and is clearly useful, it may not be the final solution. Abstract: Formal grammatical description has not generally been applied in the human factors area, which traditionally draws on behavioral science for its methodology. This paper illustrates, by means of a detailed example, how formal grammatical description can be used as a predictive tool to compare alternative designs for ease of use and to identify design choices which could cause users to make mistakes. The paper describes the human interface for two versions of an interactive graphics system intended for use by nonprogrammers. It presents the "action languages" for the two versions, then shows how these user languages can be described in terms of a production rule notation. Particular emphasis is given, in the notation, to actions the user has to learn and remember (i.e., to "cognitive" factors). The paper then presents predictions about human performance based on the formal description, and exploratory results of testing some of the predictions. Since the predictions are based on general properties of the formal description, the technique should also be applicable to other "action languages." Extract: Introduction Introduction In both linguistics and computer science, formal grammars are used to describe languages precisely. In linguistics, a grammar is used to describe the rules for generating sentences in a natural language. These rules are usually assumed to be the ones a native speaker of the language follows implicitly in creating and in understanding sentences. In computer science, a grammar is used to describe a programming language to a translator (e.g., compiler) or a compiler generator. The compiler can then be used to translate statements in the programming language into machine language. Formal grammatical description has not, however, been generally applied in the human factors area, which draws primarily on behavioral science for its methodology. Since human factors methodology rarely includes theoretical description or precise prediction based on formal models, the field is often considered "soft" or even ad hoc (at least, by some practitioners of other disciplines). In this paper we illustrate, by means of a detailed example, how formal description can be used as a tool to aid the design of systems for ease of use. We are specifically concerned with "action languages" for interactive systems -- the sequences of button presses, joystick motions, typing actions, etc. -- performed by a user interacting with a terminal. The intent of the paper is to show that an action language can be formally described and that the formal description can be used to compare alternative designs for simplicity and consistency. We are particularly concerned, in the formal description, with "cognitive" factors-what a user has to learn and remember -- rather than with physical actions themselves. By examining such a formal description rather than waiting for construction of a real, physical model, as required for behavioral testing, we hope to identify some design flaws early in the development cycle. The particular system studied, ROBART, is an experimental, interactive color graphics system for creating slides for technical presentations. It is intended to be used by people without computer training. Two comparable versions of the system exist (ROBART 1 and ROBART 2). The two versions have essentially the same function but differ in the the design of the human interface. The paper describes relevant portions of the two ROBART versions in some detail. It then presents a formal description of the ROBART 1 action language and makes predictions about human performance based on the formal description of ROBART 1 and matching parts of ROBART 2. Then, it presents results of exploratory tests of some of the predictions. The potential value of formal description of action languages is discussed, as well as other related work. Extract: Summary Summary The field of human factors is frequently judged to be lacking in rigor. To counteract this judgment, we have shown, by means of a concrete example, that 1) user actions at a terminal can be described by means of a formal grammatical notation, 2) the formalism can be used to make predictions for comparing design alternatives and locating design flaws, and 3) the predictions can be empirically tested. We have given a complete formal description of the ROBART 1 system and then made predictions on the basis of the formal description of ROBART 1 and matching portions of ROBART 2. We predicted that selecting shapes in ROBART 1 would vary in difficulty, that selecting shapes in ROBART 2 would not vary in difficulty, and that selecting any ROBART 2 shape would be easier than selecting the same shape in ROBART 1. These predictions were upheld in objective testing of immediate memory and in subjective questionnaires. We also predicted that users would make errors in attempting to initiate continuous shapes using ROBART 1 and would not make mistakes in ROBART 2. These predictions were also supported in testing. Formal description of interactive systems is an analytic tool. It makes possible the examination of a design from the human point of view early in the design cycle. We can thus compare some aspects of alternative designs and identify some design inconsistencies before a working model is built. The method we have presented is a general one. Other interactive systems (word processors, editors, etc.) can be described by means of a formal notation. The predictions we made were based on general properties of the formal description and the approach should therefore generalize. in IEEE Transactions on Software Engineering, March 1981 view details in IEEE Transactions on Software Engineering, March 1981 view details |