Legal
The views expressed in this blog are my own and do not necessarily reflect the views of Adobe Systems Incorporated.
Search
July 7, 2006
LiveCycle, PDF and Open Source
A few blog entries ago, I explained why I thought the release of Flex was good for open source developers. One of the comments, from Will Pollard, asked for clarification on how LiveCycle fits with Flex and open source. In particular, why would someone use LiveCycle as opposed to any of the free PDF creation tools that are out there.
To start with, LiveCycle is a bit more difficult to access than Flex... Unlike Flex, you cannot download trial versions of the Adobe LiveCycle server products. (You can download a trial version Adobe LiveCycle Designer and start building out PDF forms.) Currently you need to be a member of the Adobe Enterprise Developer Program to download the LiveCycle software, including the very easy to setup LiveCycle Toolbox. (The toolbox is a pre-confirued install of all the LiveCycle software. For an explanation of LiveCycle, check out this Breeze presenation I did for Adobe Developer Week.)
We do want to make LiveCycle more accessible to developers.
To understand how LiveCycle competes with open source PDF creation tools, its important to understand that there are two types of PDF documents: what I call static PDF documents and dynamic PDF documents. Static forms are created in Acrobat, and are sometimes referred to as "AcroForms". The PDF file is static (it does not grow or shrink in size), but in Acrobat or Adobe Reader it may contain interactive elements that people can fill out electronically. For example, if you had an invoice, you would create the template with a set number of rows, and then hope that someone didn't order more items than the number of rows on the document.
On the other hand, dynamic PDF forms can grow or shrink in size depending on the data that is bound to the form. So, say you have an invoice for products, it could be 1 page for 1 customer, and 10 pages for another customer who orders a lot of items. To build that, you use LiveCycle Designer and create a PDF form, then use LiveCycle Forms to bind the data (likely in XML format) to the form. Most of the free, open source tools out there do not handle this type of PDF document. In fact, I haven't seen any solutions that do this, other than the Adobe LiveCycle set of products.
So, the question now becomes how does Flex fit into this? The idea is that you would use a Flex front end to gather data, likely on a website. At some point, you may want to continue filling in the form offline, or send the data to other people. When the time comes to take that data offline, you pass the data to a PDF form (which was created with LiveCycle Designer), and then users are able to access that data in a PDF document. They can send it to friends, do offline collaboration etc... When the time comes to send the data back to the organization's servers, a user would hit the submit button in the form and the data would be sent back to LiveCycle Forms, which will extract the data from the PDF form and allow the organization to process the data.
Once the data is in the PDF form, there are other LiveCycle pieces that may be of use as well. Digital signatures, policy protecting that information, managing the form's workflow are all services that the LiveCycle set of products provides. In the above example, I've focused only on taking the data off line, but once it is off line, the other LiveCycle products add additional functionality to the document / form.
technorati tags:livecycle, adobe, opensource, acrobat, flex
Blogged with Flock
Comments
However, Designer ends up not working too well if you aren't living in a windows world. I'd like to see Adobe fix that, but ever since, well, Acrobat 5 really, it's been pretty obvious that the non-windows Acrobat users are not going to be able to fully participate in the creation side of the future of Acrobat and PDF.
Mike,
Thanks for explaining this. I still find it quite disturbing though as someone who imagined LiveCycle would one day be priced at a level most people would find possible.
If FLEX is available to try out, presumably people at Adobe believe there is a future in this. LiveCycle is still only promoted to a few large organisations at very high prices. (I am guessing at this based on what I know in the UK. If I am way wrong, please let me know.)
You are suggesting FLEX rather than PDF forms as web design. So I'm not sure why many sites will go to LiveCycle as well.
I realise you can't reveal too much about new products but the capability of PDF to work offline is suggested to be similar to 'Apollo', available sometime. So the future seems much more FLEX than PDF. Unless PDF is a container for Flash.
My conclusion at the moment is that I shall just continue looking at LiveCycle as a world of inspiration which will one day arrive in other forms.
I don't understand the need for pdf forms at all. To me, pdf is good, very good infact, for one thing, and one thing only, output. If I've got a website that requires input, I'll use some sort of form, whether its html, flex, flash, but not pdf. If I want to display data on the application, its going to be, once again, in html, flash, or flex. I'll generate a pdf form if the customer wants to print it. I know Adobe is trying to make pdf do everything, but lets keep it real and use it for what its really good at being.
Will:
I think people will go Flex for the web input side of things, then LiveCycle for the PDF / off-line type of things.
Having a document of record enables many things that you can't get with Flex, even with Apollo (which will probably give you offline capabilities similar to what PDF gives you now)... But, LiveCycle will add digital signatures to certify documents (LiveCycle Document Security), enrcyption of PDF documents (LC Document Security), policy protection of documents (LiveCycle Policy Server), routing of information throughout the organization (LiveCycle Workflow)...
I think the future input looks something like Flex until you need a certifiable document of record, at which point you'll want to move to PDF.
I'm not sure that PDF will be a container for Flash as much as it will continue to be a great container for data.
Jeff:
There are certain usecases when the display of information in a digital form must match the printed form exactly. Many governments face this problem on a daily basis, as do many financial institutions and other large businesses.
PDF is much more than output. Take a look on the web for PDF 3-D samples. They'll blow you away.
If you've got a website, then you're right, you'll use Flash, HTML etc... But, if you don't have a website, if you just have a set of forms, then why re-create those forms in HTML or Flash? Why not just use the format that they are currently in (PDF)?
If you want to display information in the application, then again, you're bang on, HTML, Flex etc... But, what if you want people to look at that info while they're not connected to the Net?
If you're only generating PDF forms when the customer wants something printed, then you're missing out on some real functionality that many customers find very valuable. You should look into the LiveCycle and PDF stuff further.
Thanks for the great comments guys!
Mike
I'm a government employee in IT. Imagine this. A bunch of application screens are created to basically mirror the same information that users submit on forms. A good screen designer/application programmer has index/keys in the upper right corner of the screen for easy identification and more or less most of the screen corresponding to the paper form layout. Or questions the user might ask a customer/client.
If you need to do auditing, there's the process method of auditing (print indicators, etc) And nowdays we might be sending out a form that a user might fill out and sign to be re-keyed or scanned into the system.
Scanning written notes is a different subject, I won't comment on that. But for Data entry done by your own users or those on the web, why even bother to design the screens in the first place? If a scalable and affordable tool can present the forms needed to be filled out to the users, then they can fill the forms out directly on the screen and there's no need to design the screen at all.
Of course internal logic, storing data, etc has to be performed by some kind of database linked to the back end of the form, but that's what XML is for. So in theory you could design a Complete system with PDF forms (To be printed) and other forms used as as screens and store all the information either as PDF's with XML, XML with PDF form tags, or flattened PDF's with ASCII encoded data.
All the options are there with Livecycle and it seems to me to be a very compelling reason to have it. But only if economies of scale and ease of use make it compelling.
For conversion of older systems: the challenge of course would be to re-target transaction processes to a forms based systems. This means re-writing applications to do the other things. And also transaction processing workloads have to be figured into the solution Return on Investment (ROI).
In other words how many transactions (forms) can be processed by an Adobe Livecycle Server? If I'm spending $70,000 US for a set of servers to start and they can only do 890 forms an hour, well that's a really low load from a transaction processing perspective.
An organization with several hundred users would need a lot of Adobe servers to go this route and other web form solutions would be much more affordable.
FOR CONVERSION
There's a lot to consider, especially logic processses that are built into legacy code which are geared towards hundreds of even thousands of different requests that may be encoded into an complex older system. You cannot easily, quickly or cheaply convert these legacy systems to a different database standard, much less convert them to a web or form based one. Where I've worked they have stated they would do it with Oracle in the past and never really put a dent into the legacy apps, but did put a huge dent into our budget.
That's one of the challenges toward using any new magic bullet, you have the weight or what I'd like to call inertia of legacy application development and those old investments providing real work and holding back the new "solution". The new solution also at times becomes nothing more than a "new problem" once it's given to the users, a whole new set of problems for the IT staff to deal with.
For example instead of having 10 or 12 tech people supporting 80 or 90 mainframe programmers - in my particular shop/location we have 70 or 80 people supporting newer technology and microcomputer/web application solutions, that are bought and "deployed". And maybe 20 mainframe programmers still support legacy apps that do the bulk of the work.
So we have a lot more support staff, but don't really do much more work, the work just shifts to a different type of IT position. And there are political implications with new technology vs. legacy, which I'll avoid discussing, but new seems to be "good" to higher ups. It's almost a different mindset and approach.
These are some of the challenges with "new solutions" and "new technology" even when it's canned and supposedly doesn't require programming skills.
Thank you for signing in, You may now comment. (Sign Out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)