Minimizing the Memory Load

People aren't particularly good at remembering things, which is one of the reasons we use computers. It follows that a good user interface doesn't make users remember any more than is absolutely necessary. Obviously they're going to have to learn (and remember) what your system does. And they'll need to remember some things about how to use it. But you should minimize the amount of information users need to remember wherever possible.

One approach is to comply with Windows interface standards and conventions. The Windows Interface Guidelines for Software Design gives one a set of conventions. You will rarely have a reason to change them and shouldn't do so arbitrarily. The Microsoft Office products—in particular, Access—set other de facto standards. If you vary from the standards, make sure you have a good reason. Otherwise, you probably aren't doing your users any favors.

You might think that your navigation widgets are much cooler than the default video buttons provided in Access. But pity the poor users. They've learned to press the button to move to a new record. Now you're making them remember that in your program they must click on that incredibly cute photograph of your cat having kittens.

Of course, the Windows interface guidelines only go so far, and they don't cover all situations. In most cases, you'll be able to extend the general guidelines to cover the specific situation you address. Where you do have to make decisions, stick to them. We'll talk about the importance of consistency in the next section.

It should be obvious that if you're trying to reduce the amount of information a user has to remember, you should never make them enter the same information twice. We've talked about the use of default values in this situation. You'll also want to make sure that you carry forward any relevant information if users must work through a series of forms.

Furthermore, users should never be asked to enter information that could reasonably be selected from a list. Computers are notoriously picky, and users shouldn't have to worry about whether John Doe's Customer record was entered as "John Doe", "J. Doe", or "J.C. Doe". But note that I said "reasonably." Asking a user to wait while the system fills a combo box with 65,000 records is not reasonable. What is reasonable is providing them with a means of filtering the list and then picking from a manageable subset.

When you do present lists to users, include as much additional information as possible, particularly if the list items are not necessarily unique. Users shouldn't have to remember that "John Smith" is the one who lives in Madrid, while "Johnny Smith" lives in Milan. Microsoft Access list boxes and combo boxes allow you to show multiple columns of data. In Visual Basic, you can concatenate the relevant fields.

In both environments, consider displaying subsidiary information by means of a context menu. Technically, the display should be by way of a command, such as "Details", on the context menu. (Note that there is no ellipsis following the menu item, even though it displays a dialog box. Including an ellipsis is a common error.) However, if the details are short, you might want to display them directly in the context menu. This saves users a little time.

Finally, users should never be forced to remember obscure coding schemes. You might be using a system-generated number to ensure uniqueness of a record, but in most cases users should be unaware of its existence. Unless the number has some objective use like an invoice number, don't even display it.

Many organizations have developed lists of abbreviations representing things like product categories or sales regions. The rule I use to decide whether or not to use these abbreviations in the system is whether they're used in casual conversation. You want to avoid a situation where people talk about "the Southwest region" but have to enter "SWR". Only if they use "SWR" in conversation should it be used by the system. Even then, I would probably allow entry of both "SWR" and "Southwest" in the region field.



Designing Relational Database Systems
Designing Relational Database Systems (Dv-Mps Designing)
ISBN: 073560634X
EAN: 2147483647
Year: 1999
Pages: 124

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net