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.
Howard Peirce is pondering <<...design considerations for
very large hypertexts? By "very large," I mean roughly
equivalent to ~10,000 printed pages.>>
Youch! Glad I'm not the editor on that project.
<<Our current documentation (shipped in HTML) uses a
"library of books" navigational paradigm... the user chooses
one of roughly 40 "books," and navigates primarily by means
of a java-based hierarchical TOC.>>
On the (inter)face of it, that sounds like a reasonable design,
though I have to wonder (not knowing how you've separated
your books) how intuitive this is. Long ago, I spent many an
unproductive quarter-hour cursing the folks at Interleaf for
splitting their documentation across multiple volumes in ways
that didn't always make sense to me. Are the boundaries of
the 40 books very clear (e.g., one book per machine for a 40-
machine system), or somewhat arbitrary? If they're clear, then
you've got a good starting point for the rest of your design. If
not, then the paradigm needs some work in light of how
computerizing the books can make it easier for readers to find
what they need.
<<All the "books" are identically formatted, and consistency
of look and feel is considered very important... However, as a
surrogate user navigating the help system I participated in
writing, I find 10,000+ pages of consistently formatted and
navigated text almost incomprehensible. It all becomes a blur
in short order.>>
I suspect that a large part of your reaction relates solely to the
fact that you're too close to the project to be truly objective; I
once spent several profitable but wearying days scanning a
large database of addresses to identify missing and obviously
incorrect information, as well as flagging anything suspicious
that needed verification. Mind-numbing work, and I
guarantee that I missed stuff as I became increasingly sedated
by the task. Another large part of your reaction is due to the
fact that you're probably not using the docs the way a real
user would; in fact, it sounds to me like you were checking
the validity of all the links manually rather than trying to
navigate to a single help topic that would help you solve a
specific problem. If either of these factors applies to your
situation to any significant degree, it's time to take a step back
and ask whether your reactions are really typical. In
particular, what does your audience think?
Despite what I've said, there's almost certainly some validity
to the problem you've identified. I've occasionally seen
people use different visual coding schemes (e.g., different
paper colors or different graphic ornaments in the running
header for different manuals) so that readers know when
they've changed modules. I'm equivocal about this because
sometimes this works for me, and sometimes I don't even
notice it until I do an analysis of the information based on
information design principles. I've also tried some of these
tricks and discovered afterwards that my graphics colleagues
and I were the only ones who ever noticed them. That being
said:
<<I think that we should design variety into the
documentation, such that different kinds of information
(concept vs. process vs. reference; design vs. analysis vs.
manufacturing) would have a radically different look and
feel. This would provide immediate visual and kinesthetic
cues to let the user know "where they are.">>
Variety for its own sake is rarely useful, but I think you've hit
the important point here: different types of information
require different formatting. As a trival example, think of the
differences between headings and body text. A little more
sophisticated case would be the fact that reference material
often lends itself extremely well to a table-based approach
that would be disastrous for step-by-step procedural
information; similarly, the warranty and disclaimer
information probably doesn't require screenshots <g>, though
some of the procedures do. So if two different types of
information look identical, you're doing your audience a
disservice. In this case, the "cues" are less important for their
own sake; they're more a symptom of whether the format of
the information really supports its use.
<<the WWW itself becomes a navigational paradigm--I never
get lost when websurfing, because each site is unique.>>
Unfortunately, you may be an exception to the general rule,
though I've read conflicting reports on the frequency of
"getting lost in cyberspace"; even if you're not atypical, your
example is misleading. For example, it's easy to tell when
you're on the Sports Illustrated site versus the PC Magazine
site (analogous to two different books in your library of 40),
but it's often very obscure which particular part of the site
you're in once you settle down to the pages in a single site
(analogous to finding the particular book you need to consult
and then getting lost in identical pages). That suggests that
variety may only be important at the micro level
(differentiating two types of information, not two books).
<<how easily would you navigate the Web if all sites looked
alike?)>>
Personally, I'd do just fine with that, but I'm a very text-
centered person; I am visually skilled too, but I have to
consciously switch modes of perception (the robot said <g>)
to become "fully functional" in the other medium. Other
audiences would respond differently, and it pays to remember
that.
