OT: Is online help necessary?

Report · Apr 12, 2011

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

Report · Apr 12, 2011

... 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.

Report · Apr 12, 2011

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.

Report · Apr 12, 2011

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

Report · Apr 12, 2011

I have to admit our regular ol' HTML help is not context-sensitive, either. It opens at the TOC...

Report · Apr 15, 2011

brilliant, Peter -- great analogy!

peter at knowhowpro wrote:
Simply opening the PDF at the TOC is the equivalent of "go fish."

Report · Apr 15, 2011

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

Report · Apr 19, 2011

Thank you for your response.

Our online help isn't web help, but is in HTML format, either compiled as a .chm or uncompiled (i.e., uncompressed). We display it in the typical help browser window when the user presses F1 (or accesses the Help menu item) from within one of the software apps that we produce. It is not context-sensitive but is of course searchable.

We will have to investigate "future formats" eventually, as some of our apps will be used on mobile devices. But for right now, we want to replace our current labor-intensive method (using an HTML editor) with something more automated. You do raise a good point, though, because whatever we buy today will hopefully still be usable tomorrow.

Thanks again, I appreciate your input.