User Interface Standards

  • Article

This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.

Dennis Schumaker

In this article, Dennis Schumaker discusses the importance of user interface standards for both programmer and end-user productivity. As a case study, Dennis discusses when to use the navigation methods available to the Access programmer and shows how to implement the most useful ones.

Without programming standards, it's difficult to bring new developers into your organization and quickly make them productive. Without user interface standards, it's difficult to bring new people into your organization and quickly make them productive with your custom software applications. Many user interface features are the result of many years of trial-and-error experimenting. They aren't just the result of finding better ways to interact with the user, but also the result of learning about techniques that don't work. Without standards, your developers might implement one of those unfortunate user interface designs.

The need for user interface standards became apparent to our organization when we added two new programmers to a five-person programming team. Our organization had been fairly diligent in adopting programming standards for naming tables, forms, variables, and other developer products. However, the various applications developed over the past several years varied significantly in their user interfaces. We'd never looked critically at the appearance of our applications to pull the best concepts from each and mold those concepts into a standard user interface design. Though many "theoretical" books have been written discussing user interface design, when you attempt to create a user interface design standard to use within your own organization, theory might not be enough.

In this article, I'm going to focus on the kind of analysis that we did to develop our standards. What I want to model for you isn't a particular set of standards (though I'll be showing our standard for navigation, too) but the kind of process that you should go through in creating your user interface standards. For our navigation standard, I'll also show you how to implement the standard so that you can see the techniques behind the design. Chasing down the navigation standard, I'll go one level deeper in the process to discuss how we organize our menus. But before any of that, I'll discuss how we created our model application that acts as the reference point in user interface design.

A work in progress

We'd used various techniques for navigation, including switchboards, command buttons on forms, and drop-down menus. In our defense, the design of the applications we built for our clients was driven by the specific business needs of organizations to fit into their culture. The design was also driven, to a large extent, by the experience level of the application's programmer. We needed to leverage the background and skills of all of our programming staff to bring the greatest productivity to our organization. It became clear that more standardization was necessary to permit our programmers to rapidly develop applications to meet client needs.

In addition, we needed to quickly bring new programmers up to speed. Most of our applications had been developed over a long time period (in some cases five to six years) and had become extremely complicated and difficult for a new person to quickly grasp. We found that new programmers had difficulty working even in limited areas of these applications (such as enhancing reports) due to the learning curve required. And what they learned on one application often didn't carry over to other applications.

Fortunately, we stumbled upon a solution to this problem. Several years ago, we'd used a Microsoft Access 97 database wizard to create a simple application for tracking compact discs (CDs). The wizard created an application that consisted of roughly four or five tables, forms, and reports, all linked together using a switchboard design. We modified the application to meet some specific needs, but the application severely lacked some functionality and "quality of design" compared to the applications that our firm had developed. As a training exercise, we directed our new programmers to rewrite this simple application, using the best of the user interface designs that we'd incorporated into projects for our clients.

The beauty of the CD application was that it was small enough for a novice programmer to be responsible for the whole application (forms, reports, database design and relationships, navigation, and so on). The project resulted in an enhanced application and served as an example of user interface standards for all future application development efforts. This application was used as the case study when we drafted programming standards for user interface design for our organization.

Making UI standards useful

We also realized that for our user interface standards to be useful to programmers, they needed to be set up in a way that made it easy for developers to find the relevant standard. To make it easy for developers to find the information that they need, we organized our user interface standards into four major areas:

  • Navigation: We needed to develop a standard method for navigating through our applications. In the past we'd used switchboards, command buttons on forms, and drop-down menus. We decided to standardize on the use of one form of navigation, drop-down menus, which we felt would provide us the most flexibility in all of our applications.
  • Forms: We needed to develop a standard method for laying out and presenting information on forms, including methods of navigating between various parts of the form, standard colors for forms, and some of the basic functionality that should be built into all forms.
  • Reports: We needed to develop a standard design and layout for all reports. We believed it necessary to develop standard report design guideline (all reports include a printed date, page 1 of __, report name, standard font, and so on) and techniques for permitting users to select reports for printing that would be both easy to maintain and easy for a user to understand.
  • Documentation: Last, but not least, we needed standards around the documentation we'd produce, both for systems and user documentation. Our programming standards and the use of FMS tools such as Total Access Analyzer, to a large part, addressed the system documentation requirements. However, we needed to develop a standard for user documentation including the use of screen captures and various features in Microsoft Word that would be used in creating this documentation.

Navigation was the first area we focused on for our revised interface standards and is the area that I'll discuss in this article.

In Microsoft Access, there are four basic approaches that can be taken with respect to navigation:

  • Switchboards
  • Command buttons on forms
  • Drop-down menus
  • Toolbars

We used each of these techniques in the applications that had been developed over the past several years. In fact, we progressed from switchboards to command buttons on forms to drop-down menus as our programming staff became more familiar with each approach. In this section, I'll outline the kind of analysis that we did on each of these methods. I want to emphasize that none of these methods is bad. However, each is suited to a certain kind of application, as you'll see.

****

Switchboards

Our earliest applications were developed using switchboards, as shown in Figure 1. We chose the switchboard approach because it was the last area of the application that we'd developed. On our earlier applications, we'd spent our time developing the actual table structures and integrating the business rules into the various forms. We gave very little thought to exactly how the user would navigate to the various forms to perform various business processes. The quickest way to tie all of the various forms together was by using another form—that is, a switchboard. A switchboard is relatively easy to build. In fact, both Access 97 and Access 2000 include a wizard that automatically generates a switchboard.

That doesn't mean that it's a bad design. In some situations, it might be your best choice. Several of our clients are currently using applications that we've developed using a switchboard design and have no desire to change the user interface (or to spend the money to change it). It's been our experience that a switchboard is sufficient when a user doesn't navigate much within the application. As an example, we have an application where the users navigate to one form where they enter or edit information. Less than 10 percent of their time is spent moving to other forms in the application (for example, to edit a lookup table or generate a report). They don't need much more than a switchboard to meet their business needs. Since switchboards are table-driven, they're easy to maintain. The switchboard wizard automatically creates the Access tables that are used to generate the various switchboards used in your application.

The switchboard design has one subtle benefit in that it forces the users to close the form that they're working in before they can navigate to another form. For naïve users, reducing the number of forms on the screen makes it easier for them to use the system. Power users who can handle multiple open forms discover that by minimizing the form they can get back to the switchboard without actually having to close their current form.

There are limits to switchboards. The switchboards in Access 97 and earlier versions use macros, for instance. This limits the functionality that can be designed into an application. To a certain extent, we could get around these limitations by passing parameters in switchboards using OpenArgs, but it was awkward. The major disadvantage is that as your application grows in size, specifically in the number of different forms that a user might navigate to, the switchboard can become an unwieldy form of navigation. A switchboard that's created by using the switchboard wizard is limited to eight buttons on each form. Given that one of the buttons will most likely be used to return to the previous switchboard, you're actually limited to seven buttons. To support more than seven forms, the master switchboard has buttons that navigate to another switchboard that presents a maximum of seven more buttons. As the number of forms increases, the users are forced to memorize switchboard button sequences to navigate to each form. If the users mistakenly choose the wrong button when working through the sequence, they must back out of the switchboard to a point where they can navigate down the correct branch.

****

Command buttons on forms

Command buttons on forms are similar to a switchboard. The exception is that you're now able to use VBA and put more buttons on any form in your application in any manner that you choose. Command buttons on forms give you much more control over your user interface. The actual user sees little difference between a switchboard and command buttons on forms. The programmer sees a big difference: Each command button requires code. An example of command buttons on forms is shown in Figure 2.

Although this approach is very similar to a switchboard, you can place as many or as few command buttons on the form as you like. You can also vary the style and appearance of each command button and cause a variety of activities to occur—you're not limited to just opening another form (depending on how much time you want to spend coding the events behind each command button). It wouldn't be too difficult to develop some standard navigation forms that could be imported into each application and then customize the code behind these forms to meet the specific needs of each application.

However, like a switchboard, the command-buttons-on-forms approach can get complicated as your application grows in size. Unlike with a table-driven switchboard, maintenance costs can be high since every button is different.

****

Drop-down menus

Although we'd considered using the command buttons on forms as our standard of navigation, once we discovered how easy it was to integrate navigation into the standard menu, we adopted that as our standard. And, because of the ease with which we could implement a form of application-specific security using drop-down menus, we adopted them as our programming standard. All of our applications are now developed using drop-down menus.

Our design approach is to add our menu items to the existing menus that are provided in Microsoft Access. In fact, in many of our applications, our users still rely on some of the built-in features of the Microsoft Access menus to perform some of the business functions in their applications. In essence, we create an application-specific menu that includes all of the normal menu items and then add our menu items to that menu bar.

As an example, one of our applications included functionality to create a plain text file that could be sent to a printer to produce a directory. Instead of trying to completely automate the process, we created a report, print-previewed it to the screen, and then, in a message box, told the user how to use the menu features already built into Microsoft Access to create the final text document.

There's a possibility that leaving some of the built-in items from the Microsoft Access standard menus can lead to problems, but in our experience, these problems have been relatively minor and easy to solve. For instance, the most frequent problem occurs when users have some information on a form that they want to print. With the form open on the screen, the user selects File | Print from the Access menu and is disappointed when the information is printed using the form on the screen instead of the Microsoft Access report format. Although one solution to this problem would be to remove the Print option from the menu, our solution has been to place a print button on any form where we anticipate a user might want to print some information. This print button prints a Microsoft Access report that's based on any filter settings that might have been selected on the form.

****

Toolbars

There's not much to say here. Toolbars and menus are, as you'll see, almost identical. The major difference from the user's point of view (which is what matters in user interface design) is that menus consist of text items ("File," "Print," "Undo") while toolbars can contain any combination of text, buttons, and other controls.

Implementing drop-down menus

Since we decided to use drop-down menus, it makes sense to show you how to create menus. This section is in no way a full discussion on the Command Bars collection (which is what a menu is) or any of its objects. It's meant to give a basic introduction on how to create a basic custom drop-down menu. There are many ways to create custom menu bars and controls, including with Visual Basic. For further information, the Microsoft Knowledge Base Web site is a good place to start: http://support.microsoft.com. However, unless your menus are going to change dynamically, the simplest way to create your menu is to do it through Access's user interface.

The process for creating your own custom menu is relatively straightforward. You need to be familiar with these items:

  • Command Bars collection: A collection built into all of the Office applications that contains menu bars, toolbars, and shortcut menus.
  • Menu Bar: An object in the Command Bars collection that contains menus and sub-menus.
  • Menu: Items on a Menu Bar that are used to organize all of the items on your menus.
  • Sub-Menu: Items below a Menu providing another level of organization.
  • Button (or Command): An item on a Menu Bar that opens an object or runs code.

Microsoft Access provides a very simple GUI interface for creating and editing menu bars. First, right-click the mouse button on any of the existing toolbars to reveal the toolbar menu. Selecting Customize from the popup menu will produce the Customize window as shown in Figure 3.

To begin creating a custom menu bar, click on the New button under the Toolbars tab and give the new toolbar a name (see Figure 4). After the new toolbar has been named, it will appear as a small square on the screen (see Figure 5).

Now that a new toolbar has been created, it needs to be populated with the application's menus. It's easiest to add pre-existing menus and buttons to the new toolbar before adding any of your custom menus and buttons. To add existing menus, just click on the Command tab of the Customize window to reveal all of the available menu items (see Figure 6). The Commands tab contains all of the menu items that can be added to toolbars. This includes the items on the standard Microsoft Access toolbars, all existing forms in the database, and all existing reports in the database. Any of these menus and commands can be added to the new menu by simply dragging and dropping them onto the new toolbar. Figure 7, for instance, shows how to add a standard Microsoft Access View menu into a toolbar.

As I said, your custom toolbar isn't limited to standard Microsoft Access menu items. Commands to open forms, reports, tables, and queries are also available. First you need to add a new menu to the toolbar (see Figure 8) and give it a name. In Figure 9, I'm adding a command to open a form under that new menu.

After all of your menus and buttons are added, the next step is to rename the custom buttons so that they have meaning to the user. When you drag a form onto the toolbar, the caption for the button is the name of the form. The same thing happens whether you use a report or an ActiveX control. The button can be renamed from its popup menu.

After you've added all of the items to your toolbar, the next step is to transform your toolbar into a menu bar. A new Command Bar defaults to a toolbar when created and should be changed to a menu bar in order to allow it to show up every time the application is launched.

First, return to the Toolbars tab on the Customize menu and select the toolbar that was just created. Next, click the Properties button to get the dialog shown in Figure 10. From this screen, change the type from Toolbar to Menu Bar. Next, your new menu bar has to be set to be the default menu bar on startup. To do this, from the Tools menu, select Startup to get to the startup options (see Figure 11). To finish the process, select the name of the newly created menu bar from the Menu Bar combo box on the Startup window. Now the newly created menu bar will appear as the default menu each time the application launches.

Now that you know how to create a menu bar, you need a way to created those menus in a uniform, consistent manner from application to application. The standard layout for our menus is shown in Figure 12.

Our menu design philosophy is very straightforward: Menus open forms (forms are used for entering and editing information, performing additional navigation within a selected function, or opening reports). There are three required menus that appear in the middle of the menu (to the right of the standard Access Tools menu and to the left of the standard Access Windows menu):

  • Activities: This is the menu that gives access to the basic business functions in the application. This menu item is usually available to the main users of the application for functions like data entry, inquiries, updates, and so on. While the menu is normally called Activities, it can have a different name that does a better job of describing the activities available in the application. In some of our applications, this menu item is called Requests, Timesheet, or Assignment.
  • Administration: This is the menu where basic administrative activities can be found. These functions are typically not accessed every day and may only be accessed by a limited number of people.
  • Reports: This is the menu item where much of the reporting is found. Although some reporting is available from forms reached through the Activities menu, the Reports menu is the most direct access to the application's reports. Everyone or a limited number of people may access these functions.

Each of these items is customized based on the specific needs of our clients. We don't impose this format if it isn't appropriate. If there are menu items that don't fit in these groups, new menus can be added (see Figure 13); if we can apply a more specific name than just the general-purpose "Activities," we do (see Figure 14).

Another advantage that we found with using drop-down menus is that we could implement a form of application security. In many cases, we've found that our three different menu groups would be accessed by different individuals (security groups). With a little additional programming, we can turn on or off, hide or unhide, gray out or not, the various items in the menu depending on which user is using the application.

As contrasted to the Activities menu items, the Administration menu items tend to be used less frequently, and by a more limited number of users. The types of functions that are to be placed behind this menu include:

  • Basic application configuration functions: This includes items like database locations, license expiration extensions, and other configuration items.
  • Table maintenance: Entry and editing of the basic lookup tables that are used by the application.
  • Other elements of the business function that are only performed by a limited number of people, or are less frequently performed.

They don't call it "trial and success"

How did we arrive at the design guidelines presented here? Simply by making mistakes and learning from them. We'd developed four or five applications and used our experiences to develop these design guidelines. Our navigation design revolves around having some of our navigation handled by menu items and the rest handled from Access forms. This article has given you the opportunity to learn from our mistakes. More importantly, you've seen how looking critically at a particular topic can help you create your own standards.

To find out more about Smart Access and Pinnacle Publishing, visit their website at http://www.pinpub.com/html/main.isx?sub=57

Note: This is not a Microsoft Corporation website. Microsoft is not responsible for its content.

This article is reproduced from the September 2001 issue of Smart Access. Copyright 2001, by Pinnacle Publishing, Inc., unless otherwise noted. All rights are reserved. Smart Access is an independently produced publication of Pinnacle Publishing, Inc. No part of this article may be used or reproduced in any fashion (except in brief quotations used in critical articles and reviews) without prior consent of Pinnacle Publishing, Inc. To contact Pinnacle Publishing, Inc., please call 1-800-493-4867 x4209.