Archive for the 'Pet Peeves' Category

Are we Connect-ing?

Thursday, March 22nd, 2007

Much touted in the new Acrobat release is “Acrobat Connect“, formerly Macromedia’s Breeze.

By now, I’ve participated in several Connect “sessions” as both presenter and presentee, so I thought I’d offer a few observations.

Connect hasn’t really got anything to do with Acrobat, and I’m really unsure why Connect occupies a prominent place in Acrobat 8.0 at all. Connect is something like WebEx, with some clever interactive tweaks. The polling, chat and status facilities are good, but it’s not a trivial affair, and it’s not really about managing or using documents. It might someday benefit from being pressed into service in the “Acrobat family of products”, but that day isn’t here yet.

In the present incarnation, Connect can’t actually use PDF files except in a desktop-sharing (ie, bandwidth-intensive) mode. This simply serves to highlight the lack of any real connection between Acrobat and Connect, even though Connect is available “with” Acrobat, even allegedly “integrated” into it.

While I have certainly experienced a number of connection issues (especially with the VOIP), I understand this is not the norm. Regardless of my circumstances, in today’s world, one can’t really expect that all users have big or stable pipes, be optimized for VOIP, or have adequate speakers or microphones for their environment. Laptops suffering wireless interference is increasingly common. Adobe recommends that presenters and viewers shut down their other chat, email and other applications to allow Connect to hog the bandwidth, and further, that you shut down the Presenter’s video uplink as well. At what point wouldn’t you rather make a YouTube movie or email a PowerPoint?

Even with the current generation of the software, a carefully planned meeting using the polling, chat and other features, and POTS (Ma Bell) for audio can work well, even for remote users. Connect has real potential to be a useful conferencing system for experienced users enjoying 1st class connectivity. As presently constituted, new and infrequent users are going to stumble and fall to a degree that will deliver poor impressions when they count the most.

While Connect sessions may be easily recorded by the Presenter, disclosure of this fact should be made clear to the end-user, visually and otherwise. The Presenter should not be encumbered with the responsibility of reminding each and every attendee that “this session is being recorded”, especially if the session is interactive.

At least some who check out the Connect “offering” through Acrobat come away confused and/or a tad miffed. The general opinion seems to be that Adobe doesn’t make it clear that Connect is not actually a new feature of Acrobat, but a new service, with it’s own (again, non-trivial) fee structure.

Lastly, my accessibility creds force me to point out that there’s nothing remotely accessible about Connect - it’s a free-flowing Flash interface, and screen-readers aren’t welcome here. This will, in the long term, have to be addressed if this technology is to have a big future in government.

All that aside, I like Connect - right down to the nervous anticipation that comes from wondering if it will all fall apart midflight, or that I’ll lose the thread, or go blind from squinting at the non-resizable copy in the UI. I just wonder if it’s properly co-located with Acrobat.

Cut it out, or copy without? Redacting with Acrobat 8 Professional vs. Redax

Thursday, November 16th, 2006

redactionOne of the new features in Acrobat 8.0 Professional garnering significant comment is redaction. This handy tool allowing users to permanently eliminate text or graphics from a PDF page. Solid, simple idea - what’s not to like?

Thus far, Acrobat 8’s redaction tool has been generally well received in principle, although a few discriminating reviewers have also noted a key concern with the method Adobe chose for redaction in Acrobat 8.0, as we shall see.

Acrobat 8 Professional is the first Adobe software to include a redaction feature for PDF, but it’s not the first. Acting on a request from Adobe, in 1996, Appligent developed and released the first version of Redax, which quickly became the definitive tool for serious redaction work on PDF files. The latest version of Appligent’s Redax works with Acrobat Standard and Professional versions 6, 7 and 8.  So you don’t need to upgrade to Acrobat 8 Professional to get PDF redaction.

To help me evaluate Acrobat 8 Pro’s new redaction tool, I wanted to find out more about how people use (or fail to use) the one PDF redaction tool that’s been available for over 10 years. I talked to Mark Gavin, founder and CTO of Appligent, to get his take. I began by asking Mark to explain the basic difference in the way Redax and Acrobat redact PDF. The answer was illuminating.

“There are two primary differences between Adobe’s redaction and Appligent’s redaction,” Gavin says. “Appligent uses an “additive” redaction methodology while Adobe uses a “subtractive” redaction methodology.”

OK, sounds technical… but redaction is redaction, right? Who cares how you zap it? This is where Gavin set me straight.

“Adobe takes an existing document and attempts to remove or “subtract” information,” says Gavin. “Appligent creates a new blank document and then “adds” the non-redacted information into the new document. Thus, the new document has never been touched by the information to be redacted.”

So, why does this matter?

Although Acrobat redacts the way you might intuitively expect (subtraction), this method is flawed. As I saw for myself almost as soon as I started redacting with Acrobat 8 Pro, I managed to “nuke” my original document by carelessly doing something that’s routine for me in other document workflows - a “Save As” operation in which I over-write my original file before I’d even realized what I was doing.  I’m not exactly the average user, so this got me thinking.

Someone who makes this mistake while redacting in Acrobat 8 Pro, will be running for the backup tapes - if there are any. Once redacted, that data is GONE. That’s a pretty harsh penalty for a easy fumble with a single keystroke. Redax’s redaction method, by contrast, makes it pretty much impossible to damage the original document.

The problem arises because Acrobat merely offers the user a ‘Save As” opportunity rather than assuming that the redacted file must be, of necessity, a new version of the document… a redacted version.  Inattentive users and system crashes are known threats  to be engineered around.  In principle, no redaction workflow should EVER put the original document at risk.

Gavin went on to explain that Acrobat’s method forces the application (and the user) to locate and remove all of the document metadata with an extra step, even custom metadata that Acrobat knows nothing about. Since Redax creates a new blank document, the only information retained is that specifically requested by the user - the text and metadata they affirmatively chose NOT to redact.

The second major difference between Acrobat and Redax, according to Gavin, is that Redax is designed to redact in a “fail safe” manner where Acrobat is not.

“If for whatever reason the document is not redacted correctly, this must be made very clear to the user that something is wrong,” Gavin says. “One of the techniques Redax employs to ensure fail safe operation is to use transparent zones to identify redaction areas. If any text or graphics remains in the redacted document it can easily be seen by the end user. On the other hand, Acrobat’s redaction zones are completely opaque. Since on occasion the Adobe software will fail to redact all the information correctly, the user won’t be able to easily see that information has been left behind.”

For these reasons, I cannot as yet recommend Acrobat’s redaction, free as it is (with the purchase price of Acrobat 8 Pro), over the fail safe and time-tested Redax.

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!