Re: Form Design Theory

**
_at_home was having a lot of trouble with their news servers the other day, and as far as I know, this didn't get delivered, I hope it is not a duplicate message.
**

I think the forms should be a natural outgrowth of a normalized data model. By this I mean that a form should never have an m:n relationship, and I would generally not put more than one 1:m relationship on a single form. In general, look at the logical model and make a form for each independent entity. For each dependent entitiy make a form where the parent entity information is in the header section of the form, and the child information is in the table section of the form. If you have a single parent entity with multiple child entities, put the info for each child on a separate tab.

This approach makes more forms, but each form has a specific purpose. I've found that people who actually use the systems like forms that are designed this way, because everything is well organzed. Sometimes the management wants the "do all" form, but they aren't actually running the system day in day out. Often the executives or owners need comprehensive reports that can be produced with a join of the required tables. By all means, show the owner what s/he wants, but don't force the users to live with the "form from hell" that attempts to do everything.

I think that its useful to look at interface design in industry for clues. Calculators that have 2nd and 3rd functions for each key are not as fast to use as calculators that have dedicated keys. Even in the cases where 2nd and 3rd functions are necessary because of space considerations (e.g. scientific and financial calcualtors), the most important and commonly used functions get their own keys.

So how do you answer the often heard argument that "I want system that is simple to use, and that means fewer forms"? I often answer with the following illustration:
How would you like to use a keyboard that only had half the keys of your existing keyboard? Each key could produce multiple letters. For instance, you could get either an 'A' or an 'S' from the same key depending on if you held down the control key. Of course, everyone thinks that is a lousy idea, and it is.

How about this example: Would you go into a factory and say "This shop floor is too complicated, there are just way too many bins for the storage of raw materials messing up the floor. We're going to simplify by getting rid of all 100 bins and replacing them with one large bin." The floor would be less complicated from the standpoint of having fewer bins, but the one bin that is left would have to hold all the parts and be a huge mess.

Everyone agrees the all purpose bin in the factory is ridiculous, but that is exactly what many people want to do with database tables and application forms. The bolt bin should store only bolts, and the angle iron bin should store only angle irons. By the same token, the Customer table should store only Customers and the Employee table should store only employees. The forms that manipulate this data should also be dedicated to a single purpose.

So here are the major benefits of single purpose forms: 1. They are generally easier to use for day in day out users 2. The form performs faster because the code behind it is simpler. A fast keyer can outrun a slow form, which is very frustrating for users, and bad for business efficiency.
3. Because the forms are organized, it is easier to train new users on the system.

A side benefit is that the single purpose forms are generally much easier to code, document and maintain.

Thanks,

Bill

"Adam Steiner" <ajsteiner_at_aol.comnospam> wrote in message news:20011118004115.08692.00000373_at_mb-cs.aol.com...
> Hey,
>
> I'm developing a program for my father's real estate law office. He
wants the
> primary form to contain ALL of the information that has to be entered on
one
> long form that you use to scroll down (he has his valid reasons for doing
so).
> However, I'm also developing this product for law offices in general (a
number
> have expressed interest) and I think that this method of having all of the
> information on one form (vs. having tabs on that single form) is a bit
> unordered. Is there a standard way of designing forms - perhaps a rule
that
> says forms should not take up more than one screen in length (and
therefore
> need the scroll down option?).
>
> Thanks,
> Adam
Received on Sun Nov 25 2001 - 05:41:02 CET