Loading ...
Sorry, an error occurred while loading the content.

Re: [xml-doc] Re: Book-oriented misconceptions

Expand Messages
  • Larry Kollar
    ... Opposing data point -- when presented with a choice to read a book online or download it, I always scan the TOC to get a feel for what s in the material --
    Message 1 of 33 , Oct 1, 2001
    • 0 Attachment
      >> In extensive usability testing ...
      >> 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.

      Opposing data point -- when presented with a choice to read a
      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?
    • John Russell
      ... alternative ... in ... the ... querying would ... difference ... Querying does give a lot of flexibility, but in the end it s only giving something that a
      Message 33 of 33 , Oct 5, 2001
      • 0 Attachment
        --- In xml-doc@y..., mpriestl@c... wrote:
        > John Russell writes:
        > >Clearly you can write something in Docbook, and generate
        > >navigation maps 100% through querying. This is what I'm doing now
        > >with information that was originally book-oriented and we've left
        > >that same physical structure. How is the querying different
        > >from "inspection"?
        > By inspection, above, I meant creating a TOC automatically based on
        > nesting structure of the sections in the file. I'm assuming
        querying would
        > give a bit more flexibility, as you suggest above. That's the
        > 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-oriented
        > authoring inside a large print-oriented file, but it takes
        discipline that
        > 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 my
        > experience, when writers create nested topics (especially using
        > names like chapter, or appendix) little tell-tale signs tend to
        creep in.
        > Things like "In this chapter, we talk about..." oops. Or "Next, we
        go 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.

      Your message has been successfully submitted and would be delivered to recipients shortly.