Being Consistent

Consistency in a user interface means more than just getting the File and Edit menus in the right place. The way your system interacts with users should also be consistent. When designing database systems, you need to pay attention to three areas: how users move through records in a table, how complex entities are represented, and how users initiate editing and adding records.

Most systems have a series of forms that represent each of the major entities in the system. You might, for instance, have a Customers form, a Products form, and a Sales Orders form. You must decide how users will move through the underlying recordsets. Unless you have a strong reason for using different mechanisms, you should choose one method and use it in every form.

By default, bound forms in both Access and Visual Basic display the first record in the underlying recordset and contain navigation buttons that allow users to move through the recordset. For various reasons, you might want to change this default interface. You might, for example, want to display only a single record and provide some other mechanism for choosing records to be displayed—perhaps a separate search form or a combo box control from which users can choose a record. Figure 12-3 shows an example of the latter technique, taken from the Access Developer Solutions sample database.

Figure 12-3. A combo box can sometimes be a useful mechanism for users to choose a client, but you must use it consistently.

Changing the default navigation mechanism is fine—in fact, there are often good reasons for doing so—but having chosen one, you should use it for all the forms in your system. It's unnecessary and confusing for users to have standard navigation buttons on the Customers form, a Find Order button on the Sales Order form, and a Products form presented in datasheet view.

The exception to this rule is if you have several categories of forms. You might decide to handle the forms used to maintain lookup tables differently than those used for entering primary entities. In this case, as long as the interface is consistent within the category, you're not placing an undue burden on users.

The second area where you need to be consistent is in representing complex entities. If you have entities that are modeled using more than one table in a one-to-many relationship (Sales Order entities are the classic example), you should be consistent in how you present them to users. You wouldn't want to present the line items of a sales order in a datasheet and the multiple contacts for a customer in a list box.

Unfortunately, consistency in this area is more difficult to maintain, particularly if there are more than two recordsets involved. A single form that has one datasheet for customer contacts, a second for addresses, and a third for products ordered can get ugly. You need to be inventive in these situations. Perhaps you can embed each datasheet in a tab control or use pop-up forms containing the datasheets. You might have to decide on two display methods and keep them as consistent as possible.

The final area to watch for consistency is the mechanism for creating and editing records, which must be absolutely consistent throughout the system. If one form allows editing in place but another requires users to explicitly enter edit mode by clicking on an Edit button or choosing a menu item, you've got a real user-confuser on your hands. Of course, edit modes aren't a good idea in general, as we've seen.

Sometimes, there are good reasons for locking records—that is, for not allowing editing in place—once they're saved. For example, you might allow users to change orders only prior to their shipment, after which time they become historical records that shouldn't change. Some designers implement a mechanism to check whether the order has been shipped when a user asks to edit it. Doing this is acceptable only if all forms behave this way.

A better solution is to allow editing in place but to lock all the fields on the form when a shipped order is displayed. This requires more work to implement, but it's work done by the system, not by the users, so it doesn't count. And it allows editing in place to be implemented in the rest of the system, where the locking of historical records doesn't apply.