Re: [xml-doc] Re: Book-oriented misconceptions
>> In extensive usability testing ...Opposing data point -- when presented with a choice to read a
>> one over-riding conclusion has been that users NEVER
>> user the Table of Contents.
>So true, so true. I have seen more people downloading entire books
>for printing than I have jumping to the corresponding online TOC.
book online or download it, I always scan the TOC to get a feel
for what's in the material -- and whether it's worth downloading
in the first place. If only small parts of it look useful to me,
I read those parts online and possibly grab a printout from the
browser. If the entire document interests me, I snag & print the
I think it's safe to conclude that some people are more comfortable
reading online, and others are more comfortable holding a dead tree.
And for many, it just depends on how much info they need to absorb.
A ToC doesn't have to represent a linear progression of chapters,
although that's what it usually does (and maybe that's why it doesn't
map well to hypertext presentatations) -- it could present topics by:
- topic type (e.g. procedure, background, reference)
- user type (e.g. end user, administrator, power user, developer)
- usage phase (e.g. installation, operation, troubleshooting)
I'm probably missing other ways, but you should get the idea.
Plus, you don't have to limit a ToC to only one presentation.
Assuming the metadata is there for searching and indexing, you
can automatically generate as many different ToCs as you want
using the metadata.
Larry Kollar, Senior Technical Writer, ARRIS
If a cable modem is caught in an SNMP trap,
will it chew off its coax to get free?
- --- In xml-doc@y..., mpriestl@c... wrote:
> John Russell writes:alternative
> >Clearly you can write something in Docbook, and generate
> >navigation maps 100% through querying. This is what I'm doing nowin
> >with information that was originally book-oriented and we've left
> >that same physical structure. How is the querying differentthe
> >from "inspection"?
> By inspection, above, I meant creating a TOC automatically based on
> nesting structure of the sections in the file. I'm assumingquerying would
> give a bit more flexibility, as you suggest above. That's thedifference
> between inspection (as I used the word above) and querying.Querying does give a lot of flexibility, but in the end it's only
giving something that a good writer could do anyway. I suggest that
the best way to figure out what queries to do is to look at stuff
that was done by good writers and trace back their thought
processes. How did they decide the threshold for including things?
Why does this subject get more attention than that one? And so on.
It's interesting that one of the trickiest queries to do -- I'm still
working on making it real-time -- is a recursive one that just
reproduces the same nesting order as in a book.
> It's certainly possible to do topic-orienteddiscipline that
> authoring inside a large print-oriented file, but it takes
> the DTD won't enforce or encourage.This idea of enforcing and encouraging leads to some other ideas.
Maybe that's another thread. I suggest that the best encouragement
and guidance for an author is to compare their information against
existing information: are my topics at the same level of detail, am I
using the same style, etc. And this is easy to do when working on
information that is "transcluded" :-) into a book structure.
> In myactual
> experience, when writers create nested topics (especially using
> names like chapter, or appendix) little tell-tale signs tend tocreep in.
> Things like "In this chapter, we talk about..." oops. Or "Next, wego on to
> introduce..." oops again.I've seen people run screaming from online information systems for
many different reasons, but never over things like this. So I'd say
this is far from the biggest problem around.
At Google.com, Salon.com, etc., I find a useful chunk of information
that ends by implying "if your interest hasn't been satisfied yet,
here is a preview of the next chunk or a summary of all following
chunks". That is, those links that show how many screens to expect
in the search results or multi-part article, maybe showing a title or
quotation from the following section. In some cases, it might not
even be a link yet if "Part 2" of the article is coming tomorrow.