User Interface Design in Visual FoxPro
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
User Interface Design in Visual FoxPro
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.
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 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 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 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 t