*************************************
                    *                                   *
                    *          DB/C Newsletter          *
                    *           November 1995           *
                    *                                   *
                    *************************************

                               Editor's Notes

     When DB/C programmers start to write their first GUI DB/C program,
they quickly recognize they are in foreign territory.  Gone are the familiar
KEYIN and DISPLAY verbs.  Without guidance many quickly get lost in a morass
of buttons and boxes.  This month's article may help to give guidance to
those who are starting down the GUI path.  For more information in designing
GUI programs, I can suggest these two books:

"The Windows Interface Guidelines for Software Design" from Microsoft Press

"Macintosh Human Interface Guidelines" from Addison Wesley

     DB/C 9 beta testing continues.  We have had substantive feedback from
a few beta testers.  Based on their input, we are adding several new features
to DB/C 9.  We will provide more details about these new features in next
month's DB/C Newsletter.

                                                           don.wills@swc.com


                            GUI Style Guidelines

     The move to a graphical user interface (GUI) can be hard for programmers
who are skilled in building character-based programs.  This is especially
true of DB/C programmers.  A character-based user interface (or CUI) built
with DB/C can be very feature rich - and many of the more advanced features
of a CUI program do not translate easily or well to a GUI environment.  In
this article, we will provide some guidelines for how to build GUI programs
that conform with the generally accepted GUI style, while still retaining as
much of the DB/C CUI functionality as possible.

     The fundamental difference between CUI and GUI programs is that in CUI
programs the programmer controls the flow of actions, whereas in GUI programs
the user controls the flow of actions.  GUI programs must be structured
differently to deal with this.  More importantly though, there are several
new principles to consider during the design of GUI-based programs.

     The user of a GUI program must feel like he is in control.  The concept
of "mode" is an aspect of the feeling of control that is important.  Many
CUI programs employ successive modes while leading the user through a series
of decisions.  A mode is a situation where only a limited number of actions
are allowed.  A well designed GUI program is modeless except for a minimal
number of modal dialogs.

     An example of a CUI program that contains modes is a report program
that prompts the user through a series of questions leading to this final
question - "OK to run report (Y/N)?".  If the user decides not to run the
report after having answered only the first of the questions, many CUI
programs force the user through all of the questions just to let them answer
"N" to the final "OK to run" question.

     Another example is a data entry screen that forces the user to press
the Enter key to drop through each of the fields until the Enter key has been
pressed on the bottom field.  Then and only then is the question "OK to add
record (Y/N)?" displayed.  In a modeless version of the program, the user
would be able to press the "Add record" button at any time.

     Another important aspect of GUI design is consistency.  In modal CUI
programs, consistency isn't that important.  With limited options in a mode,
somewhat inconsistent terminology doesn't cause any harm.  But when the user
can choose any function at any time, it is important for the user to know
exactly what operation he is activating.  Inconsistent terminology and
identification can cause errors in a modeless environment.  An example
of this is the use of the term "Close" in a push button in a GUI dialog box.
It is unclear whether this means "OK do it and make the dialog go away" or
"make the dialog go away without doing it".  The term "Close" should not be
used in a dialog box - use "OK" and "Cancel".

     Consistency within one program is important.  But consistency with other
programs is just as important.  You should use the same terminology and visual
cues that other GUI programs use.  Consistency reinforces one of the important
advantages of a GUI - when all programs look and feel the same, training cost
and time is minimized and users are more confident about running all programs.
This is important for all users, but is very important for casual users.

     Feedback is another important consideration.  Your programs should always
feel responsive to the user.  When an action is initiated, a response should
occur within a few seconds.  In addition, a progress bar or other indicator
that changes frequently enhances the user's feeling of being in control.

     As the programmer, you should build the user interface to accommodate
novices as well as experienced users.  It is important to have function keys
(or keystroke combinations) to allow an experienced user to quickly initiate
actions.  But it is even more important to make sure that the casual user can
easily initiate all of the functions of a program.  This latter requirement
may translate into a large number of menu items, but it is the correct way
to design the program.

     For DB/C programmers, one of the biggest changes is the action of the
Enter key.  In most DB/C programs, the Enter key means to finish entering
a field (and implicitly move to the next field) or to do the action chosen
with the previous keystroke.  For example, pressing the "Y" key followed by
pressing the Enter key is a typical CUI way to provide a positive response.
In most GUI programs, the Enter key is reserved for activating the default
push button.  The default push button is usually the positive action, so
the positive action is accomplished with one keystroke.  In GUI programs,
the Tab key is used to finish entering a field and move to the next field.

     DB/C 8 adheres the GUI Enter key conventions.  We have had considerable
negative feedback about this convention, so we are planning to add a feature
to DB/C 9 that causes the Enter key to function like the Tab key if there is
no default push button defined for a panel or dialog.  We recommend that you
design your programs with default push buttons, but if you want the Enter
key to work like in DB/C CUI programs, you can.

     The use of coded fields is another area where CUI DB/C programs don't
convert well to GUI programs.  Coded fields are not a problem if they only
represent two possible values.  For example, the field "Taxable (Y/N)" in
a CUI program converts directly to a check box.  For fields with only two
values, always use a check box - don't use a two button radio button group.
Coded fields with three or more values present more of a problem.  The
correct GUI design is to use a radio button group or a drop box.  The radio
button is more obvious and easier for the user to understand and change,
but the drop box takes up less room on the screen.

     Do not use radio buttons, drop boxes, list boxes or check boxes for
display-only fields.  When the user sees one of these controls, it is
implicit that the value in it can be changed.  If your program violates
this assumption by using these controls for display-only fields, users may
feel uncomfortable with your program.  They may think "If it violates this
rule, what other things might it be doing that I don't know about".  You
do not want users of your program thinking this thought.

     To deal with the display-only field situation, we are adding a new
control in DB/C 9.  It is a display-only text field.  It looks like an edit
box with a gray background.

     Here are some more GUI design tips:

1.  OK and Cancel are the preferred names for the push buttons that cause an
    action to occur or cause the action not to occur.  The OK button should
    be the default push button (that is, the Enter key causes its action to
    happen).  The Cancel button should be the escape push button (the Esc
    key causes this button's action to happen).  There may be a need for
    additional push buttons, but always try to use at least OK and Cancel.

2.  The correct spelling of OK is with both letters capitalized, not Ok.

3.  The Close function causes a window to disappear.  It does not cause an
    application to terminate.  In Windows, Exit causes the application to
    terminate.  In Mac OS, Quit causes the application to terminate.  The
    Exit/Quit difference is on the few differences that a DB/C programmer
    needs to deal with if you want to make your program have both the
    Windows and Mac OS look and feel.

4.  The ... (three periods) should only be used in a menu entry when a
    dialog box prompting for additional information will be displayed before
    the action is initiated.  For example, File Open and File Save As should
    have the three periods, but File Save should not.  Do not use three
    periods in a dialog box with a phrase like "Processing...".

5.  Be sure to gray menu items and controls that are not valid for the
    current state.  In certain situations, this may mean that almost all
    of the menu items or controls are gray.  A well-designed program is
    consistent with its use of the gray state.

6.  Don't use two radio button groups immediately above and below each
    other.  The user can't tell where on group starts and another ends.

7.  Warn the user if an action will cause a loss of data or an interruption
    that has other considerations.  If possible, the dialog message warning
    of this situation should use the OK and Cancel buttons.

8.  Use consistent and unambiguous words and phrases.  For example, the
    phrase "This action will cause data to be lost.  OK to continue?" works
    well with the OK and Cancel names for push buttons.  An example of a
    poorly worded message is "Do you want to terminate processing?".  Does
    Cancel mean continue processing or terminate processing?

    Properly designed GUI programs provide many benefits to the user.  As
the programmer, you are responsible for the making sure that your DB/C GUI
programs look and feel like other GUI programs.  There is a lot more to doing
good GUI design than is covered in this article, but hopefully it will get
you started down the GUI programming path.


                             DB/C Class Schedule

     The next DB/C class is not yet scheduled.