In this article, Peter returns to the problem of designing effective user interfaces for Microsoft Access. Peter provides you with six rules that you can use to avoid creating “interfaces that suck.”
For the April 1999 issue of Smart Access, I wrote an article on creating user interfaces (UIs) for your users (” Access User Interface Design”). In that article, I concentrated on the process you could use to ensure that that your application’s UI was one that met the needs of your users. In this article, I’m going to look at some specific rules that you can follow to avoid problems with your UIs. The goal remains the same, though, and is summed up in the first sentence of this paragraph: You must build “user interfaces for your users.” Far too many UIs are built for the application rather than the people who are doing the work. There’s a site on the Web (and now a very successful book) called “Web Pages That Suck.” This article will help you avoid creating “Access forms that suck.”
Where do standards fit in?
The first rule is to adopt a set of rules. You must adopt a set of standards for your UIs. While there’s some truth to the adage that “Standards must be wonderful things — look how many there are,” standards will save you and your users an enormous amount of time.
Standards save you time because they eliminate many decisions. Where should I put the Exit button? On the button, should I use a graphic or the word “Exit”? If I have a Cancel button, does it go beside, over, or underneath the Exit button? If your standards spell out the answers to these questions, then you don’t have to think about them.
Generally, there are two reasons that developers don’t like developing a set of UI standards. The first reason is that becoming familiar with the standards and referring to them while building an application is regarded as wasted time. It’s much faster, developers believe, to just slap up whatever they want. However, redoing your application’s UI is also wasted time. Arguing with other members of the team about what the right thing to do in the UI is wasted time. And if you deliver a poor UI, you waste even more of your users’ time. There are real benefits to being the person who pushes to adopt a set of standards. If it’s your standards that get adopted, it takes little or no time for you to become familiar with them (though you’re now going to have to be consistent about applying your standards).
Access can help you implement your standards. To begin with, Access’s forms implement many of the UI standards that are part of the Windows specification. Access also lets you set the form that you want to appear when you start designing a new form. To set your base form in Access 97, select the Tools | Options menu choice and click on the Forms/Reports tab. Once there, enter the name of the form that you want to use as the starting point for your development activities. Alternatively, you can just save a form with the name “Normal” (this also works in Access 2.0). You can also create a library of standard forms and import them into your applications as needed. If you really want to commit to automating your standards, you can use the information from Helen Feddema’s articles on creating wizards (see her “Wizards” series in the July, August, and September 1998 issues of Smart Access) to build some add-ins that will help you stick to your standards.
The other reason that developers don’t like to adopt standards is because they feel that the process of developing the standards will be long and painful. Recognize that you already have some standards and that, maybe, all you have to do is write them down and stick to them. There are also a couple of shortcuts to your own set of standards. You don’t have to develop your own, for instance. Microsoft Press has published The Windows Interface Guidelines for Software Design. This book describes (in detail) the standards that all Windows programs should follow for their UI. On the Exit button issue, for instance, you can go to page 194, where you’ll find a complete discussion on the layout of controls on dialog boxes. Where does the Exit button go? The book says, “Lay out the major command buttons either stacked along the upper right border of the dialog box or across the bottom of the dialog box. Position the most important button — typically the default command — as the first button.” Add a note that, in your application, buttons go in the upper right-hand corner, and you’re done.
Don’t be dismayed by the size of the book. The guidelines proper are only the first 400 pages, and much of that material isn’t relevant to Access developers (handling ink edit controls) or is taken care of by Access (manipulating the size of the form).
While standards save developers time, the real benefit of standardizing your UIs is that your users don’t have to learn a new, oddball interface every time they start one of your applications. A major benefit of using the Windows Guidelines book as your standard is that your programs will work and act like other major applications. To be blunt: It really doesn’t matter whether your standard is good or bad; your users appreciate consistency more than anything else.
By the way, even if you’re not concerned with UI design, the Microsoft book is a useful read. Things that I’d been aware of only on a subliminal level were suddenly made clear to me when the guidelines spelled them out for me. The Microsoft book isn’t the only game in town, either. GUI Design Essentials, from Wiley Computer Publishing, includes the book on CD so that you can customize it and print it out to create your own standards manual.
What you shouldn’t do
The second rule is to not worry about silly issues. One discussion that you can avoid concerns creating a “metaphor” for your application. If you’re using Access, the metaphor is already in place: Your users are filling out a set of forms.
Metaphors have a limited use in the design of computer systems at the best of times. A metaphor can help users understand how an application works by relating the new application to some old tool that they understand. However, this can be as much a hindrance as a help. If you establish that an application is “just like” something else (a Rolodex, a desktop, a file cabinet, the old system), then your users will expect it to work “just like” that other tool. When your application deviates from that model, even if it’s to add a new feature, then the metaphor makes it harder for your users to understand your application.
One thing to remember is that you’re not designing Graphical User Interfaces (GUIs). A GUI allows the user to perform activities by directly manipulating a graphical representation of the objects involved. If you want to change the size of a window, you don’t type in a command. Instead, you click on the window’s edge and change the size of the window — that’s direct manipulation. With Windows Explorer, if you want to move a file to a new directory, you click on the graphic that represents that file and drag it to a graphic that represents its new location.
Access ensures that you won’t be creating those kinds of UIs by imposing the form metaphor on your application. Instead, you’re creating WIMP interfaces: interfaces made up of Windows, Icons, Mice, and Pointers. Within Access, you’re really only concerned with two of those items:
- the layout and flow of your windows; and
- the icons that appear on them.
You also shouldn’t spend too much time designing icons. While it’s certainly nice if a user can look at an icon and instinctively tell what clicking on it will do, it’s a very unlikely event. If you do come up with some useful icon (a rabbit to indicate a short way to perform a task, a turtle for the longer method), in this multicultural world you can’t guarantee that your users will be familiar with your reference. In many cultures, the turtle is a sign of wisdom or fertility, for instance. Icons are merely easier to spot when scanning a toolbar than words are (and generally take up less space than the equivalent text). It’s important, then, that your icons be distinctive. Your ToolTips and documentation will tell your users what happens when they click on the icon. If you’re committed to having icons that are meaningful, then let your users select and design them.
The two most common problems
The third rule is to not overload your forms. The most common problem with forms is that they have too much on them. Without the scenario design methodology that I described in my April article, there’s a tendency to put everything that the user might need on a single form. A form should let the user perform a specific task they want, taking all of the usual defaults. A form shouldn’t be a “do everything” tool. If the user needs to override some default, that option should be on a separate form that they can go to as needed.
The fourth rule is related to the third one: Let the users do what they want. When the user asks your application to do something, don’t pop up a dialog box with all of the possible variations and options that the user could ever want. If the user wants to cancel an order, don’t, for instance, present them with a form that includes “Cancel,” “Cancel and Archive,” “Cancel and Hold,” and so on. Instead, provide a Cancel button on the form and a “Cancel With Options” menu choice. When the user clicks on the Cancel button, cancel the order. When the user wants to do something special, they can go to the menu choice. If you want to get very fancy, you can allow the user to configure what the standard Cancel button does. Again, Access can be useful here. That configuration information can be stored in a table of user preferences, in the properties of the database itself, or in the Registry with the GetSetting and SaveSetting commands.
The fifth rule is to use the right kind of form for the task. The second most common problem in form design is a mismatch between the basic style of the form and the task it’s being used for. Many business applications need heads-down data entry screens. What’s important about these forms is that they allow the user to enter large amounts of data quickly. Access’s continuous forms are great for this kind of task because they allow the user to enter an infinite number of records without having to open a new form.
What users don’t want in these forms is anything that causes them to take their hand off the keyboard to reach for the mouse. Users also don’t want to have to look at the screen to find out whether they’re at the end of the form or have to click on some button.
For data entry forms, you want to stay away from ComboBoxes, ListBoxes, and the like. Even Access’s searching ComboBoxes aren’t helpful. While these boxes allow the user to select an entry by entering a few characters, they require the operator to look at the screen to determine whether they’ve entered enough characters to select the entry that they want. I know this takes a lot of fun out of designing the form (you really, really, really, wanted to use an Explorer-type interface), but life’s just like that. On the other hand, audio cues when an entry is incorrect are a plus in this environment.
There are forms where you can use a variety of user interface widgets. Review forms are designed to bring up a single record (and any related records) to display their information or to make one or two changes. With these forms, the user will be looking at the screen in order to find the field that needs to be changed. The user will probably already have their hand on the mouse so that they can move the focus directly to the field that they want to alter. Here’s where you can use that Explorer-style interface.
Forms that are used infrequently or by users you can’t train (for instance, an application running unattended in a kiosk) can make extensive use of user interface widgets to help the user through the form. Here, however, you need to stick to those controls that are understood by the majority of Windows users: CommandButtons, TextBoxes, ListBoxes, and, perhaps, ComboBoxes. This isn’t the place to use the grid control with those neat UI features that no one but the development team is familiar with. Or the Explorer interface. Sorry.
The right tools
The sixth rule is to use Window elements for the purpose that they were intended. Before you can start designing a user interface, you need to understand the purpose of the various components of a Windows interface. All Windows interfaces share the common elements of menus, toolbars, and buttons. I think that the tab interface is becoming as important. If you’re going to use these elements effectively, then you need to understand the purpose that they were designed for and the way that they’ve been used in other Windows applications. Using one of these elements inappropriately gets in the way of your users understanding your UI.
Menus
Menus provide access to all of the functionality of your application (with the possible exception of activities implemented exclusively through CommandButtons on the forms themselves). More importantly, menus tell your users how your application works. Since your application will succeed only if it works the way your users think it should, menus should be designed in close cooperation with your users.
Toolbars
Toolbars are used to allow your experienced users a quick way to perform activities that don’t appear as buttons on a form. New users will gradually come to realize that they can save themselves time by using a button on the toolbar rather than navigating to the right menu choice. Since icons can’t tell a user what a toolbar button does, ToolTips are essential.
Buttons
CommandButtons are used to allow the user to start a common, important, and immediate task that relates directly to the current form. A task that isn’t performed often doesn’t need a command button on the form (put it on the toolbar). A task that isn’t important to the purpose of the form also doesn’t need a button (leave it on the menu).
Generally, your buttons should be placed together along the bottom of the form or down the right-hand edge and separated from the rest of the form. An exception is a button that relates to a specific area of the form and not to the rest. This button and the part of the form that it relates to should be placed in a box by themselves.
Tabs
Tabs let you segment a form’s contents into several distinct categories. Tabs let you place a large number of controls on a single form while only displaying a small number of them at a time. The key to using Tabs successfully is ensure that the contents of the form break down into distinct categories, each of which fits on a single tab.
Tabs don’t work when material covers two tabs (“Customer Information” and “More Customer Information”). Tabs also don’t work when their contents don’t relate to each other. Tabs labeled “General” or “Misc.” are no help to anyone. My favorite in this area are Tabs labeled “Advanced.” Who can tell what’s on an Advanced tab?
Misusing a tool
An example of misusing a tool is the tax preparation software that I’m currently fighting with. This package opens a form where Tabs are used to break up a process into a series of steps. While it might seem like a clever idea to put step 1 on the first tab, step 2 on the second, and so on, the result is confusion.
The confusion comes from a conflict between the process and the UI. The orderly process that the application is leading me through suggests that I first do step 1, then do step 2, and so on. Tabs, on the other hand, suggest that you can go to any tab at any time to look at the information being displayed. Users (like me) see Tabs as a way of providing access to discrete pieces of information. They don’t see Tabs as a series of actions to be performed.
Once the process is complete, Tabs would be an excellent design choice for reviewing the information that I’d entered. Tabs might also be useful in the initial process as a way to give me access to actions that are seldom required. Even then, I would have preferred a CommandButton that brings up a dialog box.
Where to go from here
I’m sure that you realized when you started this article that six rules couldn’t tell you everything you need to know about creating effective user interfaces. While I’ve provided some guidance, there are some steps that you can take to train yourself.
Start by looking critically at the interfaces that you interact with. Are there some tasks that you’re regularly doing wrong, having to start over, or getting confused while doing? Ask yourself how the interface could be redesigned to let you do what you want to. Watch your users working with your applications, and assume that everything they have a problem with is your fault and not a training issue. Train someone with no experience in how to use Windows. This activity, all by itself, will sensitize you to what issues are involved in using Windows. Read the Microsoft guidelines that I recommended at the start of this article to become fully aware of what the Windows conventions are.
I also recommend that you read About Face: The Essentials of User Interface Design by Alan Cooper, again from Microsoft Press. Alan Cooper designed the UI for Visual Basic and runs a software design consulting firm. I like the book very much, probably because I found Cooper saying a lot of the things that I believed (no one is as smart as the person who agrees with you). There’s stuff in the book that I don’t agree with, and it sometimes turns into an inventory of Windows UI conventions. But the book will make you think seriously about what you should do when you create your next user interface. And that’s the most important rule to follow.
