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.
Char James-Tanny provided more insider information: <<To answer your
questions, there wasn't a "Contents" tab as we know it. Instead, there
was a "taxonomy" topic that grouped topics by categories. This, to many
folks, made more sense than a TOC anyway...TOCs are arbitrary ordering
systems, designed by the author.>>
Taxonomies are also designed by the author, and thus have the potential
to be equally arbitrary. To work well, both require audience-centered
design: you can't impose an effective structure or even a taxonomy if
you don't think of the information from the user's perspective. That
insight into the user is what makes a TOC effective. Its absence is
what undermines a TOC, and what will undermine taxonomies too.
I suppose that so long as nobody calls it a "taxonomy" in the interface
that the user sees, the end result is the same. But isn't this somewhat
like renaming a rose a "flurg", simply because "research has
discovered" that people have gotten bored with the word "rose"? The
essence is the same ("a rose by any other name..."), and changing the
name makes no difference. Ask anyone where they'll look for a list of
topics and the overwhelmingly dominant answer will be "table of
contents".
That being the case, why muck with what works? Call it a table of
contents, and provide tools that facilitate the grouping of information
into appropriate categories ("taxonomies"). This is effectively what I
proposed in an earlier message that described custom TOCs designed to
meet specific purposes.
<<And there wasn't an index tab. However, one of the MAML elements was
for keywords, and these keywords would be used to beef up the search.
There were also features like "Best Bet Keyword", which would push a
topic toward the top of a search list.>>
Really. Dumb. Decision. Indexes work well because they organize
information conceptually and by context. A good index provides entries
such as "Print: troubleshooting font problems" beside "Print:
configuring a printer" so you can compare the two entries and guess
which one is most likely to answer questions. The keywords themselves
are merely the superficial evidence of the thought process that went
into defining and presenting these alternatives.
Search engines cannot provide that context unless it's designed into
the text being searched; the keywords must not only be present, but
there must be meta-information that accompanies them to provide the
context for the keyword. Currently, that is the single biggest flaw in
all the search engines I've used. Defining better keywords won't by
itself help improve searches: the same time required to choose and test
keywords would be better spent creating an index.
If you know anyone involved in the design aspect of this part of the
project, please pass that distinction along. It's not trivial, and it's
very important to users.
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!. http://www.webworks.com/techwr-l
Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at http://www.DocToHelp.com/TechwrlList
