We build forms and put controls in them, without concern for the
users goals. We build menu systems without thinking about where the options should
be to be most useful. Forms tend to become crowded as we try to squeeze the last piece of
data into them.
The goal of this paper is to introduce some fundamental concepts
of user interface design. You will learn a set of design terms. You will examine various
design approaches and see the pros and cons of each one. You will review the form controls
in Visual FoxPro 6.0 and see the strengthsr and weaknesses of each one.
User Interface Styles
User interface designs are categorized into three types that
describe the overall style of the interface. The three groups are Process Centric,
Data Centric, and Goal Centric.
The process centric user interface centers around the processes
that the application provides. This style of interface is seen often in older
applications. For example, an application that is "menu driven" will often allow
the user to select and item from a menu, then it will display another menu and so on until
the user selects a system process like creating an invoice or editing a customer record.
Once the user has chosen to create an invoice they may not do anything else until they
finish with the invoice therefore the interface is Process Centric.
Process centric interfaces are the least desirable. They
frustrate users and get in the users way of doing their job. The job that a user has
to do is seldom easily relegated to a single system process. Users have diverse job
requirements, sometimes a user will have multiple responsibilities. For example, imagine a
user who has the two responsibilities of entering new invoices in the system and handling
the customer calls inquiring about their balances.
With the process centric interface, if that user starts to create
an invoice and the telephone rings with a balance inquiry, the user is in trouble. They
cannot leave the invoice creation operation to look up the customers balance. They
must complete the current task before they can start a new one.
Figures 1 and 2 below show a process centric menu system.
Figure 1. A process centric menu system.
Figure 2. The same menu system of figure 1 after the user chose
Create New Invoice.
As you can see in the figures, this menu system is going to start
off a process. Since the menu system is built this way, with cascading full screen menus,
you can be pretty sure that the create invoice operation is not going to allow the user to
switch to other tasks.
This user interface centers on the underlying data structures.
You will see this interface style used a lot. Why? Because it is the interface style that
developers are most comfortable with and it is developers that are designing the
We are database developers and as such, we know data and its
structures. We think in terms of tables and records, in terms of relationships between the
tables. We see the world as one big database. When we design a user interface, we tend to
design it with an orientation towards the data structures.
Orienting the user interface design to the underlying data
structure is not, necessarily, the best way to help the users meet their goals. Figure 3
shows a File menu from a Data Centric interface.
Figure 3. A data centric menu system.
Notice, in figure 3, that everything on the file menu directly
corresponds to a table in the data. The user can choose to work with the customer table or
the vendor table. Most likely, the forms used will present almost every field in each
table for data entry.
Place this interface into a real world situation. You have a
client whose business is very complex. There is a group of users who must process orders
for the company. They need to enter the order, flag it for fulfillment, track the
shipping, invoice the order once it has shipped, and produce statements for outstanding
How does the interface in figure 3 stand up to these
requirements? I say poorly, because I dont see any options to Initiate an order, or
to fulfill an order. I see Invoices listed, but that is going to bring up a form with one
invoice and all of its data. I really want an interface that allows me to fulfill multiple
orders with minimal effort. Looking up each invoice individually is not the best way to do
my job. This brings us to the third style of user interfaces.
This user interface style centers around the user's goals. Unlike
the previous two, this style does not root itself in system processes or data structures;
instead, this design is rooted in the actions and responsibilities of the user.
Figure 4 shows a sample menu from a system that is probably goal
Figure 4. A file menu from a goal centric user interface.
In figure 4 notice that the options on the menu are not data
structure oriented like figure 3 was. Instead, they are descriptive of user
responsibilities. Each menu option corresponds to a responsibility that a user must meet
in doing their job.
This system is very likely to allow the user to start another
task before finishing the current one. There are likely to be many responsibilities for
each user, and the system should allow the user to branch to wherever they choose within
Two Types of Applications
Besides the interface styles described above, there are two types
of applications Sovereign and Transient. This classification of an
application will help in deciding how the window or windows will behave.
Sovereign applications are those that occupy the users full
attention while being used. Things like word processors, spreadsheets, business
applications are among those that are sovereign.
These sovereign applications can take the entire display screen
for themselves if necessary. They can create system modal dialogs that prevent the user
form doing anything else until the dialog is dispatched.
Transient applications, on the other hand, are exactly that,
transient. They are utilities that the user may need for minor operations. A calculator or
calendar would be examples of transient applications. These applications should not
interfere with the sovereign applications. They should not occupy the entire display, but
rather only use the display area actually required. They should not be maximizable at all.
Transient applications need to coexist with sovereign applications.
In database application development you can look at a system as a
series of different forms, each of which may be sovereign or transient. The invoice
creation form may be sovereign. However, if from that invoice the user chooses a calendar
form to look up a date, the calendar should be transient, that is it should be a smaller
window that does not completely hide the underlying invoice form.
Transient forms are most useful if they are not modal. Making the
transient forms non-modal allows the user to leave them open in the background while they
do other work. The user can get to the calculator, calendar, or whatever easily and
quickly by leaving it open.
Designing Goal Centric User Interfaces
Interestingly, the best interface for the user is the one that is
most difficult for the developer to build. Designing a goal centric user interface
requires a clear understanding of what the users job is and what they do all day. To
find this out you must spend time with the users and observe their work habits. You need
to interview them to collect information about what their job goals are.
You cannot design an interface to meet the goals if you
dont know what those goals are. Often, management may try to insulate the users from
your interviews. You have to find a way to get past that and get to the actual users of
the system. Seldom are the goals of management the same as those of the users.
Goal centric interfaces can meet both the goals of the user and
of management, in fact, goal centric interfaces are usually the best for meeting
managements goals because they dont get in the users way. They allow the
user to do their job in the most efficient manor.
Designing the goal centric user interface is more than making
menu items that look like they are goal oriented. It includes the selection of controls in
your forms. Know the controls well; know their strengths and weaknesses. Select controls
that further the effort to build a goal centric interface.
Design Forms and Menus that Focus on the Users
The biggest mistake made in this area is building an interface
because this is how we have always done it. In truth, a goal centric user interface will
be very different for every user (sometimes different users will require different
interfaces within the same system).
You may develop applications for different clients that manage
similar data but have very different interfaces. Each client has their set of goals for
the system and the interface should be build to assist them in reaching those goals.
The following sections of this paper discuss each of the common
form controls and present their strengths and weaknesses. If there is any control that you
think has no weaknesses, then you certainly dont know that control very well. All
controls have weaknesses, often the weakness is a result of the very thing that the
control is good at.
Textbox and Editbox
Textbox and Editbox
The textbox and editbox are the most recognizable controls for
the user. These controls are seen all over the interfaces of all applications. The user
will inherently understand how to work with these two controls.
These two controls are quite flexible allowing you to customize
their behavior very easily. The textbox can be used for many different data types. The
editbox is restricted to character data only.
The textbox is the work horse control for most form interfaces.
Both these controls are acceptable in "heads-down" data entry as they allow the
user to keep their eyes on the data being entered and their fingers on the keyboard.
A common mistake in interface design is to think that one is
helping the user by providing ComboBoxes or Lists to select textual data. In fact, users
are faster when typing the text directly into a textbox or editbox. The textbox and
editbox allow the user to keep their hands on the keyboard, while a combo or list will
require them to reach for the mouse.
The Spinner control is used to enter numeric data only. It allows
the user to either type the number in or use the up and down buttons to "spin"
the number up or down.
The spinner control can be used in the "heads-down"
data entry as it allows typing and does not require the use of the mouse. Spinners can be
constructed to allow different ranges of values for keyboard entry and spinner button
entry. There are probably not many situations where you would want the Keyboard range to
be different from the spinner range, but if you encounter one you can set up the control
to allow it.
Command buttons are another intuitive control. Users know how to
use them. Command buttons should be limited to an action option only; that is they should
do something like Edit, Save, Exit, etc. Using a command button to edit data is of
questionable value because the command button is recognized by the user as an action
control, and using it to edit data may be confusing to the user.
Checkboxes come in two flavors Regular and Graphic. The regular
checkbox is the one that has a check mark and a prompt. Clicking on a checkbox, or
pressing enter while the focus is on a checkbox, causes the checkbox to toggle its value.
The value for a checkbox can be either numeric or logical. If
numeric unchecked will be zero and checked is anything but zero. Logical uses .T. for
checked and .F. for unchecked.
The checkbox appears at first to be a very simple control,
however, in a situation where data entry speed is important the checkbox can get in the
users way. The checkbox has no simple keyboard mechanism for changing its value and
moving on to the next control. The Enter key may work, until a command button with its
Default property set to .T. shows up. Avoid checkboxes when entry speed is important.
The second type of checkbox is called the graphical checkbox. You
have probably seen those buttons that stay pushed down when you click them, until you
click them again to pop them back up. These buttons are actually graphical checkboxes. You
can make a checkbox graphical by setting its Style property to 1 (Graphical). The Value
property of the checkbox remains unchanged, it may be logical or numeric and the values
for pushed equal the values for checked.
Many time you may need to present the user with a fixed set of
mutually exclusive options, like Gender: Male Female Other. The OptionGroup is a control
that can do this. The OptionGroup used to be called a radio button set.
In certain interfaces the OptionGroup can be a very helpful and
intuitive device for the user, however, as with many other controls, the OptionGroup is of
questionable value in a rapid data entry situation. It also is problematic when the users
are touch typists who dont want to reach for the mouse during data entry.
List and Combo Boxes
List and Combo Boxes
I combine these two controls together because they share a number
of qualities with one and other.
Both of these controls are for managing lists of possible
choices. They both allow the user to select items from the list of possible choices. The
key point to note here is that the user must navigate the list of choices in order to find
what they want. It is impractical to ask a user to navigate through a list of thousands or
even hundreds of items to find the one they need. You should try to keep the number of
items in a List or Combo box below 100 or so. More choices than that are much better
handled with other interface designs that provide controls to assist the user in narrowing
their search down before making a selection.
The ListBox is a familiar control that displays a scrollable list
of possible choices and allows the user to select one or more of them.
One point that is often overlooked is that a list should only
contain items that are valid for selection. Visual FoxPro gives us full control over the
contents of the list and therefore there is no reason that a user should ever be able to
select an invalid item. If an item is invalid in the current context, then remove it from
Lists are very powerful controls, however they are a poor choice
for rapid data entry.
Combo boxes come in two varieties, the drop down list and the
drop down combo. The difference is that the drop down list restricts the user to only
selecting items that are in the list for the combo and the drop down combo will allow the
user to type a value in the control that is not in the list.
The drop down combo style has some peculiarities that you should
know about. If the user types a value in the combo that is not the list, the display will
go blank when the user leaves the control. This occurs because the combo tries to
synchronize its ControlSource with an item in its list and it cant, because the
value in the ControlSource is not in the list.
It is common to want to use a drop down combo and not alter the
RowSource of the combobox. This can be done by using a trick. Use a combo with a
RowSourceType of 0 None and populate the Combos List using the AddListItem
method in the Combos Requery method. This will allow you to check the DisplayValue
against the Value in the combos Valid event and if they dont match add the
DisplayValue to the combos list (using AddListItem) without adding it to the lookup
table. You can also add code to the Refresh that will check the ControlSources value
against the Combos Value property and add an item if they dont match.
I have often heard developers say that their users love grids, I
wonder how many of them have investigated other alternative interface styles to find out
what the users really liked better?
In my opinion, the grid is probably the single most overused
control in all of Visual FoxPro. Grids present table information as a row and column
oriented display. This display exactly reflects the structure of the underlying data and
is therefore Data Centric in nature. If we really want to assist the users in getting
their job done, we need to create Goal Centric user interfaces. Whenever you see a grid in
a form, stop and ask yourself if the interface is goal or data centric.
A grid does have places where it excels, in a one to many edit
form a grid can be used to present the many side of the relationship. Invoices are a good
example, where a grid to display the lines of the invoice would be a powerful interface.
However, using a gird in a Customer edit form to allow the user to review all of the
customers in the table is really a data centric interface.
You need to ask yourself, "What does the user want to do
with this form?" Based on the answers to that question, design an interface that
aides the user in doing those things.
The PageFrame is another interface object that has limited
usefulness in rapid data entry applications. Of course if rapid data entry is not a major
concern then PageFrames become a very useful tool.
The obvious use for PageFrames is the tabbed dialog, where there
are multiple pages of information displayed in a single form.
Another, less obvious, use for PageFrames is to eliminate a
separate dialog form for certain functions. For example, you can provide a search feature
to a customer form by putting a PageFrame with two pages and no tabs. Use Page 1 for all
of the customer edit controls and use page 2 for the searching controls. Place a command
button for searching in the form and in its click you can change the ActivePage of the
PageFrame to 2. When the user finishes with the search, just change the ActivePage back to
1 again. No modal dialogs pop up during the search operation.
PageFrames are also subject to abuse. I saw one system that used
a PageFrame with a different page for each record in the table. This may seem like a good
idea when the table has 10 records, but what happens when the table has 10,000 records?
Ive also seen forms with PageFrames that had 20 or more pages in them. One has to
ask if the interface wouldnt be easier for the use if the form was broken up into
more than one form.
User interface design is more an art than a science. There are
guidelines that can be used but the final resulting interface design depends on many
unrelated issues. Issues like system requirements, user preferences, speed of data entry,
existing interfaces, intuitiveness, aesthetics, system performance requirements, and
In this paper we divided user interface designs into three
categories, Process Centric, Data Centric, and Goal Centric.
Applications were divided into two categories, Sovereign and Transient.
To design an effective user interface the application must be classified into the
appropriate category and then the interface style should be identified. Only after you
know these requirements can you begin to design an effective user interface.
For further reading on User Interface Design refer to "About
Face The Essentials of User Interface Design" by Alan Cooper. It is published by IDG
Books and has an ISBN of 1-56884-322-4 (available at www.amazon.com).