W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2000

structural navigation

From: Al Gilman <asgilman@iamdigex.net>
Date: Sat, 22 Apr 2000 15:07:26 -0500
Message-Id: <Version.32.20000421113126.00f1df00@pop.iamdigex.net>
To: w3c-wai-ua@w3.org
Cc: w3c-wai-gl@w3.org
I admitted on the UA call yesterday that I am thinking of something other
than just the parse tree as the definition of structural navigation for the
user agent dealing with markup languages and similar media that use some
sort of syntax to fold document structure into a stream for sharing.

It takes a long time to write a short letter.

Briefly, I believe that 

a) the tree the navigation walks needs to be different from the parse tree
or it will be too sparse and essentially as un-usable as the source view.

b) some method to generate a navigation tree from the DOM or parse tree is
readily achievable.  That is to say, a method which will reliably overcome
the above problem is readily achievable for the programmers who do
browsers.  There is an existence proof in the form of a power toy on the
Microsoft website.  What is dead easy is to get it improved to where it is
worth using.  What is not hard is knowing just when to stop trying to do
better.

c) the essence of a good navigation tree is that

(1) it tells you about high spots and standalone resources embedded in the
flow

(2) it tells you when you enter or leave a region where the discourse
changes gears, such as tables and forms.  The precise rule here would be
something like "mark changes in topic or tenor of the discourse."  Forms
actually have to be especially carefully marked because of the severity of
the consequences of error; not only if the construction rules of the
presentation are different.  The tenor of the discourse has changed because
of the possibility for the user to expose themseves to monetary and privacy
consequences, not so much because the information or display side of the
discourse has changed much.  On the other hand tables have to be obvious to
the audio visitor because the requirement to remember a context has sudenly
turned into two dimensions of context, and not just a table of contents tree.

(3) to the extent that the above objects don't do it, the structure divides
up the total playing time of the audio presentation of the content into [a
hierarchy of progressively refined] manageable-sized chunks.  There have to
be sub-part boundaries well marbled throught the flow of total playing
time.  Anything that the author has already supplied in terms of headings
marking breakpoints in the flow of the story is taken first, of course,
before anything is synthesized.

(4) add/remove grouping from the tree to minimize the average time for a
visit, including both (aa) walking the tree to a chunk and (bb) playing the
chunk until the subject you were after has been found and completed.  This
is for a range of users who have more or less control of the vocabulary
used to explain the topics per subdivision in the hierarchical view of the
contents.  One adds grouping, for example, to speed the tree walk when
there is stuff up front which is not likely to be where you actually want
to spend you time.  See Amazon.com rewrite example for the concepts of when
to add and when to remove grouping in the reflow of the tree to get it
tuned up for navigation.


http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0199.html

d) we have a current base of users that are already working this way in the
consumers of DAISY2 talking books.  The Navigation Center in the digital
talking book architecture is the working example of a navigation tree which
is a scrubbed derivative of the parse tree for the full contents.  The
DAISY/NISO documents concerning how the navigation functions should work,
and what they have told me privately about which the core functions are
[streaming automatic play (forever, i.e. to end of book), and tree walking
the Table of Navigation] are clear and compelling enough so that we don't
need to be fishing in the dark.


e) for some more technically agressive ideas, but ideas on how simple the
problem is in the end, see also


http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2000Apr/thread.html#46

[Warning -- you have to trace back manually from Len's message at the root
of the nominal thread in the archive to a message of mine that he was
responding to, in order to get the whole set of ideas.]

Al
Received on Saturday, 22 April 2000 15:02:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:04 GMT