The transition from Acrobat-driven Reader Extensions to LiveCycle-driven Reader Extensions should be SMOOTH. Instead, it’s like the difference between stepping off the curb and hang-gliding from a cliff.
I’ve been talking to clients and others about the Reader Extensions feature in Acrobat Pro 8 and 9, and it certainly gets a lot of attention. When I bring up (as I am both honor and duty-bound to do) the facts of the Acrobat End User License Agreement (EULA), there’s a profound silence. Then come the questions.
Some people want to know whether this “limitation” is enforced, maybe in the software itself, or by an army of lawyers. They come up with a variety of (often plausible) reasons and arguments as to why the (notably vague) EULA doesn’t actually apply in their particular case. Of course, I listen sympathetically – and refer them to their attorney.
Some people ask variations on this question: “What if I start developing my forms application using Acrobat’s Reader Extensions, then I add the form to my website. What then?”
This usually starts a little conversation, which typically goes as follows:
First I ask a question: “Are you expecting more than 500 users?”
The answer is usually straightforward: “Of course. Maybe 1,000 users in the first year, and so on.”
To which I am duty-bound to reply: “OK. Then you’ll need Adobe’s Reader Extensions Server.”
All of a sudden, it’s a whole new conversation with a radical new price-tag. Most of the time they settle for making the end-user fill the form by hand, or else dare them to complete the form in a single session without a crash. It’s easier than a big up-front cost, especially these days.
The original subject… the form? Forgotten.
The opportunity to deliver a high-quality (not to mention, functional) end-user experience? Lost.
Originally posted on Duff Johnson’s PDF Perspective blog for acrobatusers.com.
By Duff Johnson