BASIC 101: An Informative Series¢¢By John Kasupski, WNYAUG¢Part Five: The Human Factor¢¢¢ As I promised last month, in this¢installment of BASIC 101 we will take a¢little break from talking about the¢"nuts and bolts" of BASIC programming.¢Instead we'll take a moment to discuss¢what's known as "human engineering" as¢it applies to programming.¢¢ Why is this necessary? All too¢often we get caught up in all the¢technical aspects of programming. We¢spend hours trying to get our computers¢to do all sorts of neat things, adding¢all sorts of bells and whistles to our¢programs, and in so doing we forget¢that although a computer is going to¢run the program, a human being is going¢to operate the computer. In other¢words, too many programs are written¢with the computer in mind, instead of¢the user.¢¢ So, let this month's BASIC 101¢serve as a reminder to all BASIC¢programmers. Don't let bits and bytes¢and PEEKs and POKEs and hardware get in¢the way: NEVER FORGET THE USER!¢¢ We saw an example of this earlier¢in this series when we talked about¢error-trapping of programs. We¢error-trap programs because the user is¢a human being, and human beings make¢mistakes. They enter letters where¢numbers are expected, they forget to¢put the disk in the drive, they try to¢write to write-protected disks, they¢misspell filenames. Humans have a way¢of doing all sorts of things that¢computers and computer programs don't¢like, so we have to teach our BASIC¢programs to act civilized when the user¢screws up. Otherwise BASIC will simply¢scold the user with something like¢"ERROR 170 AT LINE 2200" and stop¢executing.¢¢ To a user, this type of negative¢feedback can be very frustrating. What¢if the user doesn't know that he/she is¢expected to enter a number? If the¢program expects a number, the user, who¢thinks a letter is appropriate, has no¢idea why the program just stopped. If¢our programs do this too frequently,¢the user is simply not going to like¢our programs, and if a programmer¢writes several programs a user doesn't¢like, the user isn't going to like that¢programmer either.¢¢ What happens then is that the user¢doesn't even bother to look at that¢programmer's next effort. By writing¢programs that aren't user-friendly, the¢programmer eventually shrinks his/her¢own user base!¢¢ So let's look at some "human¢engineering" factors that apply to our¢BASIC programs and see if we can't¢learn to write programs that users will¢be more likely to appreciate!¢¢ One thing I never forget when¢writing a new BASIC program, or¢modifying an old one, is that different¢users have different system¢configurations. On one user's system,¢disk drive one may be a floppy disk¢drive. On another's, drive one is a MIO¢ramdisk. On still another, it's a hard¢drive partition.¢¢ If, therefore, we write a database¢program that has the capability to¢format a data disk for the program to¢use, but will ONLY format a disk in¢drive one, we are assuming that the¢user has a floppy as drive one. If our¢program formats a 16-Meg partition on¢the user's hard drive, we are going to¢have one very upset user.¢¢ The lesson here is, don't assume¢anything about the user's system¢configuration (You know what happens¢when we assume things, don't you?).¢¢ If we are wise, we write our¢program so that the user can select¢which drive to format the disk in. This¢won't necessarily prevent the user from¢formatting his hard drive, but it will¢make it pretty hard for the user to¢blame us or our program (after all, the¢user TOLD the program to format that¢drive, right?).¢¢ Another thing to consider when¢writing programs is the issue of delay¢times. Have you ever booted a program¢that blanked out the screen for a full¢minute, or even thirty seconds, before¢even so much as a title screen¢appeared? If you even waited that long,¢you were probably wondering if your¢computer had locked up, or if you were¢supposed to boot with BASIC disabled¢(or enabled), or if you should have¢booted a translator disk first, or if¢you had the wrong disk in the drive,¢or if the disk is bad, or...¢¢ Get the idea? If your program is¢going to blank the screen for more than¢a few seconds, without so much as a¢warning to the user that this is about¢to happen, something's wrong with your¢program.¢¢ Although turning off the ANTIC¢chip DOES speed up computation by as¢much as 33%, it is a drastic step which¢presents the user with a DEAD screen.¢The computer will not respond to the¢user, and there's no sign that the¢computer is not dead. If possible, it's¢better to leave the screen display¢enabled, perhaps displaying a countdown¢on the screen.¢¢ Better still is to eliminate such¢delays as much as possible by speeding¢up the program. Critical routines can¢often be rewritten to speed up¢execution. Going to Graphics 3 mode¢during calculations speeds up execution¢because the simple mode requires less¢DMA access by the ANTIC chip. This lets¢us put "Please stand by..." in the text¢window, perhaps with a countdown as¢well, while also doing what we can to¢speed up the program.¢¢ Proper nesting of loops also¢helps: The loop with the greater number¢of iterations should be within the¢other loop.¢¢ Error handling is another¢important consideration. As we shall¢see in subsequent installments of BASIC¢101, it is possible to program so that¢bad user inputs are entirely ignored.¢We can program such that if, say, a¢number is needed, the program will¢ignore all input except numbers within¢the appropriate range.¢¢ The problem with this is, if the¢user is entering a letter, then in all¢probability the user believes that a¢letter is acceptable input. Ignoring¢the input compounds the problem because¢if the user presses the "wrong" key,¢NOTHING happens. NO keyclick is¢generated, NO character appears on the¢screen, and the user is led to believe¢that something's wrong with his¢computer, or the program. And, in the¢latter case, he's absolutely right!¢¢ Yes, masking out improper input¢DOES prevent the program from crashing,¢but it does NOT protect the user from¢confusion. That is why, in our¢batting-averages program from the¢earlier installments, we used prompts,¢printed to the screen, to advise the¢user of what type of input was expected¢of him/her.¢¢ There's a down side to doing too¢much error-trapping. Have you ever¢gotten tired of seeing "Are You Sure?"¢on your screen? If you've been¢programming long, I'm sure you have. If¢not, you will be sooner or later (trust¢me!).¢¢ How do we get around this problem?¢How about dual-level protection ratios?¢That is, we let the program default to¢a highly protected state where every¢important command (format disk, erase¢memory, quit, etc.) must be verified¢("Are You Sure?"). The user may elect¢to switch to a "high-speed" mode,¢enabling the experienced user to work¢at a faster pace, free from "human¢engineering" protection that slows down¢the user's interaction with the¢program.¢¢ Overall, how do we know that we've¢written a good, user-friendly program?¢I find that a good measure of our¢success (or failure) is the amount of¢time that a first-time user will spend¢to learn to use the program¢satisfactorily. If we've written a¢really good program, most users will be¢flying along like experts in a matter¢of minutes. If we haven't, the user¢will be married to the instruction¢manual for the next few days, or weeks,¢or months, before getting any¢substantial results.¢¢ For an example of a really good¢program that meets almost all of my¢criteria for user-friendliness, take a¢look at the ShareWare program Disk¢Communicator 3.2 by Robert Puff. Yes,¢this is in machine language, not BASIC,¢but it's still an example of a program¢written with the user in mind: It¢supports any disk drive number, it¢handles errors without aborting most¢processes, it works with a variety of¢system configurations, and the user can¢get the desired results with a minimum¢of documentation-reading.¢¢ I successfully compressed and¢decompressed a disk with Disk¢Communicator 3.2 the first time I used¢it, WITHOUT EVEN READING THE¢DOCUMENTATION FIRST. This says a lot,¢because I have programs that I've had¢for YEARS and I STILL can't figure them¢out!¢¢ On the other hand AwardWare, by¢High-Tech Expressions is ABSOLUTELY¢USELESS without the documentation even¢if you've been using the program for¢years. I can whip up a nice-looking¢document with Print Shop AND have it¢printed out in less time than it takes¢me to set up the template with¢AwardWare.¢¢ This brings up another point about¢programming: documentation. From the¢standpoint of human engineering ONLY,¢ALL documentation should be included in¢the program. The problem with that is¢that we can run out of memory writing¢the documentation and have none left¢for the program itself! Therefore we¢must strike a happy medium, including¢in the program only what is absolutely¢critical to the program, and put the¢rest in a hardcopy manual or a separate¢text file containing the¢documentation.¢¢ Yes, I said "a separate text file¢containing the documentation." And now¢I've said it twice. If you turn a¢program loose without documentation,¢you haven't listened to a word I've¢been saying since the beginning of this¢article. "When all else fails, read the¢instructions...and if there aren't any,¢get another program!"¢¢ The informative manual DE RE ATARI¢contains an excellent discussion of¢human engineering in programming,¢written by Chris Crawford. While I¢DON'T agree with ALL of Mr. Crawford's¢ideas, I DO recommend that you read¢Appendix B of DE RE ATARI if you want¢further information about the human¢factor in programming. Although the¢manual is out of print, it is usually¢available from American Techna-Vision¢for about $10.00 or, if you're lucky,¢someone you know may have a copy you¢can borrow.¢¢ As for BASIC 101, our continuing¢series will periodically remind you to¢keep the user in mind as we move into¢various ways of getting and screening¢user input. Next month, for example,¢we'll be looking at various methods of¢reading the keyboard, something which¢requires a lot of error-trapping which¢we'll build right into our examples.¢After that we'll discuss performing¢DOS functions from BASIC, where things¢can REALLY get screwed up if we aren't¢careful. So, human engineering will¢stay with us as we continue our series.¢Hopefully, so will you!¢
