CharlesJeter.com » adobe acrobat

Blogging in April on the Threatblog

Charles — Sat, 01 May 2010 02:44:47 +0000

The following is a summary of my posts for April on ESET’s ThreatBlog. The hot topic was cyberwarfare however Facebook and personal privacy received quite a bit of attention, as well as FBI related analysis. If you’re interested you can subscribe to ESET’s Threatblog RSS feed.

Update: links were broken, now they’re fixed!

Getting FLOSSy: Acrobat Killer Or HAT Replacement?

Charles — Sun, 31 Aug 2008 07:59:50 +0000

Technorati Tags: adobe acrobat,adobe FrameMaker,FLOSS,wikipatterns,wiki,technical communication,technical communicator,madcap flare,madcap blaze,x-edit,buzzword,flossmanuals,madcap team server,open source

FLOSS Manuals: The OTHER FM for PDFs

Some writers truly hate Adobe Acrobat and any tool that can do the job better is worth a shot, particularly if it’s open source and easily navigated. Flossmanuals.net introduces FLOSS which does a lot of the single desktop Acrobat Pro’s job – collaboratively and open source.

Could FLOSS be the new Acrobat Pro killer?

FLOSS could bridge the gaps between Subject Matter Expert (SME) authoring of content and true documentation. For the specific purpose of supporting open source collaborative efforts this is heaven sent. Most open-source dev teams are simply not able to have those wonderful team meetings for doc review either for financial or time management purposes.

Update: Anne Gentle’s site talks about an event called a Booksprint that FlossManuals.net is doing for technical writers in support of open source programs.

I’ve been reading Janet Swisher’s review of FLOSS Manuals. She examines the pros and cons of Wiki briefly and explains the problem / solution of FLOSS definitively:

You can write documentation using an open source word processor like OpenOffice.org Writer, but you still need a content management system of some kind to handle versioning of drafts and communication within a project community, and CMSs are complex to set up and maintain.

And so a divide has emerged, with open source programmers on one side, wishing somebody would come help write the docs, and potential writers on the other side, too intimidated or too busy to learn the tools to work on open source projects.

FLOSS Manuals bridges that divide, and does so in a way that is deeply rooted in the open source ethos of community and collaboration.

FLOSS and Wikis for Documentation

The implementation and administration of the wiki model always seems to be the insurmountable challenge, if one is to be found. Janet has a solid point regarding Stewart Mader’s viewpoint on wikis for documentation:

I’ve generally been skeptical of wiki advocates who say, “Oh yeah, and you can create documentation in a wiki, too”, because I’ve seen very few actual examples.

Janet’s link refers to an article by Stewart Mader regarding the specific issue of documentation within a wiki. This happens to be an area where Stewart Mader and I disagreed earlier this year. I haven’t heard of many live wikis truly impacting technical writing and Janet confirms this from her perspective as well.

I’m happy to report that Stewart, Janet, and I technically all win on this point.

FLOSS Manuals IS a wiki, but it’s purpose-built for creating documentation. Its founders have created an open-source standard of documentation that blends reading, writing, plus allowing output and redistribution of content, all efficiently administrated for the open-source community.

However, each manual must be managed separately and that’s where technical writing and document content management skills shine.

Flossmanuals: A Help Authoring Tool Killer?

This bears examining because there’s a lot to be said about context-sensitive help within applications as well as the authoring platform for help. Tom Johnson’s recent poll and the ensuing HATT debate shows a passionate user base for tools.

Janet states:

Flossmanuals.net is heavily oriented towards book-style manuals; you could use it for topic-oriented online help, but it might be a stretch—a HAT it is not. But now that there is FLOSS Manuals, there simply is no longer a technological reason for any open source project not to have documentation.

I agree with this. There’s a method to the madness when you’re writing online help files and formatting is a critical element which a formal HAT tool is designed for.

For now, FLOSS is free*, with a minor amount of techie magic necessary. I envision beginning tech writers using this to support their early projects for open source software and quickly learning the basics of the technical communication trade.

*From the Flossmanuals site:

Our principle aim is not to be a publisher but to create as many tools and outlets for quality free documentation as possible. If that means you wish to use the FM tool set but host or ‘publish’ under your own banner, then that’s excellent. We are very happy to offer you a documentation platform to meet all your documentation needs.

Of course, all this is for free software / open source software projects only. If you create proprietary software then…

Clearly this means that you need to talk to them before boldly profiting from this community.

Workflow Focused Help Authoring Tools

Figuring out the fastest and best workflow is something the MadCap and Adobe teams are each wrangling, however they have markedly different approaches.

MadCap’s Team Server solution is in development. Along with the expected release of the publication centered form of Flare, Blaze, this is their collaborative workflow answer.

Adobe seems to be several generations behind MadCap. Adobe’s answer to innovation seems to be to continue bundling new product lines into their Technical Communications Suite, plus to integrate what MadCap introduces as quickly as possible. If they can’t directly compete with innovation, bundling secondary products is another way to add value.

I can see that both are working towards collaboration tools – MadCap with X-Edit, Adobe with Acrobat and their newly acquired web-based collaborative tool, Buzzword.

My Opinion:

FLOSSManuals.net is a great place to start writing content for developers if you’re just starting out or would like to support a friend’s really cool application. I know of several for-profit companies that put out free widgets of one sort or another that don’t have tech writing staff. This would be perfect for that as well.

The other side of the coin is that it gives a good measure of what’s actually effective. While wiki implementation is challenging, on a cost scale when someone like FLOSSManuals is administrating it, it’s definitely worth exploring.

While not a HAT replacement, this model may work well to supplement a workflow.

Another PhD States: Why I Hate PDFs

Charles — Fri, 29 Aug 2008 00:49:30 +0000

Technorati Tags: pdf,user manual,online help,adobe acrobat,user assistance,technical communicator,technical communication

Great article by Michael Hughes, PhD in Instructional Technology.

User books died; if they had value in that form, companies would still print them and users would buy them. Yet PDFs still hang around like pathetic home town sports fans after the team has moved to the West Coast.

Quintus in The Gladiator says “A people ought to know when they’ve been defeated.”

PDFs should get the wake-up call.

Of course the good doctor began his article stating it’s not every single PDF he hates:

Not all PDFs; that would be over the top. I just hate user manuals that are distributed as PDFs. From User Assistance: Why I Hate PDFs

Hat tip to Char James-Tanny’s Helpstuff blog where Char posts many well written tips on PDF user manuals:

If you’re going to distribute an online PDF as a user’s manual instead of one of the many appropriate online formats, then at least make it easy for your users.

Save Yourself $700 and a Headache | Is MadCap Flare Now Leading Adobe RoboHelp In HAT War?

Charles — Wed, 13 Aug 2008 07:26:34 +0000

Technorati Tags: adobe robohelp,adobe acrobat,microsoft Word,madcap flare,pdf,xps,help authoring tool,Adobe AIR

How much money do you need to pay to make quality PDFs? According to Tom Johnson, the I’d Rather Be Writing author, zero.

Free PDF Generation

Tom opens by talking about that irritating little release updater that Adobe runs in the background. Speaking about PDF functionality that exists in Word 2007 Tom states:

…you can download the Save as PDF or XPS add-in for Microsoft Word 2007 for free. It’s less than 1 megabyte to download, and it quickly and flawlessly converts Word docs to PDF, even with hyperlinks. If you have non-Word documents to convert, Primo PDF (another free PDF alternative) will do it absolutely free.

I keep wondering why Microsoft wasn’t able to package this add-in with their updates, or initially with the product.

After reading my PDF summary from January you’ll know my position on this necessary but often overused documentation format. Yes, I use it. Yes, it is a standard. But not worth $700 if you don’t have to spend it.

Help Authoring Tool War – Now Led By MadCap?

What brought me to the IRBW site this evening was the poll that Sharon mentioned. Surfing over to IRBW I checked it out – here’s the Authoring Tool voting stats listed as of today.

I’m not surprised. This is what happens when you lose confidence in the software manufacturer who takes over a popular product such as RoboHelp and loses touch with the market.

Adobe, Adobe… Is AIR going to ‘Help’ you?

AIR seems to get some traction for ADBE however. The stock is still trading near 52-week high levels and has been climbing since it’s low around March of this year.

I’ll have to do a follow-up to my 2007 prediction of stock value for Adobe (NASD: ADBE) dropping this year. After all, Microsoft (NASD: MSFT) isn’t releasing Vista and ADBE’s forced upgrade tactic isn’t as relevant.

We’ll have to see how things go at the end of the fiscal year… They could prove me wrong.

Am I First to Coin The Term AIRHelp?

Then again, last month Ben Minson’s two part review of the RoboHelp Packager for AIR public beta raised some solid questions about the functionality of the software for the end user.

I’m not sold on .air taking over the world of WWW just yet. I agree with most of this take from Ben Minson on ADBE AIR:

Adobe seems to be following a good line of thinking here with AIR help. But remember, users want simplicity. Having to install each help system as an application is asking too much of everyday users.

This use case for AIRHelp would tend to put us back to the .chm days with a distributable file that needed to be on every system running it. eHelp introduced WebHelp as a way to get away from that back in 2002.

ADBE’s RoboHelp… Innovative A Year Too Late To Be Innovative

Doing something like Web 2.0 two release cycles behind your competition is not innovative. It’s keeping up with the market that’s trying to leave you behind. AuthorIT and MadCap Flare been-there and done-that already.

I reviewed MadCap’s Web 2.0 functionality last year as the Feedback Service. It doesn’t require installation on the client side of anything special and works cross-platform. It’s been pointed out that it can run on any IIS server on your network, even your desktop in your office.

From MadCap Mike’s Musings – Comparing Documentation Server Software – MadCap Feedback Server and RoboHelp Server:

Web 2.0 – The MadCap Feedback Server support for Web 2.0 community technologies is a complete turnkey system. Once installed there is nothing that your developers or programmers need to do to make this work. All that is required is for you to select the appropriate options while publishing your Flare projects to turn these capabilities on.

In contrast, the few similar options that Adobe has introduced are limited to the Air output only (not available in the more popular WebHelp) and even then require either programmer/developer hours or Rube Goldberg-esque scenarios where data files have to be emailed back and forth between users.

Ben’s review points out the obvious flaw; why make end users download and install something special rather than transparently do the Web 2.0 on the server side? Additionally, having an attachment-based data output for the actual server doesn’t make much sense either.