A Method for Program Design
IT, Høgskolen i Østfold
IT, Høgskolen i Østfold
The method is described as a series of steps. These steps are shortly outlined below. It is obvious that these steps cannot be a one-way stride towards the final product. The process must be iterated and any experienced designer will know that the available techniques must be seen as a set of tools that should be used as needed, in a sequence that is useful for the project or problem at hand.
I could have started out with "The Assignment" in stead of "The Idea". This would probably be a more accurate description of the situation in most projects. I have deliberately chosen to stress that a fruitful design process should have an underlying idea. The idea should feel good and it should give you some assurance that this is possible, and that the result may become really good. The idea may also be the inspiration for a very important concept: the name of the project. This gives identity to your work, and it is my experience that a catchy name really helps inspiration and communication.
Thoughts and sketches that describes the idea are important design documents. Usually the idea comprises some preliminary rationale and motivation for the project.
A proper formulation of the objective should answer the following questions:
This has two purposes. It is partly a basis for deciding if this is a project which is worth the effort, and it is partly a necessary foundation for a lot of decisions later in the project.
Any subject may be communicated in many different ways. An important part of the creative efforts in design is to find and work through at least three different perspectives to an idea. The chosen perspective is the foundation of a metaphor.
The selection of the metaphor is probably the one most important decision in a design. It has consequences on terminology, functionality and graphical design. The metaphor should support the users cognitive model of the program, an it is the metaphor that makes a program a consistent unit. The metaphor should support motivation and communication.
The first attempt to get a grip of the programs functionality is done by describing a scenario. We try to write down the things that will happen in a typical session with the program. This description is used to extract the verbs and to go on with the next two techniques, the Activity Table and the Market.
A scenario will never be complete and cover all possible combinations of actions, but it should pick up typical work sequences.
The scenario is the foundation for distributing the responsibility for different actions between the main roles involved in using the program. The roles are dependent of the type of program. For pedagogical software the typical roles are the student, the computer and the teacher.
The market diagram is a graphical description of the functionality. The scenario gives us a textual, free form description, the activity table helps us to sort things out, while the market gives us a map to work with.
This map gives us the opportunity to discuss the connection between activities and pedagogy.
As the metaphor, market place, indicates, we do also introduce a basket in the market. We use this to symbolise the accumulative aspects of the users work, or learning.
The screen, or the program window, is the place where we will realise our idea, with the learning objectives, the metaphor and the functionality. We must choose a presentation and an architecture that match our aspirations. It is a good idea to postpone the sketching of square window drawings until we have worked through the phases above in a free form.
The program window, or windows, is the place for communication between the program and the user, the user interface. A lot of static and dynamic elements must find their form. It s a good idea to look close at the established, or recommended, standards in this phase of the work.
It is also necessary to give some consideration to the overall role of the program as a part of a dialog.
"The devil is in the details." Since we want to have a broad participation in the design process, we must also offer a tool for analysing the details in the program. The available tool is state diagrams.
Most details are solved by choosing standard solutions, but there will almost always be some special situations that must be resolved.
