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.
> Dan's comment about the true nature of hypertext may well be correct but I must
> disagree with his comments on online help. As a user of numerous software
> packages over the years I invariably turn first to the online help when I get
> stuck and, with a few exceptions, I have always found the relevant information
> fairly easily.
Personally I don't view online help in the same way as I'd view an online
hypertext document. To me, the primary aim is of help is to provide the user with
information specific to a task being carried out (how to add headers or
whatever). Depending on the software this falls into two main categories:
1 Context help which is applicable to a specific screen. Here the user is
given 'how to ' help for that screen (how to add a user etc) with very specific
information - step by step instructions, what is required/optional etc. Feedback
from users at my last job indicated that this is what they wanted; they had
little or no desire to jump around the help system and See Also links provided
were seldom used.
2 Non-screen specific help. Here the help is still context help but related to
a function instead of a screen. Again the user generally wants to know 'how to
do something', be it add a bookmark etc. In this instance the search provided by
most help systems essentially equates to an index in a book. As in all TW this
comes down to know your audience - if you know they all call it a thingmebob then
that's what you put in as your key word to search. If you don't know then FIND
OUT and add all the variations. As with an index, you won't get them all an any
two people doing it will not produce exactly the same list.
That's how I see online help. Online docs are an entirely different kettle of
fish and I again see them in two main flavours:
1 Online print docs (eg PDF) which are often simply a cost saving measure with
the prime intention being that they will be printed out by the customer and
essentially used as manuals. Various navigation aids can be added to make them
more usable online but the primary aim is that they print as a book.
2 'True' online docs are, to me, what Dan was talking about when he talked
about how hypertext should be used. I agree entirely that the users should,
ideally, be allowed to jump around and create their 'view' of the
documentation/software etc. However, I see this as akin to giving somebody a
manual with no TOC and no index and telling them to find their own way around it.
Just as it's not feasible to index every word in a doc and include every para in
a TOC (may be feasible but not much use!) the same is true with hyperlinks. Put
in all you can and the chances are the user won't be able to see the wood for the
trees. Again it's a question of knowing your audience and providing the links
that will be of use to them. It's not possible to satisfy everyone but you can
satisfy most users most of the time if it's done properly.
Even when creating help, navigation can be added that allows users to go where
they want. Some of the best I've seen comes with a tree structure (optional)
like explorer that shows ALL the help topics in a hierarchical structure and the
user can browse the tree and go to any topic they like.
Usability testing isn't really applicable where I am now but in my last job all
the documentation was 'proved' by QA and tech support before it went out the
door. This also included the help - relevant help was displayed, information
provided was appropriate and correct etc. In addition, once in the field, any
query to tech support where the answer wasn't in the manual and/or help was
reported and noted for updating for the next release. Occasionally (large
customers!) an updated help file would be sent out asap to rectify the problem.
