Menu-oriented Dialogue

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 83

What is a Good Dialogue?¶

What is a good user interface? I am currently leading a study at Skandinaviska Enskilda Banken, that aims at producing an “APL Dialogue Standard”. The study raises questions also penetrated in this paper.

• The ultimate goal of the study is of course to enhance user productivity.
• The suggested dialogue scheme should be so widely applicable that the user meets a similar behaviour in all APL systems.
• Many of the employees in my company have day-to-day experience with dialogues in the several transaction-driven applications. Most of these are available in an IMS/Cobol environment. One aim of the study is to see how APL dialogues can be made similar to IMS (and other) dialogues, at least not introducing differences where there is no real reason for them.
• Another aim is to see how, within reasonable limits, line-by-line command-oriented dialogue and menu-driven, 3270 fullscreen applications can be given similar features.
• How to design a certain dialogue depends very much on: user experience; nature of the task to be performed; and the user’s equipment. These will be studied in the next section.

User experience¶

The novice appreciates good advice from the system, and benefits from a helpful, explanatory, menu-driven dialogue. The experienced user gets tired of all helpful texts, and wants less control by the system. He can use a rich command language, and wants a facility to re-use command sequences that proved useful in previous work sessions.

Any system will always have novice users - everybody is when first using it. Many users never accumulate experience, since in their eyes the system is a minor tool, which lets them perform their task with less paper work. In my company we design most systems to suit the many infrequent users.

The novice in one system often has experience of other systems, and appreciates standardisation of dialogue between applications. And, since very many users are also users of the fullscreen, menu-oriented IMS applications, we often design APL applications in this style.

The real challenge is a flexible dialogue, where the user can take over more and more of the control from the system, as he learns more about it. But when we lack the time and money to meet that challenge, we prefer to start out with the more helpful menu-oriented approach.

Nature of the task to be performed¶

Some computer-supported work is of an exploratory, unpredictable nature, where a computer application has no possibility of guiding the user on an assumed track; e.g. a data analysis system, with elaborate tools for retrieval, selection, and presentation of data, calls for a flexible dialogue with freedom for the user.

But in very many applications, there is a logical route on which to proceed; when there is a choice the user can be given a clear listing of his options. A routine task, such as data entry for an accounting system, is clearly suited for a dialogue with data input on fullscreen panels, and a high level of flexibility unnecessarily limits this.

The user’s equipment.¶

With a slow typewriter terminal, the user does not want too much to be typed by the systems: He wants short explanations of menu options (or nothing at all); he does not want long print-outs just in case something interesting might be in them; and he wants to express his needs directly, instead of finding his way through a menu hierarchy. All this seems to suggest a command language to ease his work.

On the other hand, many users in this situation would probably most of all want to get other equipment, or faster communication lines. A command-oriented dialogue is often chosen, not really because the users’ experience or the nature of the task so implies, but simply because menus (and data entry on fullscreen panels) are impractical with the current equipment.

In real life, you have to build applications for the real situation. In my company, we have several users with typewriter terminals, and we write many applications so that they too can use them. However, in most of the cases these users are waiting to get 3270-like terminals, to benefit from menu-oriented dialogue. There are only a few cases where small, portable asynchronous terminals are chosen on their own merits - such as bringing the terminal along to a customer, or bringing it home to do work there.

What Does the Dialogue Look Like?¶

The dialogue style in an application depends on how certain features are designed:

How is data entry done?¶

When much data must be entered, a fullscreen panel is preferred. It prompts for all data related to one object within the application; or allows column-wise input for many objects at the same time. The simultaneous input of many items gives the user an overview; it lets him work faster; and it allows more intelligent data validation by the system.

On simple, asynchronous terminals such data entry is done via a sequence of prompts. A good dialogue will allow the experienced user to type-ahead answers to expected prompts, but the process is still tedious.

Command-oriented data entry can be preferred only when there is a commonly-used default for each item to be entered.

Example:

The Swedish tax return form has a large number of fields to fill in, and most of them are zero (at least for me). Here, it could be a good idea to let the user start with an “all zero” situation, and let him change data items by commands like

TAXRATE 31.17 ; BANKDEPOSIT 5000 ; etc.

But there are few examples that really call for this kind of parameter + value input. Users like to see what values are used, and a fullscreen panel with the defaults visible allows that.

How does the user express his intentions?¶

This might be what most distinguishes menu-driven from command-oriented dialogue. There is a sliding scale, of course, maybe something like:

• Selection by one integer 1,2,3,…, each representing one option. Or one character from a neutral set like A,B,C,…
• Selection by a short code (1-2 characters), where the code is an abbreviation of something that the user understands. G = Get data and P = Print data; or GC = Get customer record and GA = Get accounting record.
• Simple words to describe simple intentions: GET, PRINT, ERASE. These words (commands!) can be abbreviated.
• A simple command language, e.g. as verb + object, or data item + VALUE. Verbs, object names, etc., can be abbreviated.
• An elaborate command language, with many verbs, item names, values, all meshed into nested-parentheses.
• A very rich syntactic structure…maybe APL itself.
• (…there are a few steps more)
• And finally, natural language. When supported.

Many users prefer the simple-syntax input, since they have too little time to learn an extensive command language. But note that all of the above are syntactical ways of expressing intentions, ranging from the very simple to the very elaborate. In a later section I will discuss some examples of non-syntactical user input.

How are the options presented to the user?¶

A typical menu-oriented dialogue displays the options with a one-line text explaining each. More information is available by a Help facility.

With an experienced user it is sufficient (and with a slow typewriter terminal often necessary) to keep explanations short. A list of the options, or of command verbs, is appropriate. In the strict command-oriented dialogue, the options are not listed at all, but can be seen only when the user requests help.

It is said that a command language encourages a flexible use of the system, because of the free input form. But often a user learns only a certain set of commands to perform a specific task, from a colleague or otherwise. He does not exactly know why the commands look as they do; probably he dares not experiment with the given parameters. He has no immediate reason to inquire what other commands there are, and is left ignorant of most features in the application.

When all options are clearly presented to the user, in a well-structured menu hierarchy, he is more apt to get curious and try out new parts of the system - parts that were included because somebody thought them helpful in his work.

Which options are available?¶

Many applications are built so that in a given situation only certain options are available. This can be described as a hierarchy, in which successive choices are made. Typical menu-oriented systems have this organisation, as opposed to many command-oriented applications, with a “flat” hierarchy, permitting most commands in a main dialogue loop.

Now, as the user gains experience with a menu system, he will feel uncomfortable with the control implied by the hierarchy. In many such systems he will discover that the control is not there. Successful menu-oriented applications allow the user to take over more and more control, in various manners:

• Direct selection within the hierarchy: a user working within alternative 3.2 can enter something like “GOFAST 2.8”.
• A temporary excursion into one operation, after which the user returns to the previous situation. The help facility is an important, but maybe not typical example of this. An extreme case is when some applications allow the command “APL……”, where the ….. should be executed as an APL expression.
• Starting a parallel session, such as splitting the screen layout into two. At times, this is supported not by the application, but by the time-sharing system, or by the user’s terminal.
• Letting more options (commands) be available than those listed on the menu. The listing is the system’s best estimate of how to proceed; it is displayed for pedagogical reasons, and not because of the logic of the application.
• Allowing selection codes (commands) to include parameters, even if that is not stated on the menu display. Say the user normally enters GET (or G) to get data; he expects the system to prompt him for year and month. But the experienced user knows that he can at once enter GET 8312.

So there are several ways to let the user grow into a more flexible use of the system. I feel, however, that the right starting point is one where the user gets much information and help, where his inputs are simple, and where the dialogue guides him on a suitable track through the application.

Examples of Non-syntactical Input¶

How does the user express his intentions? In the typical menu selection situation, there is one more way: he can point into the menu! (Whether he uses a light pen, the cursor, or his finger is of less interest.) There are many situations where the user’s work is made easier if the dialogue can utilize the geometry of the screen instead of an intricate syntax. I would like to elaborate a bit on this theme, which I think fits in well with the helpful, menu-oriented dialogue style.

Example:

Consider text editing; and assume the user decides that a certain paragraph should be moved. Syntactically, this is expressed with something like

MOVE 135: 140 231

—with difficulties in remembering which are the “to” and “from” line numbers. An alternative is to let the user mark the paragraph to move (with characters in a special marker column), and similarly the destination. Here the user expresses what he means in a direct fashion, closely modelling the operation to be performed.

Note that the line numbers in this example are artificial — the text itself does not need them. They are added by the “syntactical” editor just to make the syntactical expression possible. In a non-syntactical editor they are not needed.

Another example with text editing is line split: A syntactic way to request it would include line number, plus some indication of where the split should be done. Very intricate! Instead, let the user point with the cursor to indicate where the split should be, and nothing can be simpler.

Example:

Assume a tool to do yield calculations on bonds (common in financial institutions). The user enters a set of base data for the bond in question, and a suggested price, to obtain the yield (which is his key factor). Alternatively, he can enter a stipulated yield to get the implied price; in fact he wants to go back and forth between these two modes of calculation. Well, let him do that on a fullscreen panel:

* * * * * * * * * * * * * * * * * * * * * * * * * * *
*                                                   *
* BASE DATA     ________________________________    *
* . . . . . .   ________________________________    *
* . . . . . .   __________________________________  *
*                                                   *
*       PRICE ________________  YIELD ___________   *
*                                                   *
* * * * * * * * * * * * * * * * * * * * * * * * * * *

In which direction should the calculation be performed? The user will not have to explicitly (syntactically) state the direction. Instead the application can use non-syntactic information that the user supplies — this time without even thinking about it. It can detect which of the fields PRICE and YIELD has been changed, or draw some conclusion from the position of the cursor, and take the correct action.

Consider also data entry on a fullscreen panel:

Example:

Assume that the command INDATA leads to the following panel:

* * * * * * * * * * * * * * * * * * * * * * * * * * *
*                                                   *
*                                                   *
* NAME          ______________________________      *
* ADDRESS       __________________________________  *
* AMOUNT        ________________________            *
*                                                   *
*                                                   *
* * * * * * * * * * * * * * * * * * * * * * * * * * *

If you prefer a syntactical model of this, you say that the panel lets the user type ahead three answers into the input buffer. Conversely, assume that before he sees the panel the user types:

INDATA;BJORN BORG;MONTE CARLO;9999999

With a syntactical description, you expect the system to look into the input buffer for name, address and amount. Most applications don’t; the panel is considered to reside outside the syntax of the dialogue. Instead, field inputs are assigned to data items depending on panel position. In the following section are discussed some implications of regarding the data entry as being non-syntactical (existing outside the input buffer).

So, the observation in this section is that not all user input can be regarded as syntactical (and thus possible to pre-type into an actual or imaginary input buffer). Successive menu choice can fit into a syntactical description, but when the dialogue utilizes the geometry of the screen, or a light pen, or colour, the input is clearly non-syntactical.

And the argument made is that these other kinds of input can give the user a higher productivity. Many operations are more easily described in other ways than with a syntax.

Rerunning the Dialogue — and Prerunning It.¶

One question about good dialogue design is: Good for whom? For the user, of course. But other people are interested, as well:

• The ultimate end user, waiting on the telephone while the terminal operator is struggling with the system.
• The programmer, overloaded with work, and strongly in favour of standard program utilities that ease his work, while they unify systems for the user.
• The production staff, concerned about CPU load and communication lines.
• The company auditors.

Maybe to your surprise, I have a few words about the auditors. Two of their (very legitimate) concerns are:

• They don’t want people to have freedom to do things that they are not allowed to do. However, a competent user can always try to do things in free APL, that a controlled dialogue won’t allow him. So this is not really an argument for a strictly controlled dialogue.
• They want to be able to get a transcript of terminal sessions, providing the opportunity to reconstruct critical operations.

It is obviously difficult to provide a transcript of a session with much non-syntactical input. “What did the user really do; where was the cursor positioned when he hit the Enter key?” And similarly, it can be impractical to provide a transcript when data entry is done on a fullscreen panel. The session log of a command-driven application is what the auditors need.

In fact, not only the auditor but also the user himself is interested in the transcript. With a menu-driven application, you find yourself asking questions like: “How did I produce this nice graph? Well, first in menu 6.1 I did this, and then…”. A related question is that a command language allows for easy introduction of command procedures, where the user can store away sequences of commands for later use. Very seldom, if ever, can fullscreen, menu-based systems utilize command procedures. Normally that is possible only if the application also supports a command-oriented dialogue.

So I admit that in these respects (auditing, the session log, and command procedures), the menu approach is weaker than a command language. This holds even stronger with a non-syntactical dialogue design.

Conclusion¶

I will not claim that a menu-oriented dialogue is the best choice in every case — I have myself discussed when its drawbacks get noticeable. Each application must be judged by itself; but in my company we often use a fullscreen, menu-based design for the following reasons:

• User productivity benefits from the more helpful menu dialogue design, mildly controlling the user’s route through the application. This is true especially for the many casual or infrequent users in the company.
• Most applications are of a rather uncomplicated nature, and users prefer simple inputs to describe simple operations.
• The users appreciate that APL and IMS application have a similar dialogue style.
• Data entry on fullscreen panels is superior to line-by-line input.
• Listing alternatives on an explicit menu encourages users to learn more about an application.
• The menu-oriented approach is preferred as a starting point. Ambitious applications can arrange the dialogue to let the user gradually assume control.

Everybody agrees on the advantages of graphical, diagrammatic output. I have pointed out that also for user input, it is valuable to use the geometry of the screen, and not always rely on a syntactical mode of expression. This does not necessarily imply very sophisticated terminal equipment; much can be done with good screen layouts, using only character input and the cursor’s position. These non-syntactical input schemes are a natural extension to the menu-oriented approach.

Gösta Olavi, Senior Systems Analyst, Dept. for Marketing & EDP, S.E. Banken, Stockholm, Sweden.