User interface architectures can be divided into two groups based on whether the application displays only a single windowa single document interface (SDI)or displays a primary window inside of which additional windows can be openeda multiple document interface (MDI).
Neither style of interface is intrinsically better than the other. They both have advantages and disadvantages that we'll discuss in this section. Your choice of user interface architecture should be based on the work processes the system will support.
Single Document Interfaces
The SDI, as you might expect, presents users with only a single primary window. It can display additional dialog boxes for supplementary information. The SDI approach is suited to systems that are intended to maintain a single logical entity (which might be represented by any number of physical tables in the database). For example, a simple system for maintaining employee information might best be presented using an SDI.
The SDI has much to recommend it, since a single window is so easy for users to manipulate and keep track of. It conforms to the document-centered approach to user interface design recommended by the user interface wizards at Microsoft.
SDI systems are simple to build in Microsoft Visual Basic. It isn't possible to directly implement them with Microsoft Access, since all forms are contained in the Access window. You can, however, achieve the effect of an SDI by maximizing the system's primary form on application startup and eliminating its minimize button. In Access 2000 and later, you can also specify that the form window be shown in the task bar. So with careful management, your Access system can be, for all intents and purposes, an SDI application.
A workbook interface architecture is a special kind of SDI. In a workbook, different views of data are shown on tabs of a single window rather than in separate windows. Microsoft Excel is a good example of a workbook.
This interface architecture has the advantage of providing a secure context for users without restricting them to a single form. It can, however, be mildly tricky to implement with acceptable response times. But provided performance concerns are adequately addressed during implementation, the workbook is an extremely useful paradigm for presenting different views of an object or for presenting views of a closely related set of objects when users don't need to compare them.
For example, you might want to use a workbook to display a summary report of the month's sales on one tab, a pie chart showing sales by category on another tab, and a bar chart displaying year-to-date sales on a third tab. These are related bits of information, and it's reasonable to expect that users would want to view the reports as a group. But they probably don't need to see all the reports simultaneously, since the different reports are related but not directly comparable.
The tabs in a workbook have an implicit order that can be useful. Say that you're supporting a work process that consists of a number of discrete tasks and, further, that these tasks are often, but not always, performed in a specific order. You might use a workbook tab for each task. The order of the tabs supports the order in which the tasks are performed without forcing users to comply with that order.
On the other hand, a workbook isn't generally a good method for representing separate work processeswhich tend to be quite distinct activitiesor for presenting information that needs to be directly compared. Remember that only a single tab is visible at any given time, and you don't want to place an unfair burden on your users' short-term memories.
The Outlook-Style Interface
Another special kind of user interface architecture is what I think of as the "Outlook-style interface," since Microsoft Outlook is where I first saw it. This style of interface divides the application window into two panes, one containing a set of icons and the other containing documents, as shown in Figure 16-2.
Figure 16-2. The Outlook Interface Divides the Application Window into Two Panes
I like this style of interface for applications that support multiple work processes. The icon bar on the left provides an immediate context for users, and dividing the bar into panels allows icons to be grouped into functional areas.
Unfortunately, neither Access nor Visual Basic provides intrinsic controls for implementing this style of interface, despite the fact that it's implemented in the Microsoft Access Database window, as shown in Figure 16-3. However, Outlook-style controls are available from third parties for both environments.
Figure 16-3. The Database Window in Microsoft Access Uses an Outlook-Style Interface
If you do adopt this architecture, it's a good idea to allow users to hide the icon bar, as Outlook does. The icon bar is a good navigation mechanism, but once users have loaded the document they want to work with, they tend to stay there awhile, and the icon bar takes up scarce screen real estate.
Multiple Document Interfaces
The majority of database systems use some version of an MDI, allowing multiple child windows to be opened within the primary window. The child windows of an MDI application can contain different kinds of information, such as a form showing customers and a form showing orders. Or they can also show different views of the same information, such as a form with information about a customer and a report showing sales for that customer. Finally, they can show multiple instances of the same kind of information, such as one customer form showing details for Jones and another instance of the same form showing details for Smith.
As with SDI architectures, there are several ways of structuring MDI applications, each of which is suited to different requirements. We'll discuss the primary structures here, but be aware that these configurations are not exhaustive, nor are they necessarily mutually exclusive.
The "Classic" MDI Architecture
The classic structure for an MDI application is for a primary window to contain multiple child windows of either the same or differing types. MDI applications are useful in many situations where users need to compare several different bits of data or the same data in different formats. But MDI applications can be scary for new users: Choosing "New Whatever" from the File menu doesn't occur to a lot of people when they're presented with an apparently empty window.
The MDI versions of Microsoft Word (prior to Office 2000) allowed a command-line startup switch (/n) to automatically open a new document window on application startup, and you might consider doing something similar in your own application if you adopt this interface architecture. You might, for example, provide a switch that causes the Orders form to open for data entry.
Be sure to provide a mechanism for turning this functionality off, however, as it can be irritating to users for whom it's inappropriate. You also need to be careful during implementation that you aren't inadvertently displaying error messages to users who immediately close the window or, worse yet, adding empty records to the database.
The major problem with the MDI interface is the inconsistency in the containment model. The parent window visually contains the child windows opened within it, but the application it represents doesn't necessarily contain the objects represented in those windows. This tends to be a more acute problem in applications such as Microsoft Word, where the documents are actually distinct objects in the file system. Database applications usually do a far better job of isolating users from file system complexities. But even simple database applications are not completely effective in accomplishing this.
For example, look at Figure 16-4 from the Northwind sample database for Microsoft Access. Assume that a user has been switching back and forth between the windows and that uncommitted changes are pending in all of them.
Figure 16-4. The Containment Model in MDI Applications Can Confuse Users
If the user selects Save from the File menu, what's going to happen? Only the changes in the Suppliers window will be committed. You know that, because you know that menu options only apply to the current window. But does the user know that? Isn't it reasonable to expect that when you tell "Northwind" to save, "Northwind" will save all the changes you've made regardless of where you've made them?
The Windows Interface Guidelines for Software Design (woefully out of date, but still the best definition of the interface conventions) specifies that the item "Save All" can be added to the File menu to save all uncommitted changes in all open windows. This is undoubtedly a solution, but it's at best a compromise. It still requires that users understand that there's a difference between the MDI application and the objects on which it operates.
This difference is part of the implementation model, not the users' mental model, and it's a surprisingly difficult concept for users to understand. Even relatively sophisticated users can get confused about what's stored where. I still get confused about what formatting is stored with the document and what is stored with the style sheet in Microsoft Word, and I've been using the product extensively for many years.
All this having been said, however, classical MDI applications do have their place. They remain the best available solution for the majority of applications that require multiple windows to be open simultaneously.
A switchboard application displays a central form on application startup, as shown in Figure 16-5, again from the Northwind sample database. Most of the buttons on the form are tied to either forms or reports.
Figure 16-5. A Switchboard Is Displayed when the Application Starts
The databases generated by the Microsoft Access New Database wizard use the switchboard structure, and so this structure has become quite common for database applications developed in that environment. It would be easy to implement similar behavior using Visual Basic.
I must admit to a prejudice against switchboards. Something about them feels DOS-like and clunky. I also worry that they encourage the "Find a Record/Edit a Record/Print a Record" menu structure that is so incredibly tedious for users.
Switchboard applications can be useful, however, if you have several distinct work processes that are being supported within the same application, and you either don't want to buy into the implementation complexity of the Outlook-style interface or your application requires multiple windows open simultaneously. A top-level switchboard that contains a button for each work process is an elegant mechanism for guiding users into the application.
The important thing to remember in designing switchboard applications, as with any other interface architecture, is to structure the switchboard choices around the work processes, not around the data. You should have a button for every activity users will want to perform, not for every form and report in the system.
I think of a project interface as a switchboard application without a containing window. Instead, a "Project" window (which need not be called that, of course) provides a mechanism for opening windows independently on the desktop. The Visual Basic 6.0 SDI interface is a good example of a project interface, as shown in Figure 16-6.
Figure 16-6. Visual Basic in SDI Mode Is a Project Interface
Once open, these independent windows are displayed in the taskbar and users can manage them independently. They are also controlled by the Project window. When the Project window is minimized or closed, the secondary windows are also affected.
The project interface, by eliminating containment, avoids the model inconsistency inherent in classic MDI applications, but it substitutes another inconsistency: the relationship between the Project window and the (apparently) independent secondary windows.
Consider this scenario: A user opens a secondary window by double-clicking in the Project window, and then to free up space on the desktop, minimizes the Project window. Poof, the window the user just opened has disappeared. Yes, it can always be restored from the taskbar, but what a user-confuser.
If you like the idea of a project window, I think that the model of the Database window in Access is preferable to a conventional project interface. The Database window provides the navigation advantages of a project window without the potentially frightening side effects, since it's part of a classic MDI application.
The final form of interface architecture that has a role in database applications is the wizard. Wizards are made up of a series of pages displayed in a dialog box, as shown in Figure 16-7.
Figure 16-7. Microsoft Access 2000 Uses Wizards Extensively
Wizards are most often used to support tasks that are performed infrequently, such as installation or hardware configuration. But it's certainly appropriate to use them to support infrequent work processes in database applications.
Wizards can also be useful to support complex work processes. If a work process consists of many distinct tasks that must (or at least can) be performed in a specific order, a wizard might be a good interface choice. Wizards are particularly useful if the work process has a lot of conditional tasks: "If condition a, perform task 3 and then task 4; if condition b, skip to task 6."
Using wizards for complex work processes is feasible, however, only if the individual tasks can be completed in the order in which the wizard presents them. This occurs less often than one might expect. If the tasks needn't be entered in a specific order, a wizard isn't the best interface, or at least shouldn't be the only interface for completing the task.
When using a wizard in a database application, you need to give careful consideration to how and when data entered by users should be stored. The usual model is that, if a user presses Cancel at any point during the process, the system is returned to the state it was in before the wizard was initiatedthat is, any data the user might have entered is thrown away.
Depending on the application, you could consider either saving the data as each wizard page is completed or giving users the option of saving previously entered data when they cancel. I don't recommend either of these as a general rule, but if the wizard has a lot of data entry, it might be justified.
Alternatively, you might consider allowing users to temporarily halt a wizard and continue it later. This is a very usable solution, but it does add quite a bit of implementation complexity, since it requires a temporary data store, some mechanism for determining where a user stopped, and the ability to resume from that point.