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.
Subject:Usability of WinHelp features? From:Geoff Hart <Geoff-h -at- MTL -dot- FERIC -dot- CA> Date:Wed, 25 Aug 1999 13:33:40 -0400
Dan Roberts is <<...in the midst of planning my own
RoboHelp project... and I'm wondering about the usefulness
of some WinHelp features - do they really help communicate
information to the reader/user?>>
<<In the paper doc, I've got a screen capture, followed by a
table summarizing the functions of the various buttons on the
screen. When I go online, I can either keep the table, or turn
them into hotspots on the graphic.>>
Why not do both? Keep the table for those who print, and
add hotspots for those who don't. The nice thing about online
is that you're not constrained much by document size
compared with print, so it's easier to build multiple modes of
access to the information than in print.
<<Hotspots take up less room on the WinHelp window than
tables do; otoh, ya can't print hotspot text if ya print the
topic>>
Sounds like you mean "popups" or "what is this?" ("tool tips")
rather than hotspots. If that's the case, then it emphasizes my
point that you should use both hotspot and table. If you mean
that the hotspots are part of the screenshot, and clicking on
the screenshot takes you to a window with information on
that part, that's another story. The simplest workaround is to
make that information part of the same topic (rather than in a
separate window)... just lower on the same page. This has the
advantage of letting "sequential readers", read in a more or
less logical sequence through all the info. on a particular
screen. Don't let anyone kid you: some people (me, for
instance) really do read docs linearly at times, even online.
<<In the paper doc, each screen... is followed by a table that
describes the fields that require user input. When I go online,
I can either keep the table, or list the fields and use popups to
provide the field descriptions. Again, using popups takes less
space in the WinHelp window, but they don't print out if the
reader/user prints the topic.>>
My preferred workaround for this situation is to introduce the
topic with a list of the field names and a short summary of
each (in a table, for instance, so ideally, a skilled user gets all
the necessary info. in the first screen, without having to jump
or scroll); then, I turn the field name into a jump to a subtopic
later in the same "page" (topic) of the help file. That way,
those who need more detail click on the one field they need
the detail for, jump to a later point in the page to see the
details, and can print the entire help info. for that set of field
names without having to print multiple files. This may be
problematic if there are many, many fields (i.e., you get long
printouts), but on the whole, it seems to work well.
<<Each general topic has a number of related tasks. I
can provide a list of tasks in each topic, and/or under the
topic in the TOC [Table of contents]. I think putting the tasks
in the topic window is a good thing, but not sure about the
usefulness of also including the tasks in the TOC.>>
There's no reason not to include them in the TOC if the TOC
is hierarchical; users can drill down as deep as they need, and
if they never need to drill down to the task level, they won't
see the extra information. I'm not a fan of the WinHelp 4
TOC, but the expanding/contracting hierarchy is one very
nice feature if properly implemented. Even so, I much prefer
to build the overall TOC plus the mini-TOCs for each section
by myself. It gives me far more control and seems (based on
personal prejudice due to lots of encounters with truly useless
TOCs) more user friendly than most WinHelp TOCs that I've
seen.
<<I've got a Head1, then a H2 topic with no H3s, then a few
H2 that *do* have H3 topics in them. When I go online,
I've got a H1 book that opens to display a page, then a book,
then a book. And that just looks odd.>>
It looks a bit odd, but I doubt anyone will be disturbed by it.
After all, the identical phenomenon doesn't seem to bother
Windows users who open a directory that contains both files
and subdirectories (or Mac users who open a folder that
contains both files and subfolders). But if it bothers you, you
could always get rid of the automatic TOC and replace it with
your own manually created list.
<<If anyone has any sort of input from their customers about
their online help - what was useful, what wasn't, what was
annoying - I'd appreciate hearing it.>>
Ditto. I guess I screwed up somehow: word is, everyone's
pretty happy with my documentation, or at least so
intimidated that they haven't mustered the courage to
complain. <g> All joking aside, that's a fairly serious
problem, and I'm hoping to get permission to talk to some of
the users soon, since the version 2 docs are looming ahead of
me.
"Perhaps there is something deep and profound behind all those sevens,
something just calling out for us to discover it. But I
suspect that it is only a pernicious, Pythagorean coincidence." George
Miller, "The Magical Number Seven" (1956)