User Interface Design
User interface design is a vast and often misunderstood area of application
design. Too often, in application development, there is a large amount of time
spent designing the data and the application framework. There is very little
time spent designing the user interface.
We build forms and put controls in them, without concern for the user’s goals.
We build menus 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 session 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 benefits and downside of each one. You will review
the form controls in Visual FoxPro 6.0 and see the power and weaknesses of each.
Who is this session for?
This session is for you if you meet
any of the following criteria.
- Are familiar with the Visual FoxPro form designer
- Are familiar with Visual FoxPro form controls
- Want to know more about user interface design.
This session is aimed at intermediate
to advanced Visual FoxPro developers but people just starting with Visual FoxPro
can benefit also.
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 user interface centers around the processes that the application provides.
This style of interface is seen best in looking at 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 user’s way of doing their job. The job that a user has to do is seldom
easily relegated to a single system process. User’s 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 and 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 customer’s 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 from figure 1 after the user chose Create New
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
developer’s are most comfortable with.
We are database developers and as such, we know data and its structures. We
think in terms of tables and record, 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 balances.
How does the interface in figure 3 stand up to these requirements? I say poorly,
because I don’t 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 goals that the user has. 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 centric.
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
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 user’s 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 most difficult to design
for the developer. Designing a goal centric user interface requires a clear
understanding of what the user’s 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 goals.
You cannot design an interface to meet the goals if you don’t 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.
User centric interfaces can meet both the goals of the user and of management,
in fact, goal centric interfaces are usually the best for meeting management’s
goals because they don’t get in the user’s 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 User’s Goals
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 may be
very different for each user.
You may build some applications that have different menus and forms for each
user of the system. Most often the users will be able to be grouped together
into goal oriented groups and the interfaces can be provided to each group.
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 form controls and
present their strengths and weaknesses. If there is any control that you think
has no weaknesses, then you certainly don’t 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
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 error is 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 alter 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 user’s 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
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, that is 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
touch typists who don’t want to reach for the mouse during data entry.
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 item 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
choice 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 used should ever be bale
to select an invalid item. If an item is invalid in the current context, then
remove it from the list.
Lists are very powerful controls, however they are a poor choice for rapid
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. Th9is occurs because the combo tries
to synchronize its ControlSource with an item in its list and it can’t, 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 Combo’s List using the AddListItem method in the
Combo’s Requery method. This will allow you to check the DisplayValue against
the Value in the combo’s Valid event and if they don’t match add the DisplayValue
to the combo’s list without needing to add it to some lookup table. You can
also add code to the Refresh that will check the ControlSource’s value against
the Combo’s Value property and add an item if they don’t match.
I have often heard developers say that their users love the grid, I wonder
how many of them have investigated other alternatives 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
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
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? I’ve also seen forms with PageFrames that had 20 or more pages in them.
One has to ask if the interface wouldn’t 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,
In this session 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.