- From: Al Gilman <asgilman@iamdigex.net>
- Date: Sat, 22 Apr 2000 15:07:26 -0500
- 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 UTC