RE: Structure navigation within a document, re: Development Cost

Chuck, 

In a series of messages to the group in the last two weeks you describe
(as far as I can tell) the process the group works by, and then you claim
that the group has some other, fundamentally flawed process.

I suggest that if you listen to what happens in meetings and read the
background materials (minutes, agendas, list archives, etc) more carefully
you will find the process is pretty much what you claim we need. If you
have material suggestions to offer, please provide them through the list,
so they can be discussed in that forum, and thus dealt with efficiently
in the limited time available for teleconferences. 

In the case in point - the need for navigation of structure, I refer you
yet again to the minutes of the face to face meeting where it was
discussed briefly, and a placeholder was left for further discussion, to
the explanations given to you during the teleconference, and to the
discussion of the problem on the list. If you have in fact read all that
material, and the problem is still not clear, let me know and I will
ensure that a very simple and straightforward description of the problem,
which you find clear and comprehensible, is furnished. (I would also refer
you to the work done by Microsoft in the development of such features for
products which are designed to manipulate documents - I assume that there
is material which is internally available.)

If on the other hand you feel that the current process is so flawed that
the group is moving backwards, and the working drafts are successively
worse, rather than successive improvements, please point out to us where
the problems are most serious, again via the list, for the same reaasons
outlined above.

In the email quoted below you are asking for all solutions to go into the
document, yet time and again you claim that we should not just be throwing
things in willy-nilly since a large document is less likely to be read.
See for example the last paragraph of your message yesterday -
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0210 

I find it very difficult to understand what you feel is wrong. It seems
the point is so subtle as to require seemingly infinite discussion, with
negligible practical impact on the workings of the group, except that it
has the unfortunate side effect of removing some of our focus from our
actual goals. If there is a serious problem then this is important. But if
not then it is consuming an excessive amount of the group's time and
energy.

Charles McCN

On Wed, 10 Mar 1999, Charles Oppermann wrote:
[snip]  
  I'm trying to show that the process for developing checkpoints is flawed,
  not to eliminate this or any other existing checkpoint.  All ideas are
  valid.  If someone says they need a structure view of the document, web
  site, Intranet, or the Universe, that's fine with me.  Tell me why you need
  it (i.e.: what problem are you currently having that this feature solves)
  and then let's brainstorm on this feature and some other ways of solving the
  problem.  All those solutions should go into the document.
  
  -----Original Message-----
  From: Charles McCathieNevile [mailto:charles@w3.org]
  Sent: Tuesday, March 09, 1999 6:12 PM
  To: Charles Oppermann
  Cc: WAI AU Guidelines
  Subject: Structure navigation within a document, re: Development Cost
  
  
  These comments, and therefore my responses, seem only to address the case
  of navigiation within a single document, not of navigating a series of
  related documents.
  On Tue, 9 Mar 1999, Charles Oppermann wrote:
  [snip]  
    * It only helps document creators and editors, not users of the finished
  web
    site
  CMN:
  This is true. One of the two goals of the group is to describe how to do
  just that. It is in the context of what is necessary to help creators and
  editors of the documents that the priority of this particular feature
  should be assessed.
  
  CO:
    * It only helps those document editors using speech output.  It is of
  little
    help to users with mobility impairments or low vision people using screen
    magnifiers.  
  
  CMN:
  Actually the ability to navigate a structured tree, rather than having to
  work through a document in its complete form, is of specific benefit to
  people who have mobility impairments, for precisely the same reason - it
  enables the document to be traversed with much less work. In the case of
  magnified screens (and users with various types of cognitive disability)
  it is the ability to work with an overview of a document
  
  CO:
    * The degree that it helps those users is unknown and debatable
  CMN:
  While we could debate at great length the precise degree to which it
  helps, and while I expect in the course of our work on these guidelines to
  debate this and to refine our understanding, it seems that there is
  clearly value to accessibility. We have heard, as we could also deduce
  from a little thought, that the value is related to the complexity of the
  material produced. About which more after
  CO:
    * It's only meaningful in the cases where structure is important.  The
    feature would make little sense in products such as Microsoft Access,
  Excel
    or Project.
    * The feature already exists in Microsoft Word.  Does it need to be
    duplicated in FrontPage?
  CMN:
  Essentially, that depends on whether Microsoft regards Frontpage as a tool
  suitable for creating a structured document, or really only worth using
  for trivial pages. (Whether resources are available to justify its
  inclusion in these tools is a separate issue to whether there is a reason
  to put it there in the first place).  
  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Wednesday, 10 March 1999 19:34:27 UTC