A Method for Program Design
IT, Høgskolen i Østfold
IT, Høgskolen i Østfold
In this phase the design may take unexpected directions. It is a good investment to put a considerable amount of effort into the choice of metaphor. The metaphor is the setting where we want to place the user. The metaphor is in many ways the personality of the program. A good metaphor is essential to both the user interface in traditional sense, as well as to the work to be done and the learning to take place.
The concept metaphor is used widely, in different contexts. Many are familiar with the biblical metaphors, which are used to communicate complex moral and ethical issues. Poets use metaphors, filmmakers use them and they are a part our daily language.
Within the field of program design the use of metaphors is established as an important issue for many reasons.
Some designers focus on the metaphor as a rather shallow illustration that mainly serves to explain the functionality of buttons, messages and menus. The design of the metaphor is in this understanding mainly a question of designing buttons and texts.
Navigation may mean at least two things: navigation in functionality (where is the button that turns of automatic spell checking?) and navigation in data structures (where is the comments I wrote yesterday ?). The use of the Internet has set focus on the latter, and has raised a lot of interesting questions regarding consistency in metaphors.
A good metaphor contributes beyond communication and navigation. It should support a cognitive model of the program. We should know what to expect and we should be able to foresee the consequences of a series of actions. It is important to design the metaphor such that it rewards understanding. The users efficiency increases as you gain experience with the program.
In a pedagogical perspective we do also want the metaphor to support learning. The metaphor should support the cognitive process that involves learning, and it should be adapted to the cognitive level we have stated in the objective. A phrase like "The user should understand..." is much more demanding than "The user should get an overview...". This difference must be reflected in the metaphor.
You may have different approaches to motivation. In a general sense the program should sell itself. The argument can be rational (it is effective and saves time) or it could be irrational (it looks nice). The first takes some explanation, or experience, while the latter is based on first impression. In a pedagogical perspective there is a parallel reasoning. On one hand the program can be designed to be part of a pedagogical plan and work effectively within that plan. On the other hand it may be designed to be self motivating and function without planning or a special context. The latter approach is of course the difficult one.
Place
Role
Time
When we start out with an idea, preferably a drawable idea, we do usually have a rough metaphor in mind. It may be incomplete, it may be unconscious and it may turn out to be a dead end for a lot of practical and conceptual reasons. It is important to investigate other approaches, other metaphors.
It is good rule of thumb to come up with at least three different perspectives. Changing perspective is generally a rather difficult mental process and we need some tools for thinking that can support this process. One way to do it is to work systematically with place, time and role. Make up a perspective from descriptions of these three key concepts.
When we read a novel we are mentally carried away to another place. The author wants to do this to us to prepare us mentally for the plot or the narrative. We must consider where we want to place the users of our program.
The options are usually plentiful if we take the trouble to look for them. In a program about cultivating of fish we may choose to be at the pond (seeing the fish) or we may be in the managers office (seeing the balance sheets and the plans). These approaches gives two quite different programs, even if the objective may be the same.
All the programs that I know of have all made decisions about place, deliberate or not. Word processors take their metaphors from "in front of a typewriter", while layout programs puts us in front of the "light board" where we can paste up pieces of text or images. Even if the functionality is getting more equal for each new version of the two program types, the basic concept, the place, is different. An intriguing issue is that both the typewriter and the light board is getting less and less known for most of the potential users; the frame of reference disappears.
The same way that we can look for different places, we can look for different roles. We can look for roles independent of the places we discussed above. In the end the role must of course match the place, but we are know looking for effective approaches to stimulate our creative efforts for alternative perspectives, and finally a good metaphor.
In a program dealing with traffic rules we may be the driver of a car, a police, a pedestrian, or a student in the teachers classroom. These perspectives will probably lead to fundamentally different programs.
We may also analyse the role in a more direct way. We may look into different role models for the user towards the program. This is a concept that are often overseen. We may as well put the student in the role of a teacher as in the role of a student.
Time is an important and difficult issue in many aspects of program design. We may discuss time as part of the user interface design and we may discuss time as part of the metaphor.
The use of time in a model may be rather complex and difficult to grasp. We may think of an ecological simulation as a case. Are we moving faster than real time, slower or do we make leaps in time. How should the user affect the time ? Can we use retrospective techniques, playback or simulate ahead to illustrate consequences of decisions ? Usually the problem is not time as inherent part of the model, but the users understanding of time and orientation in time.
A rather straight definition of time may be in place: Frank, a character in the film "Late for dinner", after having been frozen for 30 years: "Time is something we have to prevent all things from happening simultaneously".
Often the search for a metaphor may seem like an unnecessary effort or some kind of conceptual overkill. You will hear designers claim that " this stuff is self explaining and the program will do fine without a metaphor" or " this is a serious program and a metaphor will just make it look childish".
It is important to note that all programs is based on a metaphor of some kind. The choice may be deliberate or not.
A drill or test program that invites the user to answer by choosing from multiple choices, is based in a teacher - student metaphor with all the consequences that may have. The designer may not have considered alternatives.
The programs that we know as successful programs all have a deliberate metaphor that is instrumental for their success. It is interesting to look at a few typical samples that we all know in one form or another.
Very few programs have had an immediate success like Visicalc, the first (?) commercial spreadsheet program. The concept of evaluating a set of equations is as old as the computer, but the idea of placing variables, constants and functions in a table made the application understandable and usable. The concept of a table for organising made the difference, and we all have a conceptual model of spread-sheet programs as a table.
MacPaint from Apple introduced an interesting metaphor, which we may call the painters metaphor. The idea of the canvas and the available tools was almost intuitively understandable. Two tools was a little hard for new users. The hand that should position the canvas within our view port, and the lasso. The latter is a intriguing element i the metaphor, and most users had problems grasping it. The fact that it is a reflection of a useful concept (regions) in the graphical toolbox did not help most users. This anomaly was accepted because the rest of the metaphor was consistent and communicating.
The desktop is interesting in many ways. The most interesting thing is the gradual transition from an attempt to mimic a physical desktop towards a concept which defines its own attributes. The desktop has i many ways taken the route that many metaphors in the language does; from an explicit analogy to a part of the language. When the Internet gets incorporated in the desktop in a seamless way this transition will be even more clear.
The metaphor has, and should have, what we can call a naive physics. It should be evident what we can do and what we cannot do. The metaphor should match our earlier experiences and we should be able to act without any further explanation. When we see a dice on the screen it is obvious that we should be able to roll it. If we see a card it is obvious that we should be able to turn it or move it. If we can not, we are puzzled and we loose faith in the metaphor, the model and the program.
Design is an iterative process and it should contain phases of expansion and phases of reduction. When we deliberately stress the tools for supporting creativity without limits, we must accept the cost of having a set of rather colourful ideas, metaphors and thoughts. The good thing is that we have something to choose from.
The metaphor we choose will be subject to modifications, and most of all reductions. Typically we will start out with a metaphor that is rather colourful and detailed and which has associated to it a lot of images in the back of our head and hopefully on paper. Only part of this is ultimately suited for presentation on a screen, and we must be prepared to reduce the metaphor down to the essentials in later stages of the design. Someone has once said that a design is not perfect when there is nothing more to add, but when there is nothing more to take away.
