Designing Outlook Forms

The promise of the paperless office still seems a long way off, but I see steady movement toward replacing paper forms with electronic forms. In fact, I'm just starting a project to create a set of second-generation electronic forms for a company that's migrating to Exchange 2000 Server from another mail system that had rudimentary forms capability. We're trying to build on what my client liked about its old forms--especially the live view of everyone's projects--and use Outlook forms to duplicate the functionality and, hopefully, add a few enhancements.

Going over the company's requirements, I highlighted several considerations that are part of any Outlook forms project. The first question I always ask is what Outlook version and service pack (or versions and service packs) the organization is using. You can generally assume that you'll be using a version of Outlook that includes the Email Security Update, which triggers prompts on certain properties and methods, but you might encounter a case in which an organization refuses to go beyond Microsoft Office 2000 Service Pack 1 (SP1) just to avoid the security features. The various Outlook versions have some subtle differences, so your form-testing environment should mimic the production environment as closely as possible.

The drop-down list is a common element on many forms, so I ask where the items in each list should come from. For short, static lists that haven't changed in 3 years, hard-coding the list into the form is probably OK. For longer or more dynamic lists, should the form build the list from data in an Outlook folder or in a database? Do users need the ability to add new items to the drop-down list and have those items appear the next time they use the form? I've worked with companies that wanted the drop-down box to show a list of the last entries used for that property, similar to the most recently used (MRU) lists that many Windows programs use. In that situation, you need to know whether the MRU list should be global--gathered from all users--or specific to each user. If user-specific, you must find out whether the users move between machines so that you can make sure that the list travels with the user if necessary.

A second-generation form gives you the opportunity to learn from the first-generation form experience. Perhaps some form elements didn't work as well as anticipated or didn't hold up well over time. Designing a new form gives you a chance to ask--for each form element--what users find helpful, both in the design and in the information collected.

One of the advantages of moving from paper to electronic forms is that you can more easily use color to emphasize areas that deserve special attention. In my current project, for example, key deadline date fields have red highlighting. Ask which areas of the paper or first-generation electronic form are most important and which seem to be the most difficult for users to fill out correctly, and pay special attention to those areas.

Something else you can do with electronic forms that you can't do with paper is enforce business dependencies and rules. You might want to require entries in certain fields, or the valid choices for field B might depend on the user's choice for field A. For example, the old forms that I'm converting allowed an entry of ASAP for the due date. On the new Outlook version of those forms, users must enter an actual date.

Finally, most organizations will need a printed version of the electronic form, so I give my client some ideas about how we might arrange on the printed page the information found on the multiple tabs of an Outlook form. Thinking through and coding a paper version means a little extra work with Outlook forms because they don't have any built-in support for WYSIWYG printing, but being able to produce a good-looking printed view of the data can be crucial to selling users on the electronic version of the form.

Thinking through design points such as the ones I've mentioned will help you design effective Outlook forms. You can also apply these considerations to other kinds of electronic forms your organization might design: Web forms, forms for use with third-party tools, or forms that use the new InfoPath program in Office 2003.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.