Archive for the 'Features I'd like to see' Category

8.1.1, a missed opportunity?

Saturday, August 11th, 2007

Immediately following the release of Reader 8.1, I informed readers that:

The down-side [of the Kinko’s button] is that taking unnecessary partisan positions in affiliated industries and the effective denial of equivalent functionality to all users of the software can undermine the sense of ubiquity, and ubiquity is the essence of the Reader value proposition.

Adobe has now seen the light. It turned out to be an oncoming freight-train belonging to the print industry, who credit themselves as Adobe’s oldest and best customers. Result: Reader 8.1.1, sans Kinko’ button, is due in October.

Like Ted, I was hoping that Adobe would take real advantage of the hubbub and create a new, more platform-oriented feature. The timely burial of “The Kinko’s Edition” could be converted to a significant opportunity. Adobe could make a simple api available to registered printers such that PDF creators could have their own programmable buttons appear on their Certified PDFs.

The Certification mechanism could be of real help here, because Certificates could be used to unlock simple JavaScript calls for “Creator button control”. (More on the promise - and reality - of Certified PDF some other time). Kinko’s (or any other printer) could then offer a service wherein they return a PDF of every print-job with their button added to the toolbar for triggering easy reprints, account modifications or other purposes. There are all sorts of possibilities for getting more mileage out of Trusted documents in this case - as long as it isn’t hardwired to a single vendor.

For the print industry (and indeed, for the rest of us), Reader appears close to a public trust, a notion which Adobe has certainly fostered, if not directly. Such beliefs are nonetheless our own misfortune, and Adobe is entirely within its rights to do what it will with Reader. Adobe Systems is a business, and businesses get to develop and market their products as they see fit, right or wrong. Nonetheless, my hope is that Adobe takes away the following lessons from the “Kinko’s Edition” debacle:

  1. Reader is a precious software franchise not only because it is free, but because it is fundamentally nonpartisan where it counts. For example, Reader will open almost any old, malformed PDF from any source (including non-Adobe sources) without drawing attention to the fact. Likewise, Reader should appear completely agnostic about print vendors unless the creator explicitly chooses otherwise.
  2. If Reader itself is to be sullied with advertising, the responsibility for that glory should be placed squarely on the creator (with the help of Adobe server products, of course). We can safely say that if PDF creators had a new opportunity to add features to the Reader toolbar, they wouldn’t complain about it.
  3. Reader is SO valuable that it should not be used, by itself, to generate revenue, unless that method is author-driven. The Yahoo, Google and Kinko’s deals all “sullied” the brand. There’s greater value to be found in finding ways to serve everyone equally. The toolbar should remain in the service of the platform, not the next business quarter.
  4. For platform software, ubiquity and customer enablement remain the true keys of success. All “improvements” that could impact these essentials should draw suspicion, rigorous scrutiny and deep consultation with affected industries prior to implementation, far more (clearly) than has gone before. This is the price of owning such a deep and wide franchise as Reader.

Posted in Features I'd like to see, Adobe-Watching, In the News, Unsolicited Advice, Acrobat 8 | 26 Comments »

Adobe Document Center: Report from the Field

Friday, December 15th, 2006

I was sufficiently intrigued by the Adobe Document Center to put it to the test with a real document distributed to a reasonably savvy group of people.

I’m one of those people who finds Flash more than a little overused. Once the initial buzz from the soft-focus feel of the all-Flash UI wore off, the Document Center did nothing to dispel this view.

Certainly, the process of adding new Policies and then applying them to documents was very easy. The Document Center doesn’t make it especially clear that applying Policies to documents is conducted from within Acrobat, which it is.  Create a Policy, go back to Acrobat, open your document and navigate to Advanced -> Security -> Manage Security Policies, login using your Adobe ID, select your Policy and save.  That’s it!

Less easy, as I went through version after version of my document, was retaining any meaningful picture of actual usage over time, one of the great Policy Server Promises.  I couldn’t delete revoked documents from the UI, or consolidate their statistics - perhaps that’s just a reporting issue, but it’s significant.  I also couldn’t group users, and I could never tell if or when the interface actually updated, and resorted to logging out and back in, which always seemed to do the trick. 

So, it’s a freebie interface for a freebie demo application, so I guess that’s OK.  I sure would hate to have to use it as a going concern, though.  Subtle hint.

I also found that my document recipients (and they are savvy, no kidding) were in a surprising number of cases quite stumped when confronted with a Policy Server protected document.  Part of this was due to a degree of reticence (or forgetfulness) in loyally signing up for Adobe IDs as is necessary for Adobe Document Center-protected documents.  Part of the problem was clearly also the cumbersome, Flash-heavy (why?!?) signup screen, which sapped enthusiasm further in at least two cases.  Worst, a disturbing number of reports (ie, more than 1) attested to the files consistently “crashing Acrobat”, which certainly wasn’t what anyone wants to hear.

So, I guess I have to report that thus far I’m not totally charmed, there are some definite rough-spots.  The Policy Server is undeniably an extraordinary concept, and I’d like to see much more of it. I certainly proved to my own satisfaction that I could flip a switch in Boston and watch my chosen file go “dark” all over the world, almost instantly, from Manila to Moscow.  For a second, lightning crackled between my fingertips as well.

Here’s hoping that Adobe will leave it in place past the end of the new year, or else limit freebie users to 2 protected documents at any given time… or something of the sort. Let the people kick the tires!

The ability to issue a truly embargoed document and then seamlessly (to prepared users, in any event) update it while simultaneously and effectively deleting all prior distributed copies is, quite simply, MAGIC.  Policy Server could be a real smash-hit if the execution, marketing and sales can be made to match, or even approach, the power of this product concept.

Posted in Features I'd like to see, Adobe-Watching, Unsolicited Advice, Acrobat 8 | No Comments »

Acrobat is a RAD tool!

Monday, October 30th, 2006

RAD = Rapid Application Development (Wikipedia definition)

When Adobe Systems began expanding PDF beyond the original mission of a portable file with reliable printed output, they added navigational, interactive and other features intended to improve the end-user experience.

Beginning with links and bookmarks, then adding form field elements, buttons, javascript, movies, full-screen mode, transitions, templates, layers, XML and more, each new version of Acrobat has seen a corresponding update to the PDF Reference, the document that describes (technically) the PDF format.  When introducing JavaScript for PDF in the mid 1990s, Adobe published the first of the (excellent) Acrobat JavaScript Scripting Reference documents to assist Acrobat developers (and even developer wannabes) in doing their thing.

And what is that “thing”? The original idea was to give form-developers a way to build interactive PDF forms using javascript; forms that could calculate, validate and display changes based on user input.

Beyond business forms, PDF developers began making other ”information applications” with interactive PDF files, including “kiosk” applications such as interactive brochures, slide-shows, training materials, CD and DVD-ROM interfaces and stand-alone document collections.

While PDF doesn’t offer all the whizzy effects available to Flash developers, it is powerful, flexible and stable enough to offer a more-than-capable alternative to Flash in many situations.  In particular, PDF serves uniquely well in terms of delivering seamless continuity between navigation content and document content.  There are other advantages as well - but that’s for another post.

Is Acrobat 8 a step forward for “Acrobat as RAD tool”?  The fact that Acrobat Professional 8 can enable PDFs so that the free Reader can save a form’s contents is a dramatic and very positive move, without a doubt.  Whether the user can save a partially-completed form - seemingly such a simple idea - can (and often does) decide the question of whether PDF is an appropriate format for a given forms application.  With Acrobat 8, that question is now put to rest.

That said, while Adobe has put their steroids into commenting and other features, Acrobat’s RAD tools remain largely unimproved since Acrobat 5. It’s a real shame, considering the exposure such applications offer PDF in a serious value-added context, not merely as electronic paper.  With XPS on the horizon and third-party PDF creation tools proliferating like veritable weeds, the “RAD platform” qualities and potential of Acrobat and PDF are becoming, one hopes, ever more evident in San Jose.

PDF kiosk application developers and users still contend with showers of largely valueless warning dialogs.  Up to and including Acrobat 8, the application assumes that every PDF that includes fillable form-field elements must therefore logically be a form… and thus the user must be warned that they can’t save it.  What a narrow way to understand the power and utility of form-fields!  It’s also perfectly plausible that this PDF is NOT a form, but is instead a self-contained application - a delivery, navigational and interaction system for a body of content, leveraging the toolkit Adobe still seems to think is “only” for forms.

Serving up a warning that the user “can’t save” the file is fine as a default, but clumsy details like this have obstructed the development of interactive PDFs for years.  Developers should be able to simply turn off this warning, or otherwise place the document in “kiosk mode” at runtime.

I am, however, happy to report the news that in Acrobat 8, there finally IS a way around the “Reader can’t save” warning that so frustrates PDF developers.  Use Acrobat Professional 8 to enable Save rights in Adobe Reader, and… guess what!  No more warning!  That’s one way to do it… and it works!

Posted in Features I'd like to see, Adobe-Watching, Acrobat 8 | 3 Comments »

A milestone: Acrobat Help now online

Tuesday, August 8th, 2006

As noted by my esteemed fellow Blogger and AUC Editor Kurt Foss, AcrobatUsers.com has now made it easier to learn how to get things done with Acrobat by posting the Acrobat Help file online.

Now, why do they need to post it online, you might ask?  Isn’t the Acrobat Help file available right there in the Acrobat Help menu?

Indeed it is.  However, note that the clever little “mini PDF browser” invoked from the Help menu doesn’t allow one to know the page-number one is looking at.  This can make it sometimes quite difficult to quickly and effectively refer people to the correct section of the manual to assist in clarifying a point. 

To illustrate; two different ways to refer to the same location in the Help file:

  1. Acrobat Help, via the Help Menu:  “Go to the ‘Converting Adobe PDF documents to other file formats’ section, try a text-search to find it.”
  2. Acrobat Help, as referenced via page number (hyperlinked or no):  “Page 176″

Which would you prefer? One way to know which page-number you are looking at in the manual is to track down or even provide links to the file itself (ACROHELP.PDF) on Windows machines, usually found at C:\Program Files\Adobe\Acrobat 7.0\Help\ENU\.  But this advice is bad - for it encourages users to poke around in the program files area… not a good idea.

Making the Help file available online thus provides a straightforward way to address a variety of training and reference issues.  AcrobatUsers.com currently makes the Manual is currently available as a Zip file.

The next move (and it would be a good one), would be to deploy each page and/or topic of the manual as a separate file (PDF or HTML), with a durable URL. This would allow any user to easily create a hyperlink direct to Adobe’s documentation to illustrate a training or reference point, or easily incorporate it within their own documentation.

Now, Adobe shouldn’t encourage anyone to actually print the Acrobat Pro 7.0 manual… quite a few of the pages are over 20 inches in length, with no page-break - injurious to their appearance when printed, even under the best of circumstances.

Ironically, the “Print Adobe PDF Documents” page (p. 642) is over 41 inches long. (!)

Posted in Features I'd like to see, Adobe-Watching, Unsolicited Advice | 1 Comment »

“Manifesto” now a page…

Wednesday, July 26th, 2006

I’ve received sufficient interest in the idea of a “Manifesto for Reader Extensions” that I realized I needed to (a) swap the nomenclature to “Extended Rights”, and (b) make a “proper” page for the idea. Here it is. Please feel free to email me your comments and suggestions. If your suggestion is adopted, we’ll add your name (only if you wish) to the Contributors list!

The name change idea (thanks, Max Wyss) was a “duh” as soon as I heard the suggestion. Not auspicious, I suppose, such evidence of mental clutter. Moving on…

Posted in Features I'd like to see, Reader Extensions | No Comments »

Reader Extensions: A Manifesto

Tuesday, July 25th, 2006

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!

Posted in Pet Peeves, Features I'd like to see, Adobe-Watching, Reader Extensions | 7 Comments »