Considerations when building an electronic form (eForm) solution using LiveCycle - Part1

This article is intended for those who are interested in migrating your existing paper based processes over to an electronic one. I will go through some high level considerations in finding the right solution.

1. PDF or HTML?
Are you interested in implementing a pure PDF solution or one that includes both HTML and PDF? LiveCycle Forms allows multiple output formats (PDF, PDF Form, HTML, DHTML, AHTML, etc) to be generated from a single template (.xdp) created from LiveCycle Designer. The caveat is that the scripting behavior is different between the HTML and PDF, resulting in scripts that has to be coded into the templates. Unless there's a significant requirement to continue to support HTML based forms, I would stick with PDF Forms.

2. When is HTML Form an appropriate output from LiveCycle Forms?
Scenario 1: If the PDF form is very long (5-10 pages), I sometimes use HTML Forms to capture data, in a multiple step wizard. This breaks the long time into a sequence of smaller and more focused forms for the user to fill out.

Scenario 2: Use HTML Forms when screen real-estate becomes a high premium (within a portal, within LiveCycle Form Manager)

3. Requirements to archive the PDF?
Do you have existing requirement to archive the PDF that the user submits? If yes, then the submit type needs to be either XDP or PDF. This is done at the form design stage. Note, to support this capabilities using Adobe Reader, the PDF needs to be reader-extended first. (Product: LiveCycle Reader Extensions)

4. Requirements to use digital signature?
Are you planning to support digital signatures in your PDF Form? If that's the case, you should be aware that an existing PKI infrastructure and/or support for roaming certificates / id needs to be there to associate and identify the signing party. Also, if digital signatures are required, the submission type (of submit buttons on the PDF) has to be an XDP aor a PDF.

to be continued..

Gmail on the desktop? Sign me up!

Leslie at jinsync.com released an apollo gmail app that showcased how easily existing AJAX application can be wrapped and deployed onto the desktop. The concept is very simple, use the HTML capabilities within apollo sdk to wrap around an existing web site. Many will say, "so what? I can just bookmark gmail using my browser, and place a link on my desktop as well." Now, look at apollo's documentation. Offline capabilities support within the SDK. Add caching and offline capabilities onto the existing AJAX-based gmail, and you will have a powerful desktop emailing tool without significant rewrite of the entire code base.

Google, pay attention. With Apollo, gmail can be a desktop email client that is cross platform, based on the same code base as the existing web version, and ready to be deployed within a couple of weeks.

Apollo is released on Adobe labs!

Apollo has been released on Adobe labs at http://labs.adobe.com/technologies/apollo/ ! Get it while it's hot. For those of you who doesn't know, Apollo is the code name for cross platform runtime from Adobe, that allow developers to use familar web technologies (flex, ajax, css, html) to build compelling rich client applications.