8-Bit Software Online Conversion

            Creating user friendly programs (4) ----------------------------------- by Steven Flintham (15A) ------------------------ Interacting with the user (1) ----------------------------- An extremely important part of any user friendly program is the way in which the user and program interact with one another. There are a variety of techniques available, such as: The WIMP approach ----------------- WIMP (Windows, Icons, Menus & Pointers) systems have become extremely common these days and have been around for some time now. The first real system of this kind on the BBC series was AMX Art, which was released around April 1985, if I remember correctly. Implementing a system of this standard on a machine with just 32k is difficult, and for many purposes not necessary - even if you have the AMX ROM which makes this type of programming easier, a large amount of RAM is still taken up by the control routines and data storage necessary. However, anyone who has used a PC will probably have come across the "text- based" type WIMP system which is often used - I think the PCPlus cover disc menu uses this system. This should be perfectly possible on the BBC series without too much trouble, and I might cover it later in this series. The command line approach ------------------------- Always fairly rare in applications, this is the type of interaction used by MS-DOS and similar operating systems. View's command menu is also an example of this type of user interface. These systems are fairly user un-friendly by virtue of their approach, although this isn't always a problem, as it can have advantages for experienced users in terms of speed and flexibility. The menu approach ----------------- This is what I intend to cover (at least partly) in this article. There are several different types of menu but they can be subdivided into two main categories - direct choice menus and "step selection" menus. Direct choice menus are those where the user directly enters a code of some sort representing the option they require. The 8BS menu is a good example of this type, although it is slightly unusual in the three digit codes used to select menu options. "Step selection" menus are those where one option is highlighted and, by some means or another, the user steps through the options which are then highlighted in turn. The highlighted option can then be chosen in some way. The 8BS software menu is of this type. There is also a variant on the step selection method which provides key shortcuts (often called hot keys) for some of the menu options, which can then be chosen with a single keypress. This allows the additional user friendliness of the step selection method with the speed of the direct entry method, at the cost of a little extra programming. Implementing direct choice menus -------------------------------- Direct choice menus are extremely easy to implement and require relatively little program code to produce them. They are therefore ideal if you want to try to use as little memory as possible. Their ease of implementation also makes them useful if you are in a hurry - perhaps when writing the first version of a program, when you want to get on with the main part of the code but need a menu structure to fit it together with. In a user-friendly program, it is important that the menu should be well laid out. The style is up to you - you may find some of the previous articles in this series helpful - but it is important to make sure that the "code" for each item is clearly visible. The program DirctC1 is an example of a direct choice menu in mode 7, showing one style which I find useful. The words "Main Menu" at the top of this menu are unnecessary, since there is only one menu in this program, but they do illustrate the principle of titling menus, which is important if there is more than one in a program. Having displayed the menu options, it is important to make sure that there is a clear prompt somewhere at either the top or (more usually) the bottom of the menu asking the user for his or her choice. If space permits, it is often a good idea to mention whether or not RETURN has to be pressed after the choice has been entered. For most menus, a REPEAT-UNTIL loop with a GET or GET$ command inside it will usually suffice - this avoids the need to press RETURN. This is the method used in DirctC1. Examining the program will show that the method is very simple. Notice the *FX21 at line 440 - this flushes the keyboard buffer to avoid the risk of accidental menu selection. The CHR$(GET AND &DF) in the next line is just there to make sure that an upper case character is returned whether or not CAPS LOCK is on. If it is important to ensure that accidental choices are not made, then a "confirmation key" can be used which must be pressed after a choice has been made. The 8BS menu uses this approach - although in this case it is also necessary because the choice contains more than one character. This type of system can be implented using the INPUT statement (or preferably a programmed version of this which avoids some of the problems with INPUT - such as the ability to enter control codes and the inability to control length). Alternatively, the method illustrated in DirctC2 can be used. The menu routine is slightly more complex here. Up to line 430, everything should be obvious - do note, however, that all the menu options are indented by 1 space (TAB(1,y)) to allow for the insertion of the flash control code. Line 430 itself stores the X and Y position of the space after the "Your choice?" prompt - this is to enable the choice to be printed at the appropriate point even after moving the cursor else -where. Line 450 sets the choice to 1 - this is done because when a new choice is made, the old one must be made to stop flashing. The first time around the loop, no old choice will have been made, so this line "pretends" that choice 1 has been made to allow it to be blanked correctly. Line 460 sets a flag (choice`made%) to show that this is not a real choice - otherwise, RETURN could be pressed before a selection has been made from the menu. This is checked in the UNTIl statement in line 510 - a RETURN will only be accepted if a choice has been made. Line 520 is the real heart of the menu routine. If RETURN has not been pressed, the choice`made% flag is set to TRUE, the choice is displayed next to the "Your choice?" prompt, the old choice is prevented from flashing by printing over the "flash code" with the "stop flashing" code and choice% is set to the new choice. Finally, a flash code is printed next to the new choice. Note that a default choice can be provided (if required) by making slight modifications to the code - as demonstrated in DirctC3. The changes involve setting choice% to the default choice, removing the choice`made% flag and modifying the initial display appropriately. Although this menu routine is not too long, if you are using several menus, it might be worthwhile removing the actual input routine to a separate function - DirctC4 is a version of DirctC3 using this method. The selection code has been transferred to a separate function (FNmenu`select (default%,choice`x%,choice`y%,options%, offset%) which can be used by any menu routine. The parameters are: default% - this is the number of the option which will be selected as default. If no default option is required, set this to -1. choice`x%, choice`y% - these are the X and Y coordinates respectively at which the letter corresponding to the choice should be displayed options% - this is the number of options in the menu offset% - this is the Y coordinate of the first line in the menu As always, you are free to use any of the routines provided with this article in your own programs, provided you do not make any profit from them - a mention in the documentation would also be appreciated, if possible! In the next article, I intend to cover step selection menus.                                    