Supporting the Work Processes

The most important principle in deciding how to structure the interface is that the choice must be based on the work processes your system supports, not on the structure of the data. Pay attention to what your users are trying to accomplish, and structure the system to support those activities.

It's an easy mistake to make: you look at the entity-relationship (E/R) diagram for the system and see an entity called "Customers," so you build a Customers form for creating and editing customer records. Then you build an Orders form that has a read-only reference to the Customers table. In an effort to make the system "user-friendly," you allow users to choose the customer name from a list, and you fill in the rest of the fields for them based on the information in the Customers table. Your form might look like the one shown in Figure 13-1, taken from the Northwind sample database.

click to view at full size.

Figure 13-1. The Orders form from the Northwind sample database.

This isn't a bad form, as forms go, but think about the users' task: they're entering a sales order. They open the Orders form only to discover that the customer isn't yet known to the system. So they have to leave the form, go someplace else in the system and enter the new customer, and then finally they get to enter the order. If the Orders form hasn't been closed, they'll probably need to remember to press Shift+F9 (or something equally self-evident) to refresh the Customers list. Painful.

Some designers address this problem by using the NotInList event of a combo box to allow users to enter a new name. When the event is triggered, these designers display a message box asking whether to add a new customer, and if a user confirms the addition, the Customers form opens.

This solution saves a few keystrokes, but it still forces users to stop what they're doing (entering a sales order) and do something else (maintain the customer list). It would be far better to allow users to complete the task at hand without interruption. If a user enters a customer name that's not in the list, the fields that would otherwise have been filled in will be blank. (This is sufficient notice that the customer is new, by the way; there's no reason to scare people by beeping at them and displaying unnecessary message boxes.) After a user has filled in the fields, the system can quietly add the new customer record in the background.

If all the fields in the customer record can be obtained from the Orders form, you're done. If additional fields exist (as is often the case), you might decide to ask users whether they'd like to add that information after they finish filling in the sales order. (But be sure not to ask until the order is finished—it's rude to interrupt.) You should base your decision on the circumstances under which the order is being entered—in other words, on the work processes.

If the order is being entered by a sales clerk with the new customer standing in front of her, after the order is taken is an excellent time to capture that information. "Since you're a new customer, would you mind providing some additional information…" In the same way, if the additional customer information (or at least some of it) is on the Orders form being used for data input, allowing users to easily enter the information while it's in front of them will save them from digging the papers out later.

But if users have a stack of sales orders to enter and the additional customer information isn't immediately available to them, they're going to dismiss the dialog 99 percent of the time without entering the additional information. Constantly prompting users to enter information they don't have isn't helpful, it's harassment. A better approach would be to flag the incomplete records to allow users to easily find them later when the information is available.

You might want to ask users whether they want to go directly to Customers maintenance (or whatever it's called in your system) when they exit the Orders form. But do this only if finding and entering this information is a sensible next step for the individuals who enter the sales orders.



Designing Relational Database Systems
Designing Relational Database Systems (Dv-Mps Designing)
ISBN: 073560634X
EAN: 2147483647
Year: 1999
Pages: 124

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net