Creating form designs for the Forms service

Behavioral differences exist between form designs that are used to render PDF and HTML. Form designs rendered as PDF are viewed using Acrobat or Adobe Reader.

If you are rendering a form as HTML, some client devices (for example, older browsers) do not provide the same support level for individual object properties. To create a single form design that reduces these limitations, follow this process:

  1. To determine how objects behave in a particular client device, see the Transformation Reference.

  2. If you are designing a form with a fixed layout and want to output the form as HTML, enable transformation caching. (See Designer Help.)

  3. When creating a form design, try to work around limitations by finding ways to implement the form without relying on unsupported object properties.

  4. If required, include a layout that works for both PDF and HTML.

  5. Read "Creating Accessible Forms" in Designer Help and use the guidelines to build accessibility into your form design.

  6. Ask your form developer where scripts should run. By default, scripts run on the client. If the scripts you include in a form design must run on the server, or both the client and server, you may have to change the default setting. For example, a form design may contain a script that extracts data from an enterprise database that is available only on the server. In this situation, the default setting must be modified so that the script runs at the server.

  7. Periodically preview the form by using Designer or the client device (for example, a web browser) to troubleshoot problems early in the design process.

  8. If the Forms service will be prepopulating forms with data, use test data to thoroughly test your form design.

    For the Forms service to retrieve form data, perform calculations, or validate field data, the form must provide the mechanism to initiate the request. This is typically accomplished through the use of buttons located on the form design. The caption that is displayed on a command button label indicates the function of the button to the end user. When a user clicks a button, the form-related processing is prompted by the script that is associated with the button. Typically, a button initiates either a submit operation or a calculate operation.

    Buttons are the most common way to initiate logic that is contained in form design scripts. Placing a button on a form design in Designer and configuring its submit option implies a submit operation. The intent of a submit button is to complete the form and submit data to the Forms service. However, validation operations may interrupt this process. For example, if a user enters an incorrect value, the user may have to correct the value before the form data can be submitted. Placing other button types on the form implies a calculate operation. The intent of a calculate operation is to run calculations and update the form before a submit operation.

// Ethnio survey code removed