ON THE USE OF TRANSITION DIAGRAMS IN THE ... - CiteSeerX

ON THE USE OF TRANSITION DIAGRAMS IN THE DESIGN OF A USER INTERFACE FOR AN INTERACTIVE COMPUTER SYSTEM* David L. Parnas Carnegle-Mellon University Pittsburgh, Pennsylvania

not needed in the design of a single language system.

Abstract This paper deals with what might be called the top level design of an interactive computer system. It examines some problems which arise in trying to specify what the user interface of such a system should be. It proposes a concept--the terminal state--and a notatlon--the terminal state transition diagram--which make the design of the top level somewhat easier. It also proposes a user interface in which the notion of terminal state is explicit. This user interface seems to provide a great improvement in flexibility and ease of adding sybsystems to a general purpose system.

Current Developments Concernin~ the User Interface

The main explicit focus in user interface design has been the command language. The development of the command language aspects of the user interface are an interesting topic in themselves. Originally the commands (for the most part these are simply commonly used programs) were not thought of as part of a language, simply as a set of separate but useful programs which were easily available to the user of the system. In response to a growing user need the command system grew by the addition of commands, each program separately written and usually differing in formats and conventions from other commands. The confusion which resulted from such inconsistency motivated the development of command languages in which a specific syntax and set of other conventions was dictated for all commands. At this time, too, demand was made for certain features which would allow the expression of complex commands built up in regular ways from the basic commands. Macros, iteration statements, etc. now appear in command languages. This development should appear quite familiar for it is simply a recognition that the user requires a general purpose programming language for use in expressing his requests to the system. The response to this fact has been the statement by many that a command language should include all the features which have been proposed for programming languages. These include lists as parameters, function procedures, etc.

Introduction This paper is concerned with the design of the user interface for a general purpose interactive system. By user interface we mean the aspects of the system behavior that a user sees. Several papers ],2,3 have argued that the proper procedure for computer system design involves going "top-down" or "outside-inwards"--in other words, designing the user interface first. The point of those papers has been that interfaces should be an explicit article of attention for designers not an implication of the implementation decisions which are made. In this paper we wish to discuss problems which arise in designing the top level. In particular we wish to suggest a concept--the terminal state--and a notation--the terminal state transition diagram--which can be of great use to the designers of a user interface for an interactive system. Further, we shall explore an approach to interface design which is suggested by these representations.

This paper is intended to point out another aspect of user interfaces which we feel is not dealt with by the above developments. The need for this view of the user interface is a direct result of the interactive nature of the system; interaction has not, to date, been a major consideration in the design of general purpose prograrmming languages.

General Purpose Systems It is important to note that we are concerned with the design of general purpose systems rather than systems dedicatad to a fixed set of languages. The design problem here is a bit more difficult simply because the designer cannot predict the ways in which his system will be used. If the system is successful, there will be those who write subsystems which are used in ways which differ substantially from the usage of the main system or other subsystems. The designer of the general purpose system must maintain in his design a certain generality and open-endedness which is

Terminal States The aspect of a user interface which shall concern us is called the "terminal state transition diagram". We think of a user as using a terminal of some sort that is connected to the system. At any point in time that terminal is in some specific terminal state which is characterized by the set of possible input messages and their interpretations. In any state there will usually be a large number of input messages which a user may type. A large number of these messages will be rejected by the system as meaningless (null interpretation). The remainder

This work was supported by the Advanced Research Projects Agency of the Office of the Secretary of Defense (F 44620-67-C-0058) and is monitored by the Air Force Office of Scientific Research. This document has been approved for public release and sale; its distribution is unlimited.

379

explicit

will be interpreted by the system in some way (e.g., as a call on a program, a value of a parameter, etc.). We shall include in a terminal state all system conditions (relative to a given user) in which the set of interpreted messages, and the ~et of interpretations is constant.

Example

The reader must not think here that we are using state in a slightly different sense than is used in the discussion of finite state automata. There a state is characterized by the set of input messages and their responses. We are allowing the responses to vary within a single terminal state. This is necessitated by the complexity of the systems with which we are dealing. Were we to insist that a state have a consistent response to a given input (e.g., a query about the amount of file space available), the number of states would be so large as to make analysis of the system impossible for all practical purposes. Luckily the representation which we can handle is adequate for our purposes. Terminal

State Transition

Diasrams

As a user interacts with the system, the state of his terminal changes. The changes that are made are predictable (barring errors in the system) and can be represented graphically by a state transition diagram which is entirely analogous to the state transition diagram used in describing finite state machines 6. The state transition diagram is a graph with a node for each terminal state. At each node there is an arc for each possible input stream (or set of input streams with identical interpretations). The arc starts at the node representing the state being described and ends at the node representing the state that the terminal will be in after receiving the input message and giving the response. The input message and the response are ~escribed along the arc in the form: 'input message description'/'output message description'. It will become apparent from the examples which follow that the user of a system must become aware of the terminal states and the terminal state transition diagram very early in his usage of the system. If he is not aware of what state his terminal is in, and what interpretation his messages will have in that state, the system (however mnemonic the commands) becomes very difficult to use. If explicit attention is paid to the terminal state diagram, and the user is given an explicit description of it, the system can become a pleasure to use. Examples

of Terminal

attention

States

In this section we shall attempt to make the meaning of the foregoing discussion more concrete by means of a few examples of terminal states which might occur in an interactive computer system. These shall illustrate the way that the terminal states occur and are useful in such systems, and will also serve to illustrate some of the errors which can be made if the designer does not pay

380

]:

to the terminal

state diagram.

The Initial State

Figure ] shows a part of a terminal state diagram which includes the node representing the terminal state which occurs after connection is first made with the system and before any input messages are sent by the user. In this state there are usually only a few messages which have a non-null interpretation. These messages include logon messages (messages in which the user identifies himself in some way to the system and indicates the nature of his usage) and (optionally) some messages in which the user requests information about the system in order to decide whether to logon or not. In our example the user can ask if there are any messages stored in the system for all users (broadcast news) and also he can ask for some description of the load on the system. Many other possible requests might be included at this state, but they would serve no purpose in our example. In the example we also show the possibility of two distinct logon messages which lead to two distinct states according to the type of usage. Clearly there could be no more. Example

2:

A Fortran

State

Figure 2 illustrates a part of the terminal state diagram which appears in systems which have an incremental FORTRAN compiler. The user gets his terminal into this state by a sequence of input messages which inform the system that he wishes to write a FORTRAN program and have the program checked as he writes it. Our partial diagram shows the arcs corresponding to a correct statement (other than "END"), a "DO" statement with missing interation variable, and an otherwise valid statement with an invalid statement number. State SO represents the state in which whole statements are a valid input. S] is a state in which the only message with a non-null interpretation is an integer. If the integer is a permissible statement number it is taken as a replacement for the invalid number on the previous statement. In all other cases the user returns to S]. In $2 the user is expected to supply an integer variable to be used as the iteration variable missing from the previous incorrect DO statement. $3 is the state in which the user can request an action to be taken with the just completed FORTRAN program. Again, this diagram is incomplete; the complexity of an actual diagram will increase with the amount of effort that is put into error diagnosis by the compiler. It is worth noting that were we counting states in the sense of automata theorist (complete states) there would be a vast number of states just in what we have called the FORTRAN state. The set of permissible statements, legitimate statement numbers, etc. changes with each line input making a set of complete s t a t ~ w h i c h is, for all practical purposes, infinite.

Example 3:

Prom~ting

States

a r e distinct states because two of the input messages have different interpretations. Situations generally cause considerable difficulties for a user who must (I) be aware that there are several states, (2) learn the conditions under which each of the several states is reached, (3) remember the differences between the states as well as which input message is appropriate in which state, (4) occasionally respond in two distinct ways to apparently identical series of stimuli. As an example, consider a system which has provisions for easy modifications of files. At first glance there appears to be one state in which the system types a '#' and accepts a llne number followed by a comma, followed by a line of text. Facilities are available for displaying parts of files, asking for confirmation messages, etc. In using the system, however, one suddenly becomes painfully aware that there are at least two distinct states which fit this description. The input stream which signals end of modification in one state is rejected as an erroneous input in the other. Not only does this cause difficulties for the user, but it suggests that the system writers have duplicated quite a bit of effort (actually almost duplicated) unnecessarily.

When a user calls upon a program which requires a long string of parameters, there is no need for him to remember the information which is required in his case, the order in which the parameters are to be supplied, and the formats or keywords to be used in supplying the values. The system can be set up so as to prompt him. The prompting may be done for any user or only for a user who calls the program without specifying all the parameters. The state transition diagram which results from this attempt to help the user may look something like Figure 3. In Figure 3 S] is the state in which the system will accept the name of the program that the user is calling. If he supplies the program name but no parameter values, the system supplies a message asking for one parameter and puts the terminal in state $2 in which a valid value for that parameter may be supplied. If an invalid parameter is supplied, an error message is given and the terminal is left in state $2. In the case illustrated some values of the first parameter may imply that values of a second parameter will not be needed. The diagram shows a transition to either S3 or S4,depending on the value of the first parameter. Needless to say, the prompting messages will differ as well. In some cases a system will allow a user to supply values for more than one parameter after being prompted for one. In those cases the diagram will be considerably more complex than that shown. Design Errors

Illustrated

in State Diagrams

In this section we shall exhibit some examples of the types of difficulty which occur in a user interface when it is designed without explicit attention to the terminal state diagram. These user difficulties are rarely insurmountable obstacles for the user. Usually he sees them as a rather annoying set of "gliches" which make the system more difficult to use than it should be. As a result of these "gliches" a user will spend an undue amount of time referring to his manuals, retype information to the system more often than he should have to, and in some cases make an undue number of errors in the system. Very occasionally they will result in a user having to start his interaction in the system over again--sometimes he needs to hang up and dial again. (Errors of this seriousness are rare, mostly because they are top priority fixes when a system is first tested.)*

2. Inconsistent ways of reaching a single state. In the course of a session with a system the user may suddenly wish to reach a specific state. He may or may not wish to return to the state he was in at a later time. For example, he may wish to return to a state in which he can inform the system that he wants a certain class of messages suppressed or enabled if it is now suppressed. In some cases he can reach this state simply by pressing a single button. In other cases (still on the same system) he must press that button three times. In still other cases he will have to give a sequence of specific commands to the system in order to get to the desired state. If he wishes to be able to return to the present point in his computation, he may not be able to make the change at all. In the prompting and error correction examples shown earlier the diagrams include states in which there is no simple transition back to this state. Generally each system has a "break" or other escape mechanism, but the interpretation of that symbol is not consistent from state to state, In many states the use of the "break" will make it impossible for a user to return to that state without retyping much of what he has already typed. 3. Terminal or almost terminal submachines. The literature on finite automata defines a terminal submachine as a set of states which, once entered, cannot be exited. Systems that I have looked at have had two sorts of difficulties in this regard. First,there have been states which it may be impossible to leave by other than the general escape mechanism described earlier. Second, when a subsystem writer wishes to produce a terminal submachine in the user interface, he finds it unnecessarily difficult. We shall have more to say on the second difficulty later. An example of a terminal submachine would be an error correcting state in some file manipulation

I. Almost alike states. It is quite common to find that a system has a number of distinct terminal states which are very similar. By this I mean that in those states the majority of the input messages have the same interpretation. They It would be tempting here to give specific illustrations of difficulties on a specific real system. To do so, however, would generate more heat than light. The problems illustrated in this section are(sometimes thinly) disguised examples of problems which have been experienced by the author.

381

command. The system informs the user that the file name he has used is not associated with a defined file and that he must supply the name of a defined file. The user has either forgotten to define his file or assumed that the system would do it for him when he first used the name. In any event he has no appropriate file name that he can use. Any name or message that he gives to the system is rejected as not being the name of an appropriate file and he has no way out of the state. Similar situations can arise in a user written program which uses formatted input. I have seen one system in which a user attempting to get out of a loop, hit a "break" repeatedly only to get the message, "is not in proper format". He was forced to disconnect from the system. 4. Inability to correct errors in lon~ strings of parameters. In the example of prompting states one can find no way after inputting the fifth parameter to return and change the third parameter. This can on occasion be quite annoying and cause a great deal of duplicate work for the user. ~onclusions

to be Drawn

from the Above Examples

It is very easy to dismiss the above and many other errors as the type of errors that always occur in system designs. They are especially typical of system designs that involve a large number of people. By taking this view one can say that they are not illustrative of any particular methodological error. In fact, however, there is a very strong conclusion that can be reached. The above errors would not have been made if the designers of the system had explicitly designed and documented the terminal state diagram at an early sta~e in the system design. These particular errors are too obvious (when viewing a state transition diagram of the system) to be overlooked.

with h i m some new data for use in continuing his old task. He does not wish to be subjected to any particular discipline (e.g., last suspended-first resumed) in resuming a suspended task. If his suspended task has a data base, he would like to be able to have access to that data base in a simple way while working on some other task. He would like similar facilities for working and interacting with tasks which he has allowed to proceed in a non-interactive manner. 3. The user interface should be ample for users who are building subsystems which will be used by others who may be completely unable to use the basic system. The MULTICS design4,5 shows a great deal of thought about accommodating subsystem writers by allowing restricted access and changes to parts of the supervisor. However, there will always be (and should always be provisions for) persons who wish to create subsystems, but who wish to do so entirely at the user level--knowing nothing of the structure of the supervisor that does not show at the user interface. Among other things this implies that the user at the FORTRAN or ALGOL level must be able to insulate the user of his programs from system messages which would be meaningful to a programmer but not to the user of those programs. In many ways this class of users is likely, in the long run, to be the most important class of users to be provided for in our design. The long term usefulness of a system depends on its flexibility and the ease with which it expands by the addition of subsystems. Applications

of Terminal

State Transition

Diagrams

There are a number of ways in which the concept of terminal state and the terminal state transition diagram can be used to ease and improve the design of user interfaces. Some of the more obvious are: ]. Designers can profit by doing their original design in the design space of state transition diagrams. Many otherwise hard to find errors become quite easy to find in this space and many improvements which might never be found are easily seen in this notation. If the designer is not comfortable working in this space he can draw the transition diagram of a design, produced in some other design space, as a means of gaining these advantages.

User Needs Before proceeding further I would like to list some of the demands which the user of a general purpose interactive system makes on the designer of the user interface. I. The user needs a simple state diagram free from transitions which are both useful and impossible. Notational conventions should (with certain exceptions) be uniform throughout.

2. Where the system is being built by a relatively large group the state transition diagram can be a useful means of passing certain aspects of a specification to the subgroups. This is a more concise, less ambiguous form of specification than the English language currently used. The group can either be given a terminal state diagram for their part of the system, or, if the design has not progressed that far yet, can be given a set of state transition conventions to which the diagram of their product must adhere.

2. The user interface must make it simple for the user to use the system in the manner of a desk tool. Many current user interfaces seem to be designed with the implicit assumption that the terminal will be used in the same way that the console of an open shop batch processor would be used--the user is expected to work on a single task in a predictable way until he can go no further with that task. In fact, the user of a desk tool expects to be interrupted at one task and to be able to switch to another with little effort. He expects to be able to stop on one task and return to it later, perhaps bringing

3.

382

The state

transition

diagrams

can become

a significant part of the system's documentation. Often the initial diagram drawn by the designer can become a part of the user documentation since it is a compact complete and easy to read description of the system from the user's point of view.

terminal state. When the system makes a transition it must have sufficient information to move to an exact state not Just a terminal state.) Suspensions may be denied because they involve an excess use of storage resources.

4. There exist algorithms for processing state transition diagrams for the purposes of eliminating identical states, detection of terminal submachines, etc. Slight modifications of these would detect almost alike states, almost terminal submaehines, and violations of established transition conventions. Although it would be preferable if the diagrams remained simple enough that such automation was not useful, it is comforting to know that there already has been considerable research on these topics.

In such a system we would not include in the command language all the features of a programming language. Rather, we would include in at least one c o m m o n l y u s e d programming language the features of a command language. In other words, we would give the programming language the ability to call for state transitions, suspensions, as well as the classical abilities of a command language, access to the file system,etc. Included in the library associated with this programming language would be the usual programs which have been called commands. However, the user would be able to write programs in his file programming language which would produce arbitrarily complex commands which could then be called just as any program in the library. By means of suspension these complex commands can be written as needed without losing one's state in the task for which the command is being composed.

5. Although our primary interest in this paper is in the use of these diagrams for designing the top level there are certain implementation techniques suggested by past uses of state diagrams some examples of which are given in 6'7. These range from using the diagrams as data for a table driven command interpreter to encoding the logic implied by the diagrams in boolean equations or even in hardware.

Users who write "commands" or subsystems should be able to define terminal states to the system so that users of the subsystems could use the standard notations for suspension and transition making use of the facilities already built into the system. Subsystem writers should be able to provide a state transition diagram which establishes local conventions (which might override the outside conventions) and indicates permissible transitions and library calls. If the diagram includes in its possible inputs messages from the main system, the subsystem writer could completely isolate his user from unwanted messages--without knowing the internal structure of the system.

An application which appears less obv%ous is supplied by a study of the state diagrams of existing systems. In these diagrams there appear to be three types of inputs provided by the user:

I. 2. 3.

Calls on programs in some library; Requests for a change of terminal state; Data for a program which has been called.

The first two types of inputs are usually classed as "commands" but they actually represent quite different items. It is intriguing to consider a user interface in which the concept of terminal state is explicit in the interface. In such a system the only commands would be requests for a change in terminal state. Every state in the system would be identified by a label. The user would be able to:

1. 2.

3.

Conclusions The intent of this paper has been to convince the reader of the importance of designing a user interface early in the design and representing it explicitly. We further hope to have convinced readers that the state transition diagram is as useful a tool in designing the user interface as it has been in designing other parts of computer systems. We have also suggested the possibilities of an interface in which the state transition diagram is explicit rather than implicit.

Request a transition to a given state by using its label; Call for a saving of his complete state, associating it with a label; the label can be used to return his terminal to that complete state. The label also serves as an identifier by which the user or his program may refer to the data associated with his suspended task; Call programs

Certainly the use of the state transition diagram does not aid at all in many aspects of user interface design. We have not even mentioned the appearance of the file system to the user, the primitives for operating on files, etc. We have not come anywhere near the difficult problem of dealing with the numerical aspects of user interfaces and many other human engineering problems. We only hope these suggestions aid in dealing with one aspect of interface design. We look forward to seeing discussions of the other aspects of "top level design" in future papers.

from a library.

For a number of reasons certain transitions and certain suspensions would have to be denied. Transitions might be denied because of either lack of appropriate privilege or lack of sufficient information for the system to make a transition. (The possibility of lack of sufficient information is a direct consequence of our including a large number of complete states in a single

383

References I.

Zureher, F. W. and Randell, B.~ "Multi-Level Modeling - A Methodology for Computer System Design," Proceedings of the 1968 IFIP Conference.

2.

Parnas, D. L., and Darringer, J. A., "SODAS and a Methodology for System Design", Proceedinss of the 1967 FJCC.

3.

Parnas, Do L., '~ore on Simulation Languages and Design Methodology for Computer Systems," Proceedings of the 1969 SJCC (to be published).

4.

Corbato, F. J., and Vyssotsky, V. A., "Introduction and Overview of the MULTICS System," Proceedings of the 1965 FJCC.

5.

Graham, R. M., "Protection in an Information Processing Utility," CACM, May ]968.

6.

Bartee, et al., "Theory and Design of Digital Machines," McGraw-Hill.

7.

Heistand, R. E., "An Executive System Implemented as a Finite State Machine," CACM 7, pp. 669-677, November ]964.

384

FIGURE

1:

PARTIAL PICTURE OF A N INITIAL T E R M I N A L STATE

(•)•

'END'/'NOW WHAT?'

Ps

FIGURE 2: P A R T I A L PICTURE OF A F O R T R A N STATE

0

~

0

f PrOgrorn,~ ,

FIGURE 3 : P A R T I A L I L L U S T R A T I O N OF STATE T R A N S I T I O N D I A G R A M F O R PROMPTING

385

f

I