Data collection options

[Former Community Member]

TL;DR

What are the available data collection options when designing forms in LiveCycle?

Background:

I am investigating all available data collection options in XFA forms made using LiveCycle. The preferred user experience would be to save a form locally and be able to revisit the form and edit their data (i.e. not printing to a PDF). Also acceptable would be the ability to export form data as a text/csv/XML file and later have the ability to import the data into a blank PDF.

I have recently spoke with an Adobe representative regarding Reader Extensions and LiveCycle server, however the implementation cost is prohibitive when considering the number of forms we need to produce (prohibitive in the sense that a web application is more cost effective to develop and maintain than the per form cost + maintenance fee for reader extended forms). So before we jump the proverbial Adobe ship, are there any additional data collection options I am overlooking?

Things I've investigated:

• The aforementioned Reader Extensions/LiveCycle Server
• xfa.host.exportData (it appears this requires a form to be certified, however the documentation for which is fragmented to say the least. Any resources here?)

Thanks!

[radzmar]

With Acrobat Pro you're able to Reader-enable your forms too, but in a limited way. The question is, how many users will use your forms finally and do you want to collect the data somewhere?

Reader Extensions enables forms to allow things in Reader you otherwise can only do with Acrobat (save, import data, export data, attachments …).

Acrobat enables forms to allow a few things in Reader you otherwise can only do with Acrobat (save, export data via mailto).

Here's a matrix that explains it:

Using LiveCycle Forms in Acrobat and Reader | Assure Dynamics developing dynamic LiveCycle and Flex ...

[Former Community Member]

The project involves 80-100 forms with several thousand users each (essentially transitioning paper forms to a digital format). The data does not need to be collected into a central repository, the feature I am pursuing is merely to enable end users to be able to enter data into a form and persist that data in some way that they can access and edit it. After the user has completed the form, they may print to a static PDF prior to submitting; it is no longer required to be editable at that point.

This feature is intended to improve user experience on longer forms that may not always be completed in one go. The user can not be expected to have Acrobat.

Thanks for the reply!

[jnicholas330]

If you are looking for a turnkey solution, then the products you mention will work. However, if you are willing to build some components yourself, you can accomplish most of what you want without cost. Without reader extensions you cannot save a filled PDF, however, you can submit your XML to a server. That same XML can be used to be imported into a PDF, using a "turncoat" XDP.