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!›