# Only Human Series Part 2

The second part of our series on user-friendly programs, with the emphasis on education

Volume 2

Number 1

March 1984

# 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

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.

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.

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