DECISION SUPPORT SYSTEMS:DIALOG GENERATION AND MANAGEMENT SYSTEMS

DIALOG GENERATION AND MANAGEMENT SYSTEMS

In our efforts in this chapter, we envision a basic DSS structure of the form shown in Figure 12. This figure also shows many of the operational functions of the database management system (DBMS) and the model base management system (MBMS). The primary purpose of the dialog generation and management system (DGMS) is to enhance the propensity and ability of the system user to use and benefit from the DSS. There are doubtless few users of a DSS who use it because of necessity. Most uses of a DSS are optional, and the decision maker must have some motivation and desire to use a DSS or it will likely remain unused. DSS use can occur in a variety of ways. In all uses of a DGMS, it is the DGMS that the user interacts with. In an early seminal text, Bennett (1983) posed three questions to indicate this centrality:

1. What presentations is the user able to see at the DSS display terminal?

2. What must the user know about what is seen at the display terminal in order to use the DSS?

3. What can the DSS user do with the systems that will aid in accomplishing the intended purpose?

Bennett refers to these elements as the presentation language, the knowledge base, and the action language.

It is generally felt that there are three types of languages or modes of human communications: words, mathematics, and graphics. The presentation and action languages, and the knowledge base in general, many contain any or all of these three language types. The mix of these that is appropriate for any given DSS task will be a function of the task itself, the environment into which the task is embedded, and the nature of the experiential familiarity of the person performing the task with the task and with the environment. This is often called the contingency task structure. The DSS, when one is used, becomes a fourth ingredient, although it is really much more of a vehicle supporting effective use of words, mathematics, and graphics than it is a separate fourth ingredient.

Notions of DGMS design are relatively new, especially as a separately identified portion of the overall design effort. To be sure, user interface design is not at all new. However, the usual practice has been to assign the task of user interface design to the design engineers responsible for the entire system. In the past, user interfaces were not given special attention. They were merely viewed as another hardware and software component in the system. System designers were often not particularly familiar with, and perhaps not even especially interested in, the user-oriented design perspectives necessary to produce a successful interface design. As a result, many user interface designs have provided more what the designer wanted than what the user wanted and needed. Notions of dialog generation and dialog management extend far beyond interface issues, although the interface is a central concern in dialog generation and dialog management. A number of discussions of user inter- face issues are contained in Part IIIB of this Handbook.

Figure 14 illustrates an attribute tree for interface design based on the work of Smith and Mosier (1986). This attribute tree can be used, in conjunction with the evaluation methods of decision analysis, to evaluate the effectiveness of interface designs. There are other interface descriptions, some of which are less capable of instrumental measurement than these. On the basis of a thorough study of much of the human–computer interface and dialog design literature, Schneiderman (1987) has identified eight primary objectives, often called the ‘‘golden rules’’ for dialog design:

1. Strive for consistency of terminology, menus, prompts, commands, and help screens.

2. Enable frequent users to use shortcuts that take advantage of their experiential familiarity with the computer system.

3. Offer informative feedback for every operator action that is proportional to the significance of the action.

4. Design dialogs to yield closure such that the system user is aware that specific actions have been concluded and that planning for the next set of activities may now take place.

5. Offer simple error handling such that, to the extent possible, the user is unable to make a mistake. Even when mistakes are made, the user should not have to, for example, retype an entire command entry line. Instead, the user should be able to just edit the portion that is incorrect.

6. Permit easy reversal of action such that the user is able to interrupt and then cancel wrong commands rather than having to wait for them to be fully executed.

7. Support internal locus of control such that users are always the initiators of actions rather than the reactors to computer actions.

8. Reduce short-term memory load such that users are able to master the dialog activities that they perform in a comfortable and convenient manner.

Clearly, all of these will have specific interpretations in different DGMS environments and need to be sustained in and capable of extension for a variety of environments.

Human–computer interaction and associated interface design issues are of major contemporary importance, so it is not surprising that there have been a number of approaches to them. Some of these approaches are almost totally empirical. Some involve almost totally theoretical and formal models (Harrison and Thimbleby 1990). Others attempt approximate predictive models that are po- tentially useful for design purposes (Card et al. 1983). One word that has appeared often in these discussions is ‘‘consistency.’’ This is Schneiderman’s first golden rule of dialog design, and many other authors advocate it as well. A notable exception to this advocacy of consistency comes from Grudin (1989), who argues that issues associated with consistency should be placed in a very broad context. He defines three types of consistency:

1. Internal consistency: The physical and graphic layout of the computer system, including such characteristics as those associated with command naming and use and dialog forms, are con- sistent if these internal features of the interface are the same across applications.

2. External consistency: If an interface has unchanging use features when compared to another interface with which the user is familiar, it is said to be externally consistent.

3. Applications consistency: If the user interface uses metaphors or analogous representations of objects that correspond to those of the real-world application, then the interface may be said to correspond to experientially familiar features of the world and to be applications consistent.

Two of Grudin’s observations relevant to interface consistency are that ease of learning can conflict with ease of use, especially as experiential familiarity with the interface grows, and that consistency can work against both ease of use and learning. On the basis of some experiments illustrating these hypotheses, he establishes the three appropriate dimensions for consistency above.

A number of characteristics are desirable for user interfaces. Roberts and Moran (1982) identify the most important attributes of text editors as functionality of the editor, learning time required, time required to perform tasks, and errors committed. To this might be added the cost of evaluation. Harrison and Hix (1989) identify usability, completeness, extensibility, escapability, integration, lo- cality of definition, structured guidance, and direct manipulation as well in their more general study of user interfaces. They also note a number of tools useful for interface development, as does Lee (1990).

Ravden and Johnson (1989) evaluate usability of human computer interfaces. They identify nine top-level attributes: visual clarity, consistency, compatibility, informative feedback, explicitness, ap- propriate functionality, flexibility and control, error prevention and correction, and user guidance and support. They disaggregate each into a number of more measurable attributes. These attributes can be used as part of a standard multiple-attribute evaluation.

A goal in DGMS design is to define an abstract user interface that can be implemented on specific operating systems in different ways. The purpose of this is to allow for device independence such that, for example, switching from a command line interface to a mouse-driven pull-down-menu interface can be easily accomplished. Separating the application from the user interface should do much towards ensuring portability across operating systems and hardware platforms without modi- fying the MBMS and the DBMS, which together comprise the applications software portions of the DSS.