A Method for Program Design
IT, Høgskolen i Østfold
IT, Høgskolen i Østfold
Program design
>A Sample
A very simple program may serve as an illustration of the design process. The program "Sant" is a simple program for training aritmetic skills. Sant means "True" in Norwegian. A demo version of the program can be downloaded.
The key design documents and most of the considerations during design process are documented below.
The idea behind Sant is Norwegian license plates as they were
some years ago, with up to 6 digits. A pastime during long car
trips and waiting for the bus was to figure out an equation that
use all the digits. Surprisingly many 6-digit number may be "solved"
this way.
7 - 6 + 5 = 4 + 3 - 1
It is easy to see that this exercise is a training in the 4 basic arithmetic skills, and that it lays the ground for understanding equations. The idea gives us the possibility to vary the level of difficulty; we can introduce parentheses and we can vary the number of digits.
After some iterations the users was described like this:
The final formulation ended up as:
The program should :
A computer program is well fitted for this task for many reasons:
The program is mainly designed for individual use, and will not be dependent of a special pedagogical plan or external motivation. This does not eliminate the possibility to plan the use in a pedagogical context.
The discussion about perspectives were mainly focused on the use of time. Two of the perspectives that were discussed in some detail are described below:
Place. The original idea was connected to cars licence plates. This perspective may easily be developed to a traffic situation with cars passing.
Role. The role as passenger is possible, or we may come up with something more exciting. Maybe a police officer with the assignment to check the drivers identities or to check if the cars are stolen.
Time can easily be integrated in this perspective. The cars may be visible for a short time before they disappear around the corner or into the darkness.
This leads us into a traffic metaphor, which probably could be worked out into a design.
Place. An other device with useful numbers are telephones. We could develop the idea of a room or situation where phone numbers had to be solved as a mean of dialling.
Role. Who would be dialling and for what reasons ?. There are lots of possible answers to this. We could take the dramatic turn and introduce some kind of spy or some role who should collect information.
Time could be integrated as a stress factor: "you must get this information within a certain time or else..."
This telephone metaphor could not doubt be developed in a more or less exciting way.
There are a lot of considerations to take into account when the metaphor is chosen. One of the most important is the objective. The two alternatives above may both have interesting and in some respect promising sides, but they may narrow down the user group. We should look for an approach which is less dramatic.
The metaphor that was chosen in the end was a betting metaphor, with cards and a flexible time limit for problem solving. The user may bet with the program that she will be able to solve a problem within in a time limit defined by the user. The shorter the time, the larger the odds.
The problem is presented as cards with digits. The cards are face down and the user can set the time and bet an amount of coins. (It turned out that betting coins was not a good idea in all countries, so the betting was done with marbles in the final version, but we continue with coins in this description).
The solving of the problem is done by turning the cards with digits and operators and moving them to a line where they should make up an equality.
A sample scenario goes like this:
User starts the program and get automatically the first task with the cards faced down. He decides the level of difficulty he wants to work with and gets a new set of cards. He judges the level of difficulty, the number of cards and decides the amount of time he will need.
He then bets an amount of coins that he can solve the problem in the stipulated time. He turns one card and notices that the odds is decreasing. He bets more coins and decides to start the game without peeping at more cards. The rest of the cards are turned and the time starts running. He starts moving cards in place, but he gets trouble and decides to terminate the problem solving. The coins disappears and the next problem is presented. The user bets again and starts the problem solving. This time he manages to solve the problem within the time limit and the coins multiplied by the odds are added to his coins, and the next problem appears.
We pick out the activities, the verbs, from the scenario:
| The student | The Program | The Teacher |
|
starts the program choose difficulty choose time bets coins turns a card strats the game move a card terminate the problem |
shows the problem decreases the odds turn the cards starts clock take away the coins "pay out" the coins |
has no spesific task, but set level of difficulty as part of a training session. |
The list is not complete, compared to the final functionality of the program, but it focus the important issues in the relation between user and program. It helps us distribute the responsibilities.
From the anatomy of the program, with a betting phase and a problem solving phase, it is obvious that we will have two main market places. These market places are categorised by the fact that they have different booths associated with them.
Note that the functions help, name registration and a top ten-list based on series of problems are introduced.
The design of the program screen, or window, was focused on keeping the two phases apart and making them clear and easy to distinguish. The main layout of the screen is dividing the area in two parts of roughly he same size. The betting to the right and the problem solving to the left.
A: The betted coins
B and D: Users coins
E: problem solving area
F and C: Status information
The manifestation of the time was problematic. The chosen solution is a linear time line, which serves as a delimiter between the two areas. The text is in Norwegian, but the screen layout should be self explanatory.
(The image has been reduced from the original.)
There are quite a few details in the dialog that had to be resolved. Some of these are:
In general the dialog is based on standard dialog elements and the exceptions, like direct manipulation, is hopefully evident from the metaphor.
Even if the dialog is fairly simple, there are always some situations that must be considered in more detail. For instance what should happen if the user tries to move coins into the card area and vica versa ? There are a many answers to this and at least a few are aceptable, but we have to decide.
Statediagrams are a useful tool for such detailed analyses. Below is a statdiagram that resolves the move coins problem.
There are a few other situations that have been resolved the same way.
A demo version of the program can be downloaded here.
