TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
There isn't an ideal help system that's perfectly cross-platform. JavaHelp
is immature. HTML Help (all flavors) have problems of their own. None are as
mature and stable and flexible as the old WinHelp for Windows, which
suffered from being locked into the Windows world.
PDFs aren't actually help files in a strict sense of the word. They're just
online manuals. They're more flexible than manuals, in that you can embed
video and such things, but they make no pretense of being context sensitive.
I know several of my colleagues on this list don't put stock in context
sensitivity, but I do. Users like having help that is tightly integrated
into the application itself. By the time users resort to the online help,
they're usually irritated and impatient and making them use indexes and TOCs
in a help file just exacerbates their mood. Bubble help, or at least help
buttons in dialog boxes, help disperse the mood.
When we teach this stuff, we often use a spectrum or ruler to point out that
at one end of the thing is "user in control, writer has little
responsibility", and at the other is "user in minimal control, writer has
huge responsibility". Help files with lots of context connections and
hypergraphics try to anticipate user needs, so take away somewhat from the
user responsibility and control by presenting him with pre-ordained topics
at certain times. This works wonderfully well with certain kinds of
applications, and with a good writer. At the other end is the full-text
search, which confuses the willies out of most users, but delights users
with the skills to use it. No anticipation expected or provided, and it can
be produced by a marginal writer if the budget is tight.
PDF resides nearer this end of the spectrum. There is a TOC/index in a PDF,
but aside from good practices creating these things, they provide little
quick help. The user must figure out the keyword, click on it, and then
double-check his own guess. Not maximally helpful, but cheap and quick to
provide, and as cross-platform as anything can get. With all its faults, at
least HTML Help can be context sensitive, and it's also cross-platform.
You'll just have to cast your own spectrum and decide on your priorities. In
my view, you can do this best by doing a thorough user analysis and asking
your defined audience what IT wants.
Tim Altom
Simply Written, Inc.
Featuring FrameMaker and the Clustar Method(TM)
"Better communication is a service to mankind."
317.562.9298 http://www.simplywritten.com
>My department recently began discussing alternatives to the
>standard Windows Help format. We are beginning to document
>software products that will rely on Web-based technology. We
>have discussed several variations of HTML Help as a
>solution, but none look particularly stable. We are considering
>distributing PDF files with bookmarks and keyword links as
>the Online Help. Has anyone tried this? What are the pros
>and cons? Any other comments are welcome....
>
>Heidi Waterhouse
>SPS Commerce
>hwaterhouse -at- spscommerce -dot- com
>
>
>From ??? -at- ??? Sun Jan 00 00:00:00 0000==
>
>
>