How to Choose an E-Form System

by Bruce Silver

One of the most basic axioms of e-business is that paper is eliminated at the source. There is no document capture or conversion. It's an online business process end-to-end, often starting with an electronic form. E-forms are becoming increasingly important to e-business application development, but they're just a piece of the solution.

So it's not surprising that e-forms specialists have become the latest wave of boutique technology suppliers to be swallowed up by bigger fish in the e-business food chain. Because of this, users are now confronted with content management vendors, process management vendors, portal vendors and Web site builder tool vendors all touting the superior power and ease of use of their respective e-form builder components. This can be confusing, especially if your solution needs all those technologies — content management, process management, a portal interface and a custom Web application — and looks to combine software from a specialist in each area in a single integrated solution. Which of those should provide the e-forms component? To answer that, you need to weigh the various functions the e-form is trying to provide for your e-business solution.

First, and most obviously, the e-form should provide a friendly, fast and convenient way for users to enter complete and valid data. The operative words are "complete" and "valid." Everyone is familiar with bad Web forms: the ones that make you fill out the entire page again if you forget to enter one required field or the ones that take ten seconds to update after each field is entered. Similarly, everyone has experienced the benefits of e-forms, like calculating totals, tax and shipping charges automatically.

But what about a form that enforces validation rules before pressing Submit? Such a form offers a much friendlier user experience, but it requires rules and data relationships to be embedded in the form itself, rather than in a post-submit form processor. Do the form-builder tools allow the application designer to do this easily?

Sometimes, data validation requires a database lookup. Is the account valid and in good standing? Is the item in stock? Such rules require some component on the Web server to perform the lookups and respond if necessary to the user. Forms often require a search based on partial criteria, and the available choices must be presented to the user in a convenient way. Online travel sites have made huge progress on this in the past year. If such functionality is important to your application, you need to ask if the form-builder tools also take care of this. Does the system provide point-and-click connectivity to the needed back-end data sources? Does it provide the user with a convenient way to format search results? How much is built into the form tool and how much is custom code?

Once the interactive form filling is complete and validated, a formatted "document" often needs to be presented to the user for final approval. This is what you ordered or requested, and these are the terms and conditions. Do you agree? Acceptance, perhaps with a digital signature, should have the same legal weight as a signed paper form. This document or confirmation should be printable by the user. Again, such functionality may or may not be provided by the e-forms component. Historically, e-forms vendors have put a lot of emphasis on printing a paper record, often with high fidelity to the format of standardized paper forms.

Next, once the form is validated and approved by the user, it is passed to the "back end system." In some cases, that means direct update of a transaction database. In many other cases, however, the form data, maybe even the form itself, is routed for additional lookups, manual checks and approvals in some sort of workflow process. Only after the workflow is complete can the form data update the transaction database. The relative importance of such a workflow process has a direct bearing on the selection of the e-forms technology. Some vendors look at the form as a data container for workflow, while others simply view it as a simple user interface and preprocessor for a transaction database.

The range of functionality of the e-form component is thus potentially very wide, encompassing user engagement and convenience, pre- and post-submit validation, submitter approval, print formatting, workflow processing and connection to a variety of back-end data sources. Your principal guideline in choosing an e-forms product should be just how the functionality you need divides between the e-forms supplier's built-in tools and the custom code you must write. The implications of that division will be magnified as e-forms take on an expanded role for e-business in your organization.

Bruce Silver (brsilver@earthlink.net) is president of Bruce Silver Associates, Aptos, CA, 831-685-8803. Reports are available at www.brsilver.com.