OT: Is online help necessary?

Hi Gay,

what is Online Help for you - Context-sensitive? On what platform you need this help? Are there requirements for mobile devices?
I mean the future formats are AIR from Adobe and Reverb from Webworks. One you generate with RoboHelp, the other with WebWorks ePublisher.

Future Online Help needs activities from the user, like integration of Social Media or Search in Communities or Google Search, and commenting tools like DISQUS to moderate it. Single-Source Publishing is more import, if you need more than one output format. Online Help should also be available on (all) mobile devices and readable!, quick to open, and navigable with buttons for touchable devices ...

- Maike

Gay Alson wrote: Hello again, fellow Framers -- After having produced our HTML help in a fairly manual way for the past several years, we have recently begun considering other options, particularly those involving single-sourcing. Members of this forum kindly offered various suggestions including RoboHelp, Mif2Go, and Madcap Flare. In a department meeting today, one of our writers suggested that it may no longer be necessary to provide online help at all, given that we PDF our end-user documentation and could just have our apps launch the searchable PDF user guide when a user clicks the Help menu item. Obviously, intended audience is an important component to consider before making a decision like this -- our audience ranges from novice retail software users to IT professionals. How 'bout it, Framers?  Pros?  Cons?  I'm particularly interested in links to any usability tests available or experiential information on the subject. Thanks as always for the collective wisdom in this group! ~~Gay

If the help is delivered as PDF, it should be as context-sensitive as other help systems. Simply opening the PDF at the TOC is the equivalent of "go fish."

HTH

Regards,

Peter

_______________________

Peter Gold

KnowHow ProServices

Kinda depends - what do you consider "online" help? Some of us regard it as any type of help that appears on a user's computer screen as opposed to a printed package of dead trees. Others feel it should be reserved for help that's produced and posted on the web someplace.

Our company actually has moved away from packaging the help as PDFs and are creating it as WebHelp to be installed on our client's local LAN server. We're single sourcing by using the TCS3 suite to author in FM, import to RH and publish to WebHelp. For those fans of dead trees, we're still printing our FM books to PDF, but only sending them to those who ask for them. Our clients tend to have web access, but don't extend it to all of their workers, so having something that was locally installed (& not on the web) was important to us.

... it may no longer be necessary to provide online help at all, given that  we PDF our end-user documentation and could just have our apps launch  the searchable PDF user guide when a user clicks the Help menu item.

If the machine has a PDF reader installed ...

which I suspect was the historical hesitation with relying on PDF-only help (or PDF-only documentation generally).

I think this ceased being a concern some years ago. I've bought numerous products in the meantime that have PDF-only documentation. Manufacturers used to include an installable Acrobat Reader, but they often don't even do that now, and just include a link to Adobe.

Also, Windows 8 will have a native PDF reader. That officially makes PDF generic mainstream.