Navigational paradigms, take II

[Geoff Hart <Geoff-h -at- MTL -dot- FERIC -dot- CA>]

Howard Peirce provided additional information:

<<Each task is a book (except when there are several tasks in
one book--don't ask). Books vary from ~50 - ~400 pages,
depending on the complexity of the task. There is some
hyperlinking across books, but often the only way to get
around is to dig your way up to the top and burrow back
down.>>

Sounds like this is a good candidate for diverging from the
(paper) book model: it might be worthwhile seeing whether
you can rigorously separate each task into its own book, and
repeat certain necessary information in each book rather than
insisting on hyperlinks. (There are various ways to do this
without spawning several different and incompatible versions
of the repeated text.) Then you could provide lots of "related
topics" information in place of the hyperlinks to help people
find other books relevant to a particular task--but only if they
need to browse in that direction, not as a condition for solving
the current problem.

<<the search function only works in one book at a time.
Sometimes the thing you're looking for is in another book, in
which case you're hosed...>>

Sounds like a job for a good comprehensive index.
Conveniently enough, there's a relatively new product called
HTMLIndexer that's been attracting favorable reviews; it
sounds like just what you need. Have a look at www.html-
indexer.com for details. (David Brown can provide more
information on this list if you ask nicely!)

<<I might write about Simulation, but need to learn
something about Design, so I go into the Design
documentation like any other user.>>

If making that leap doesn't let you find what you're looking
for, then that does indeed sound like a problem with
information retrieval; after all, if you can't find the info, and
presumably know more about the product than the average
user, I don't imagine the users will have much better luck.
Again, a good index might solve this problem.

<<There's yet to be a lot of feedback generated, and the
usability testing has been mixed.>>

Fortunately, you're publishing HTML; it's easy to update. But
one very effective strategy where you have mixed feedback is
to (where possible) concentrate on the negative comments
identified through usability testing, on the assumption that
you get more payback from fixing overt problems than from
improving things that are already adequate. The real trick is to
ensure that you understand why people are reporting
problems; sometimes the obvious reason isn't the real reason.

<<...we change banner headings for the different books. The
design is the same, but the color and text change... I find the
colors come up inconsistently...>>

As long as there's a visible change to alert the user, and that
you get the same change for all pages in a given book, that's
probably all you need to worry about for now. Bigger fish to
fry than the precise Pantone color matching system!

<<what level of granularity determines "different types of
information"? ... one procedure might involve the general
steps in taking a mechanical design from a crude sketch to
complex part to drafting to simulation to writing control
programs for NC machining. Another procedure
might involve the sequence of selecting options for a single
modal form.>>

I'm not sure you need to come up with different styles for
different procedures: I suspect that it's enough to simply
distinguish procedural material from reference material. Finer
subdivisions strike me as not being all that useful; after all,
how many ways can you number a step in a procedure?

<<our users range from kids with associate degrees to
engineering Ph.Ds to managers with MBAs... consistency
should take a back seat to targeting these specific
audiences.>>

On the contrary. Unless you're prepared to develop separate
support systems for each of these audiences, you almost
certainly need _more_ consistency, not less. You're not
"writing for the least common denominator", but rather
coming up with one design that works for everyone. That's
possible, by the way.

<<I'm also pretty darn sure that the software I'm currently
documenting has no typical user.>>

One thing I've often stated on this list is that clear, concise
writing works for _any_ user. You can quote me on that.
What differs most among users is the amount and nature of
the information they need, not how you express that
information. (Using the jargon doesn't necessarily improve
communication, other than for predominantly specialized
audiences.) The problem then becomes one of formatting
(i.e., how to keep all the information easily available, without
burying expert users in info they don't need).

<<But again, what is the standard for differentiating
different types of information?>>

I'll cop out on this question and give the correct (but
unhelpful) answer: ask your audience. My preference--which
may not be theirs--is to opt for simplicity. The more complex
you make your differentiation, the more complex you make
the task of understanding that coding. Never ask readers to
learn a coding system unless the paybacks from that learning
are so huge that they'll overcome their resistance to learning
the system; more often, they'll just give up trying. Personally,
I don't think it's fair (for a diverse audience) to make people
do this work before they can answer their questions: they
want to solve problems, not learn (or admire) your formatting.

<<Some procedures are absolutely basic, and all users need
to understand and feel comfortable with them to use them
every day. Other procedures are used only rarely, by
highly skilled users, and only in exceptional situations. Do
these constitute different "types" of information?>>

I wouldn't say so: a procedure is a procedure is a procedure.
However, I would say that you need to be sure that you've
analyzed your users correctly; if you have, the general user
probably shouldn't have access to the complex information in
the first place: either they can't use it (e.g., lack security
clearance) or shouldn't try to use it.

<<In a very large documentation set, however, users are more
likely to be browsing, looking for a particular piece of
information.>>

I wouldn't make that distinction. When I browse, I'm looking
for specific information. I won't browse docs just for the hell
of it unless I'm trying to learn how they created the docs so I
can do it myself. Most users don't fall into that category. In
the sense you're using, browsing is a way of finding the
specific topic once (by navigation, indexes, or the search
function) they've gotten to the right part of the manual; I don't
know anyone who'll follow the "browse sequence" in online
help in the faint hope they'll eventually stumble across the
desired topic. Though I have used help systems for which
browsing would have been more productive...

<<I do know that my users tend to be graphical rather than
text-oriented--more likely to stop for a table or a diagram than
for text.>>

That suggests one very clear organisational strategy: use
appropriate graphics to differentiate between types of
information. For example (very simplistically), how about a
pen icon for drafting (CAD), and a machine tool icon for
manufacturing (CAM)? That's the sort of thing that might
help.


--Geoff Hart @8^{)}     Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

"If pro is opposite of con, then what is the opposite of progress?"--Anon.

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=