This is the data entry form for an Access 2.0 database containing the Novell 3.x and 4.0 servers for Key Services Corporation and their corresponding parent organizations and administrators which I created in 1994 and maintained until 1997. In the time this was considered a great improvement over the character based green on black mainframe data entry screens. The user could tab from field to field, use the mouse or key combinations to press the buttons, and proceed fairly rapidly from entering new data to updating or deleting existing data. This was also the way many Visual Basic 3.0 to 6.0 application forms looked in the mid to late 90s.
Then the Internet came on full steam, and web usability became more of an issue. Many sites continued, and some still do, to use web input pages that look like these old Windows 3.x forms. They demonstrated these problems:
- Users were forced to scroll right many times to view and fill in any input fields to the right. If these fields off to the right were required fields, it was usually harder to find them if the page failed to submit.
- Many times buttons were used instead of links to open up new browser windows (which is an outmoded practice in itself) or to navigate to a new page.
- Unrelated data fields were often on the same page, and sometimes not even grouped separately.
- Pages which had a lot of data entry fields would take longer to post the data to the server.
- The pages often did not have an apparent logical grouping or flow to the input fields and labels.
I believe that one of the reasons why pages designed according to this outmoded idiom persist and continue on some sites is that these pages are designed by business analysts who have not been trained in contemporary web design. I’ve seen this enough to believe that it’s not a problem restricted to one corporation.
Here is a more common way in which data entry forms are done on contemporary web pages. It’s so common that users practically do not have to think when they see a form like this. I’ve worked with web pages that follow this general pattern since 2000, in classic ASP, and it’s a more common and usable idiom on the web.
| First Name | First Name Text Box |
| Middle Initial | Middle Initial Text Box |
| Last Name | Last Name Text Box |
| Address 1 | Address 1 Text Box |
| Address 2 | Address 2 Text Box |
| City | City Text Box |
| State | State Dropdown List Box |
| Zip | Zip Text Box |
| Submit | |
Here are some general guidelines for business analysts prototyping data entry forms/pages:
- Understand whether the data entry forms/pages are to be done in Windows or Web.
- Windows data entry pages should be prototyped with the print orientation set to landscape if the prototypes are done in Word or Powerpoint.
- Web input forms need to be prototyped with the print orientation set to portrait if the prototypes are done in Word or Powerpoint.
- Learn which input controls are appropriate to the type of input (checkboxes, radio buttons, list boxes, and dropdown list boxes).
- Document the correct text tooltips as well as field labels. Both web pages and Windows forms can implement tooltips, and they form a very handy way to provide immediate help to the user.
- Go over the prototypes with an architect or senior developer.
- Avoid complexity in one form or page; seek to have one form or page handle input and updating of one set of data and have it do that well.
- Be flexible and cooperative with developers if they suggest changes to the prototypes when they are actually implemented. The developers are the first users of the prototypes, and they can often make very constructive suggestions.
- Consider getting and reading the book Paper Prototyping by Carolyn Snyder, and going through a paper prototyping process to investigate usability before any kind of implementation is started.