Re: Grouping and Chunking -- Jared Spool

At 01:26 AM 2000-07-24 -0400, Harvey Bingham wrote:
>2.2. Table of contents structure and substructure can show chunking.
>
>HB: particularly if the table of contents can be collapsed/expanded as
>a dynamic user option, though starting with the collapsed form has the
>same problem with the too-general chunking naming.
>
>2.3. "You are Here" indication within chunking hierarchy, repeating the
>chunk names was not so useful as expected.

AG::

Did they just use the name used to distinguish the chunk within it
immediate parent, or did they use the full descent path through the
hierarchy to the current chunk, or what?  Usually the chunk name is
authored to be read in the context of the chunk name of the parent and
siblings.  That is to say the section title normally depends on the context
of the table of contents to be definitive.  Not ready to be read in isolation.

This is similar to what Scott Luebking found with rote repetition of the
full descent path for table cells.  He wound up giving the user the ability
to tailor the context cues and there was a definite tendency to like a
sliding scale of lots of cueing initially and little later on.

My thinking at the moment:

* If you are going to expose more than one page as a composite or
systematic resource (this can be at the site or network or "working folder"
level) you should support some sort of table of contents method.  Actually
a type spec for pages that incorporate pro-forma packaging such as is
typically what a page starts with would help, too.  Contents and conventions.

* For a given table of contents structure, there is a rationale for that
structure in terms of an information model of the domain covered in the
material.  In other words, we need to apply the "if this table of contents
is the answer, what was the question" transform to the table of contents.
Turn the table of contents into a) a table of contents extractor query and
b) keyword, linking, etc. marks on the component items in the content
structure which would enable the query to reconstruct the table of contents.

* Another image or conceptual scenario:  Letting the user edit the "like
this" property syndrome used in pursuing a "more like this" query.  There
are three ways to deal with context for a given chunk: the history path by
which the user found the chunk, the hierarchical structure in which the
author indexed the chunk, and the seach space of other web resources which
address topics similar to what is addressed in this chunk.  The explicit
marking of the topic and dependencies of the chunk so as to make the table
of contents reproducible by algorithmic extraction is probably how to
identify what the user actually wants most to know about "where am I."
This is the common core of chunk information that is common across all
three ways of backing off to gain perspective.

If chunk metadata were proofread by the information resource designer
through both of the above two scenarios: automatic extraction of Table of
Contents and default search properties for a "more like this" query, I
think you would have good chunk characterization as far as the [minority
use, i.e. on request only, e.g. as a preamble to the context-sensitive
'right button' menu] user's need for orientation to the chunk is concerned.

Al

Received on Monday, 24 July 2000 12:19:48 UTC