1. eForms design

General best practices

Use standard naming conventions for fields so you can utilize the global fields library. For example, all date related fields end with the suffix _dt, phone number fields end with _phone, address fields end with _addr, etc. If you plan to integrate your eForms with an external repository, it is recommended to try to keep the names consistent there as well. For example, if saving documents/data to Laserfiche, keep the field names consistent with the Laserfiche template field names.
Early on in a new eForm set all the field types first before diving into calculations, lookups, etc. Be sure to press save after setting all the field types.
Make small incremental changes to existing, stable eForms. For example, make a small change (like altering a calculation), test that it works as desired, and then save the changes. Then move on to other changes (if necessary). Alternatively, use the export/import feature to work on a copy of the eForm without having to worry about breaking existing functionality.
When editing eForms, it is recommended to use Firefox 9+, or Google Chrome 16+. This is because these browsers have very fast Javascript engines, and it is very Javascript-intensive when editing eForms.

Note the file size of PDF source documents prior to building eForms and then just before rolling them into production. It is not unusual for a PDF over the course of many small edits to continuously grow in size. The bigger the PDF, the longer it will take to process, and the longer it will take users to download, view, and possibly sign. A PDF can be shrunk by printing the document to a new PDF, and then copying the fields from the large document to the small. If the source doc is a scanned PDF there is an option in Acrobat to optimize the scanned PDF, which works well too. In one recent example, the former method was used and it shrunk the PDF from 2.2 MB to 300 KB.

This page was: Helpful | Not Helpful