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.