An Access Application: The Form’s the Thing

David Irvine

From your user’s point of view, forms are the heart of your application. Dave looks at what you should be considering when you create your forms and demonstrates a little-used UI design technique.

In my mind, one of the key features in any successful application is the ease with which users can enter, maintain, and extract information. If a system is constructed with an interface that’s difficult to use, then users will resist using the system to update and maintain the information in it, rendering information in the system useless. Using Access’s Forms Design tools, you can create effective, intuitive, easy-to-use forms that will even ensure that the data entered is correctly.

There are some fundamental design criteria for creating a good form that should be mentioned at the start of any discussion about form creation:

1. Have a smooth and standard flow through the form. Once you know the way that your users will receive their data, lay out the form to match. Since the standard business language in North America is English, and since English reads left to right, top to bottom, your form’s data entry sequence should normally be left to right, top to bottom.

2. Ensure that there’s sufficient editing on the data to make it difficult for the user to enter bad information. Never make assumptions about what a user will or won’t do. As soon as you say to yourself that no one is going to enter a department number of 123A452B23, someone will try. One word of caution here–don’t make it too difficult for the user to enter data. This will cause frustration, and, once again, users will resist using the system.

3. Provide as much help as possible. Use Access’s Help features to ensure that the user knows what to do with a particular field. Use Help text wherever possible. Where appropriate, control fixed entry fields (like Department Code) with drop-down boxes to show the user the list of available choices.

4. Finally, and most importantly: Give the user a simple and non-destructive way of getting out of the form.

Getting started

Some developers will complain that the Forms Wizard is limited (which it is) and will insist on creating forms from scratch. This method is fine if you’re doing a complex form, which might link several tables or views. For a standard input/inquiry screen, I let the system do the bulk of the work for me and then go back and edit what it’s created.

For my sample form in this article, I’m going to create a basic form to input the Employee table in the Project Tracking database I’ve been developing. I’ll start out using the Forms Wizard, and then I’ll step through how to improve the form. Finally, I’ll look at a simple but little-used technique for improving the overall feel and use of the form.

Starting with Mr. Wizard

After starting the Forms Wizard and selecting the table or query on which I want to build my form, I’m presented with a list of fields to select for display. When I’m doing a basic maintenance form (a form for entering new records or editing or deleting existing records), I tend to select all fields. Later, I’ll add or delete fields as I require them.

The Access 97 Wizard gives you a choice of four forms: Columnar, Tabular, Datasheet, or Justified. All of these have different attributes and can be classified by the number of records displayed and the flow of data:

The type of form that you select depends on what the form will be used for (data maintenance, inquiry, and so forth), and a lot on the preferences of the user and the designer. For this article, I’m going to look at a Columnar form.

The next choice that the Wizard presents you with is the form style. Styles control the background used in the form, the font, font attributes, and the color of the text and fields. The best thing that you can do here is pick one format and use it consistently throughout all of your applications. When you have a standard style, what’s different from one form to another reflects the real differences in functionality between the forms. With multiple styles, the real differences between the forms are lost in cosmetic noise. One word of caution, however. Some of Access’s styles are very busy and could confuse the user. My personal favorites are Colorful 1 and International.

Figure 1 shows the form for the Employee table as it comes from the Wizard. The Wizard produces a complete working screen, which allows the user to enter and display data.

There are several things that I want to add to this form (which will let me discuss some of the issues in form design). Specifically, I want to:

Managing command buttons

Command buttons should be used to implement frequently used functions specific to the form (see Peter Vogel’s article, "Six Rules for Effective Form Design," in the May 1999 issue of Smart Access for more on user interface design). Command buttons also tell the users what they can and can’t do with a form. In this example, I’ll add three command buttons to the form: Delete a Record, Print a Record, and Exit. Again, I tend to use the Toolbox Wizard to generate my code because it saves time coding and ensures a standard format for my code. A standard format for your code is as important to the developer who comes after you as a standard format for your forms is to your users. Figure 2 shows the form with the buttons added.

Here’s a trick question: What’s wrong with the buttons in this design? Give yourself points if you recognized that they’re in the wrong place. Buttons, at least for dialog boxes that conform to the Windows standard, should appear either along the bottom of the form or down its right-hand edge. The only time that you should have buttons close to specific text boxes is when they’re directly related to the text box. When a command button and one or more text boxes are related, they should be isolated from the rest of the form, normally by enclosing the text box and the buttons in a box.

Controlling data entry

The Department Number field on this form is required. The problem is that a user might know that Dave Irvine is an employee of Information Services, but not know that Information Services is Department 1. Provided that this screen isn’t going to be used for bulk data entry, the proper design here is a combo box that shows the department names and numbers and allows the user to select the correct one. Once selected, the correct department number will be inserted into the Department field of the Employee record.

Here’s an example of how Wizards can save you time but can’t do the whole job. If you use the Combo Box Wizard, it will walk you through the process of adding a combo box to the form. You’ll want to make sure, while the department number is saved to the table’s field, that it’s the department name that’s displayed in the list box and that the user uses to select an entry. No user of a general-purpose inquiry screen would regard a bare list of the department numbers 1, 2, 3, and so forth as useful. On the other hand, if this form was designed to be used for a bulk data entry screen in a function where the employee’s department number was known, you might not use a list box at all or place the department number first in the display.

As Figure 3 shows, I inserted the control between the Bill Rate and the Notes text boxes. Unfortunately, Access sets its Tab Sequence (the order it will move from field to field) according to the order that the fields are added to the form. As a result, if I tab through the fields on the form, the tab sequence will go from the Bill Rate, to the Notes, to the Delete, Print, and Exit buttons, and then to the Department. The Wizard makes no attempt to handle this.

At the start of this article, I stated that a good form follows some natural flow: Top to bottom is appropriate for most North American businesses. The logical flow for this form would be to go from the Bill Rate, to the Department, and then to the Notes text boxes. Since Access adds controls to the Tab Order as they’re added to the form, the flow currently skips over the Department and continues to the command buttons before it finally gets to the Department text box. To correct this problem, in Design View, click on the Details band on the form. Once the Details band is selected, click on View from the main menu at the top of the screen, and select Tab Order from the menu. Figure 4 shows the Tab Sequence dialog box.

On this list, cboDepartment is at the bottom of the list. To move it to the correct position in the list, click on the box beside the name cboDepartment and drag it up to memNotes. Access will insert the cboDepartment field in the list between lngBillRate and memNotes. Access will adjust the Tab Order of the controls to match this order.

One of the issues in creating an effective form design is creating a flow that moves from one form to another. One technique that’s often overlooked is to create multi-page forms. Multi-page forms have many benefits: They let you break up large amounts of data, suggest a process flow (do this, then do this), and are easy to implement. An alternative to multi-page forms is to use a tabbed dialog box. Tabs suggest a categorization of data rather than a process flow and are generally harder to implement than multi-page forms. The major limitation to multi-page forms is that they’re limited to a single table or query.

The easiest way to build a multi-page form is to design your form in two pages and then allow the user to switch back and forth between them. To do this, build your first form as normal and insert a Page Break (from the Toolbox) at the bottom. Add your second form underneath the Page Break. The two pages should be the same size, so use the rulers to guide you.

In my example, I’m going to move the Notes field to the second page. There are lots of design reasons that would require this: When the Notes field that doesn’t get updated often does get updated, it’s the only piece of the employee record that’s changed, and the amount of information that’s entered in the field would benefit from a larger display. I’ll also add the employee first and last name to this form to provide a visual connection to the first page of the form. Figure 5 shows the second page of the form.

As part of adding the second page, I moved the Exit button down to the form footer, so that it’s accessible from either page. In addition, I added two command buttons to move between page 1 and page 2. Moving the buttons down to the footer also brings the form layout in line with the Windows design guidelines.

To make all of this work, you need to create some code, but don’t worry–it’s pretty painless. Here’s the code for the button to go to page 1 (with IntelliSense, you only need to type six keys):

Private Sub cmdPage1_Click()
  Me.GoToPage 1
End Sub

Your user’s heart

From your user’s point of view, forms are the heart of your application. The more time you spend thinking about and designing your form, the easier it will be for the users to use your application, and the happier they (the users) and you (the developer, who probably has to maintain the application) will be.

Download FORM2.exe

Sidebar: A Complete Access Application