Validation - the secret of good software
IAN MURRAY takes an in-depth look at pitfalls facing the programmer
writing educational software
PUT yourself in the mind of a 10-year-old youngster. Sorry you
are a 10-year-old youngster ... hop along now and fetch your mum
or dad!
Good. Make certain Susan or Mike are not peeping over your shoulder.
Now we can pretend what it must be like to sit in front of the
screen at an age when being a teenager is like being grown-up.
There are zaps, whams and pows. You press keys and - wow! the
machine obeys you.
The rocket takes off. Another key is pressed and the screen
changes colour. It's wonderful.
For the first time in your short life, you are the boss and
completely in control.
The machine doesn't shout at you. Mum and dad think you're great
- well you haven't emptied the kitchen sink over the floor. And
it's fun!
The problem for the writers of educational software is that
youngsters love to experiment. Even with those simple (and dreadful)
addition programs.
You are asked to choose two numbers. The first time you obey
the instructions and choose two reasonable numbers.
The next time you choose two very large numbers - lots of noughts
in them. The answer miraculously appears - or does it?
Type in:
PRINT 1234567890 + 345600000000
The answer: 3.46834568E11 appears.
Horror! The machine is faulty. The youngster rushes into the
garden to tell dad that his computer must go straight back to
the shop.
We know that the answer is in exponential format because the
machine cannot handle very large integers. But your excited youngster
doesn't.
The desire to experiment with the extremes of the machine can
cause yet further havoc.
The screen display may collapse or be insufficient for the answer
- despite the answer being correct. Type in the following and
see what happens:
10 CLS
20 VDU 28,10,20,16,19
30 INPUT A
40 INPUT B
50 PRINT A+B
Run the program with two sensible numbers - like 23 and 47.
The result of 70 appears. Now run the program with 3456 and 1234567.
The answer you see is 023. This is correct?
What has happened is that the VDU 28 is the command for defining
a text window, and the window is not large enough for the whole
answer.
This may be a trivial example - but I have seen it several times
in educational software.
Alternatively, if the screen display collapses it often is impossible
to get it back without reloading the software completely.
The youngster gets quickly fed up. An otherwise good piece of
work lies unused because the programmer did not think like a child.
A young person will go to extraordinary lengths to experiment
- not with the lesson, but with the software teaching the lesson.
The job of structuring and limiting the range of possible replies
by the youngster is called validation. Good validation is the
secret to good software.
Bad validation either gives us £00.00 in our wage slip
or a gas bill for £200,000.00 when we have been on holiday
for two weeks.
The object of validation is not only to make software robust,
but also to direct the learning of the student.
Look back at the trivial addition example above. You may not
want the youngster to discover that there is a valid method of
writing numbers which includes the letter 'E'.
It may lead to running before walking or even the young person
being frightened off numbers by concepts which are beyond their
stage of development.
Your validation will therefore include, not only length of input
checks and number range of answer checks, but also character checks
to see that the correct type of keyboard character has been used.
As all validation is expensive on memory, you will need to develop
general purpose procedures to perform the checks - and an example
is given below.
Note, however, that in the BBC Micro there is a conflict between
the amount of memory space given over to clever program ideas
- and validation of those ideas - particularly in higher screen
modes.
You have to decide whether the last screen shape is worth the
possibility of the program crashing.
My general view is that with younger children - the program
must not crash.
Listing I, deliberately overdocu-mented, shows the kind of validation
routine you will need.
If you specify on entry to the function the highest and lowest
letters acceptable and how many you will allow the routine will
input routine to those specifications (see listing below).
As it stands this is a little limited. You may accept any length
up to a certain number of characters.
Then you would have to alter line 310 to just catching the Return
key.
You may decide to allow capitals and small letters. You would
then need a line 215 such as:
IF Entry > High
THEN Entry = Entry - 32
This spots an Ascii character larger than Z and brings the Ascii
character back down to capitals for processing purposes.
All data entry, once you have limited the number of characters
to be entered, should be done via a screen window.
The screen window must be large enough to take the width of
the data entry and deep enough to accommodate any error messages.
If you do this, you can keep on the screen any clever graphics,
which is entertaining to the viewer without the cumbersome use
of PRINT TABs to position your data entry.
You can happily clear the text window without worrying about
the rest of the display.
Disc fault 18 at 00/50.
I had this error message while writing this article. It is totally
uninformative, useless and encourages grown adults to tear their
hair out in frenzy.
The younger generation may be more self-controlled about the
hi-tech world, but useless error messages ruin software.
Youngsters are always going to examine your software and drive
it to the limits. Expect it. Gently inform them that you've sussed
this and they won't get away with it.
DO NOT use this as an error message:
Number out of range - try again
or:
Not valid
or worse - simply repeat the input question mark.
On data entry, you should always specify to the user what the
expected range of numbers/letters is:
I like a WHOLE number from 1 to 100.
What is your number?
If then the prankster types in 999, he has done it because:
• It's a genuine error - so repeat instructions.
• He's misread - so use simpler language.
• It's deliberate over-play - so inform the user we know the
prank.
Your number is no good.
Try a WHOLE number from 1 to 100.
Type in again?
Error messages occupy large amounts of memory space and are tedious
to type in. So store bits of the message in string variables.
For instance:
LET Error1$ = "Your number is"
LET Error2$ = "Type in again?"
LET Error3$ = "Try a WHOLE number"
You then make your error messages combinations of pre-planned
error messages. You will be surprised just how much memory and
typing this saves. Make certain they will all fit inside the text
window!
A full description on program assistance will be given in next
month's The Micro User.
But you should always know when the user is likely to forget
part of a data entry.
Science teachers scream blue murder if we leave the units off
our experiments and calculations.
"Three whats!?", they howl. "Miles -biscuit tins
what?"
I have noticed that most software is equally bad.
The worst asks you to type in a distance - no idea of units.
The moderately bad asks you to type in your distance in miles
- but then does not expect the user to specify any units.
You have to decide whether any units are necessary - not just
to run the program, but as a learning point.
There is a good example of excellent user assistance in London's
Smile maths software.
How good are you at coordinates? Do you always remember the
brackets round the number (6,3)
No? Why not!
The Smile maths software puts the brackets on the screen before
data entry and the numbers must be fitted inside the brackets.
Very good! You see ( , ) and your first numbers enters to the
left of the comma and the second to the right. To program this
is easy - it just requires thought.
The £ sign is a constant problem. It can easily be catered
for by typing: PRINT "£";FNinput("0","9",4)
Then the user is in no doubt about what is required. There is
always a conflict here between teaching and being too supportive.
With the brackets a happy compromise would be to generate the
brackets from the program if the user had not done so within a
specified period of time.
The INKEY command will help you here. A little teaching reminder
about brackets would not go amiss when the user is late with the
brackets - and then on with the software.
Mum gives Jonathan his computer for a birthday. Within weeks
he settles down. She buys him educational software.
Before very long she's telling the neighbours: "He's so
fast - he's learnt so much. He gets all the sums right".
Marge rushes straight off to buy her Sarah a BBC Micro hoping
that the same brilliance will attack her youngster.
It does - well not really. Jonathan and Sarah have learnt the
software - not the lesson.
Take those dreadful speed addition programs. The youngsters,
as you watch them, hardly wait for the sums on the screen before
they type in the answers.
Basically they are tackling the additions in the same way that
Snapper or Frogger are played. They have spotted the "pattern"
that makes the program work.
When you put fixed data into your programs, this will always
happen. In some cases you cannot avoid fixed data, such as names
of places and objects.
But where you can you should always try to use the random number
generator in Basic to generate a sample of data.
It is an awful waste of the programmer's time and your money,
when you purchase a very pretty program which the youngsters can
learn to do in five minutes.
This is the case with the BP Oil Slick program.
It is an enviromental studies game, but the youngsters learn
which way to disperse the slick by working out how to beat the
program.
I have found that they end up with little understanding of the
problems of pollution - which is a pity - unless they are restricted
as to the number of times they can play.
With more random data this might not have happened. It also
explains why the graphics programs are so good, because here the
user selects the data for the graphics, using the computer as
a tool.
This should give you some idea of the pitfalls facing the programmer
writing educational software.
In next month's article I shall be discussing how to entertain
the user.
The extended facilities of the BBC Micro allow us programmers
a lot of scope for keeping the attention of the user.
Suffice it to say that a good monster can do wonders for a banal
program.
10 CLS
20 A$=FNinput("Z",'A",6)
30 PRINT A$
40 END
100 DEF FNinput(High$,Low$,Num) 110 LOCAL High,Low,Counter,Entry,Delete
120 LOCAL Return,Temp$,Entry$
130 LET Delete=127 : LET Return=13
140 LET High=ASC (High$) : LET Low=ASC (Low$)
150 LET counter=0
160 REPEAT
170 REPEAT
180 REPEAT
190 Ok=FALSE
200 LET Entry$=GET$
210 Entry=ASC (Entry$)
220 IF Entry >= Low AND Entry <= High THEN Ok = TRUE
230 UNTIL (Counter = 0 AND Entry <> Delete) OR Counter <
Num OR (Counter = Num AND NOT Ok)
240 UNTIL Ok OR Entry = Delete OR Entry =Return
250 LET Counter=Counter+l
260 IF Entry=Delete THEN Counter=Counter-2
270 IF Entry=Return THEN Counter=Counter-l
280 LET Temp$=Temp$+Entry$
290 LET Temp$=LEFT$(Temp$,Counter)
300 IF Entry<>Return THEN PRINT Entry$;
310 UNTIL (Num=Counter AND Entry=Return)
320 PRINT 330 =Temp$
Listing I
