Re: structural navigation

AL,

I agree with your analysis, but the biggest problem the UA group has is 
that our only specified reference tree is the W3C DOM.  The DOM represents 
a DTD structure of a document, which typically  is not useful in its native 
form for the human navigation needs you describe.  The current HTML 
specifications are weak or silent on information related to how content 
should be rendered to users or structured for human use.  XML is even 
worse.  We have tried to expand on the interpretation of your analysis in 
the UA techniques document and make the types of features you outline 
possible through access to the DOM by assistive technologies.

Jon


At 03:07 PM 4/22/00 -0500, Al Gilman wrote:
>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
>

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
Division of Rehabilitation - Education Services
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Monday, 24 April 2000 09:47:59 UTC