User Interface Design

Introduction

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.

Difficulty Level

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.

Process 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 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.

Data Centric

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.

Goal Centric

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 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 the system.

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.

Form Controls

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.

Spinner

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

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.

CheckBox

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 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, that is it may be logical or numeric and the values for pushed equal the values for checked.

OptionGroup

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.

ListBox

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 data entry.

ComboBox

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.

Grid

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 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.

PageFrame

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? 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.

Summary

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 others.

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.