Reader Extensions: A Manifesto
Purpose
This post is intended as a simple sketch of views on the “ideal” Reader Extensions business model. Suggestions for amendments or additions to the Manifesto are encouraged! If this post threatens to become a serious document, I’ll move it to it’s own page for further development.
Background
For these purposes, “Reader Extensions” amount to a “switch” within a PDF. When the switch is “flipped”, users with the free Adobe Reader may not only fill out a PDF form, they may SAVE a filled-out copy on their local computer. This single feature has profound implications for the Acrobat/LC business models. Enabling PDF forms for “ReaderSave” is one of the most powerful and horizontally applicable features in Adobe’s arsenal.
Reader Extensions: A Manifesto
1) Acrobat Pro should be able to “bless” PDF files with Reader Extensions (RE).
2) Acrobat Pro and Adobe Reader Extensions Server (ARES) should always complement each other, and never compete.
3) The pathway from Acrobat-driven RE LifeCycle-driven RE should be SMOOTH. Almost any type of application requirement should be easy to accomdate within either model.
4) Scaling from Acrobat Pro-driven RE to LC-driven RE should NEVER imply operational risk to the application. Users should never have to endure a “hard stop” to their workflow simply because (for example) orders peaked in the third quarter! “Crash” installations of ARES to overcome a limitation in Acrobat Pro won’t be good for anyone.
5) The limits on Acrobat Pro’s ability to add core Reader Extensions features should themselves be EASILY extensible via a simple pay-as-you-need-it scheme. For example, if Acrobat Pro were to have the ability to make 250 instances of a form “reader-savable”, then each licenced user should be able to purchase (without ARES) the ability to make the same form savable for 500, 1,000, 10,000 or 25,000 instances at additional cost, using a simple online payment method.
6) RE can be monetized at desktop and server levels alike, and the benefits of each should complement the respective solutions.
7) The correct role for ARES is as a way to CONTROL costs for PDF forms, not to IMPOSE radical new ones, as is currently the case. ARES could allow Adobe to charge for actual usage rather than estimated usage, and allows users to coherently manage Acrobat-enabled forms. Together, these advantages will offer clear savings to larger customers compared with the “pay as you go” method. In other words, the argument for ARES should be turned around - it should be sold primarily as a management and cost-containment tool, not an enablement tool as such.
8) NEVER tell the users how to manage their forms! Let them save, edit, submit, collate, print, scan, OCR, FDF - WHATEVER. Do NOT assume that “most significant use-cases” are reducible to (for example) the ability to convert form instances into a spreadsheet.
9) XFA or acroforms: the distinction should be transparent with respect to RE. Do NOT fail to support acroforms!
July 26th, 2006 at 7:19 pm
Some very good points here. However, I would like to add a few comments, in no particular order.
The first is more a question of terminology: We are talking of “Reader Extensions”, but in most of the post, it would be better called “Extended Rights”. “Reader Extensions” sounds to me more like an application or a component of an application, whereas “Extended Rights” describe in a clearer way, what happens to a document when it gets processed by the Reader Extensions … here we have the application already mentioned.
To statement 1: To a very little extent, this is already the case with Acrobat 7 (Commenting by e-mail Right). And in a very early development stage, the Reader Extensions were actually a plug-in for Acrobat. Therefore, there are no technical obstacles.
To statement 2: This is a very good point, and it should even be possible to add additional rights to a document with either application.
Statement 3 should actually not be necessary, because there should be no differentiating between a “desktop” (Acrobat-driven) and “server” (Livecycle product-driven) extended document.
Statement 4 implies actually the same.
Statement 5 kind of implies an interesting concept, which would make a lot of sense, even if it might be a bit difficult to communicate: It would essentially mean the possibility to buy the right to grant _specific_ rights. At the moment, it is just all or nothing.
Statement 7 shows another concept (pay per use). However, this might work in countries with no or little privacy legislation, but in countries where privacy legislation is strong, we may run into serious privacy problems.
Statement 8 gets my wholehearted support. The users know what, how, and why they are doing something in a speciific way. Period.
And Statement 9 gets my wholehearted support as well. In fact, it would be even better to completely merge XFA technology into Acroforms, and then dump it. The original XDP specification implied this, but then they got watered down (or one can also say “corrupted”).
August 1st, 2006 at 1:19 pm
[…] There were a flood of responses, all along the lines of “No,” and “only with Adobe Reader Extensions Server.” (For more on ARES, see Duff Johnson’s Reader Extensions Manifesto.) […]
August 5th, 2006 at 12:18 pm
Article 8
This is a big step in the right direction, however, it lacks a fundamental principle. No matter what Adobe thinks and no matter how many resources they expend studying and analysing the saveability of user data, Adobe does not, cannot, and should not have any sort of ownership or control over the data that users input into a PDF form.
I cannot think of a single exception to this rule except for forms that Adobe uses for its own business purposes. Everything else is off limits to Adobe, plain and simple.
It’s not a matter of law, it’s not a matter of profitability, of business rights, or anything else Adobe has conjured up as justification for their RE model. It all boils down to this one thing. User data, how it’s produced, how it’s used, how it’s saved, and who it belongs to is at the sole discretion of the user (and in some cases the forms creator), no exceptions!
Whether Adobe charges a government, or a company for the so called right to allow users to Save PDF form data is not the point. Licensing schemes and price tags are not the point. Every version of RE has broken the most fundamental and sacred principle, that the data entered into a form belongs to the person who created it. To limit in any way what a user can do with his/her data can only be described as “data hijacking”.
The ability to Save PDF form data has erroneously been interpreted as some sort of “enhancement” that is worth paying for. This is faulty reasoning. The bottom line is, if Joe Blow spends a minute, an hour, or a day keying data into a form, that work and effort is of value to Joe, it is also Joe’s property. Therefore Joe has the innate right to do what he wants with his work, and that includes saving it. Joe’s work should not require an “enhancement” at someone else’s discretion. No one has the right to deny Joe the benefits of his labor, anymore than denying Adobe the right to make a profit from selling software that it worked hard to create.
To generously give away free versions of the Adobe Reader without a form data save feature is a violation of Joe’s rights to his work. To enable PDF forms with RE (solely at someone else’s discretion) and then only allowing these additional rights to Save Joe’s form data ONCE, is also a violation of Joe’s rights.
I routinely hear the argument that users of Adobe Reader can always “save” their data by printing a paper copy. This is a total copout! Not everyone has a printer. Current surveys tell us that there are now more mobile laptop computers in use than stationary desktop units, yet there are very few portable printers or laptops with built-in printers. This paper copy argument is insufficient.
Article 9
Yes acroform support! The infamous missing ADBC support in RE is a disgrace. If Adobe doesn’t want to support ADBC in RE then they need to resume sales of Acrobat Approval, or a similar product. There is a great need for PDF forms that can communicate with desktop and LAN based databases. I understand Adobe’s business goals in regards to LiveCycle and the desire to get enterprises to migrate to it. However, this type of heavy handed tactic is a sure fire way of alienating developers and those who hold the purse strings.
November 9th, 2006 at 10:34 am
[…] In July, 2006, I introduced the Reader Extensions Manifesto; essentially, a set of checkpoints for assessing the implementation of Reader Extensions in Adobe’s PDF management software. The idea was to offer encouragement and guidance to Adobe Systems as they pondered their strategy for moving Reader Extensions to Acrobat Professional. […]