A Method for Program Design
IT, Høgskolen i Østfold
IT, Høgskolen i Østfold
We have incorporated a section on dialog, in addition to the screen design. Usually the two themes, Screen Design and Dialog, is covered by the concept User Interface in the literature. The reference section at the end of the article give some references [7] to sources that I find useful.
The reason for discussing the dialog as such is grounded in the approach which has been chosen in this article. We want to emphasise an holistic approach and we are interested in analysing the program as a whole consistent unit. This means that we are not satisfied with getting all the details in order in a "correct" way. Correct in this context is understood as based on psychological rules of thumb or standards. We want to try to grasp the holistic view of the program, even if we find both standards and rules of thumbs very useful. This holistic perspective is often lost in the work with getting all the details right. Much of the literature takes too lightly on this and refers to the need for consistency in the user interface.
Let us look at some of the basic premises for the dialog. The two parties, the program and the user, has quite different proficiencies for the conversation. We all know this is so, but we tend to forget it in design.
The program is deterministic. Once a situation and a stimulus is given, the reaction is predictable. The program is a state machine and the number of states are in principle predefined. The fact that the number of states may be vast and that the user in most cases cannot grasp them is another matter. The user is not, at least for practical implications, predictable. It is a common fault in design to oversee this important difference.
The designer predicts rational behaviour from the user, and neglect that the program should react meaningful on any input at any time. Programs based on dynamic simulation models are good examples: Usually the designers expectations to the user is balance a more or less complicated model. What the user does is, however, normally to test the performance of the program in extreme situations where the program normally reacts inadequate.
The capacities are different. There is significant differences in the two parties capacities in the communication. The program has a far grater repertoire for communication. It may use text, images, sounds, animation and all possible combinations. The user can in principle do nothing but type characters and point at one of a limited number of points on the screen.
The user has no use of her wide variety of communication means like gesture, body language, fluent language, etc in this particular type of conversation. Even if we may foresee a situation that this means of conversation could be registered by the program, we will still have a problem to interpret them as meaningful "state changing input" to the program.
The consequences of this is that the program should carry a large burden of the communication, by suggesting alternative user actions which are relevant at that particular point in the dialog.
The program knows the program.The user does not. The best we can hope for is that we are able to communicate a useful conceptual model that facilitates the users part of the dialog. The program knows the limitations and the possibilities and should carry the responsibility to present them.
The paradox. If we acknowledging these three differences we brings our self into a quite a paradox. We acknowledge that the program has the upper hand in this limited dialog situation, at the same time as we want the user to be in control.
If we consult the literature on User Interface design we find principles like:
User in Control
Directness
Consistency
Forgiveness
Feedback
Aesthetics
Simplicity
If we see rephrase these principles in a human-human dialog context, we may say that we want to talk to someone who lets us set the agenda, is speaking a straight and simple language, think it is nice to be touched, is trustworthy, forgiving and patient, answers all our questions and is pretty. Someone to spend an evening with.
Most of us have experienced many types of dialogs with computer programs. Some prototypes:
These programs are very helpful. They explain everything and usually suggests what you should do before you have had the chance to find out that you have a problem. They may even grab the mouse marker to show you how and where. There are usually one of two types of reasoning behind such programs: a detailed pedagogical plan or a desire to make a "waterproof" help system.
The pedagogical reason is probably misunderstood, and it does indeed take away the users feel of control. The user help is neglecting the fact that no one is a first time user more than once. The use of standard solutions in the interface should help us utilise experience from other programs, and each program should take advantage of this.
It is very annoying to be underestimated.
These programs may be really though. They do not have any patience and they don't hesitate to smack your hand. Messages like: " You are not authorised to do this !" pops up without further explanations. The alternatives, to mask the possibilities out or explain the situation is not part of these programs personality.
No one likes to be bullied.
They really don't care. Consistence and stability is not part of their vocabulary. The content of the window and the menus changes, the same menu text may mean different things in different contexts. The modes are very diffuse and you get no feedback. Sometimes you are warned in critical situations, sometimes not.
No one like to talk to someone who does not listen.
The program is reacting in a polite and meaningful way in all situations. It is consistent, stable and the metaphor is precise and intelligible. It follows the standards and we know what to expect. Help is available when we want it.
It is nice to have Jeeves around.
The psychology of role assignment in computer dialogs is often neglected in design. There are some interesting research that should make us focus more on this. The book "The Media Equation" [5], reports some experiments where users react with what we could call human-to-human reactions when using a program.
The classical example is Weizenbaums program Eliza [6]. Eliza is a dialog program that can converse forever about almost anything with very primitive means. The effect of Eliza is also rather astonishing when we consider the limited scope and variation of the conversation. Observations of users show that the users way of expression very fast adapted to the programs, and after a few exchanges of sentences it is almost impossible to tell the difference.
