Re: Discussion of checkpoints 7.6 and 7.7

The minimum repair of 7.7 to accomodate the change in 7.6 is simple.  It
could take either of the two forms

<NEW1>
7.7 Allow the user to configure this structured navigation.
</NEW1>

or 

<NEW2>
7.7 Allow the user to configure the structured navigation required in
Checkpoint 7.6.
</NEW2>

If you want to include some clarification, it could be tested with the
group to see if the following is considered to be the same sense as before:

<NEW3>
7.7 Allow the user to adjust the kinds of restart-points which are exposed
as available destinations in structural navigation.
</NEW3>

All the other issues you raise are new business, not what is required in
7.7 to accomodate the change in 7.6.

Discussion (personal opinions):

1.  Minimum standards for configurability

It is hard to set any minimum-requirement level for 7.7.  Depending on the
amount of investment in code and media savvy applied to the generation of
predefined navigation views by the UA implementer, user twiddling could be
entirely unnecessary.

Given some relatively inexpensive generic methods of constructing
structural navigation views (ranges of motion options), user adjustment
could be essential at a relatively-P2 level (all the benefit of 7.6 goes
away without it, for some users).

2.  What it is that can be configured

Here Jon had it nailed.

The dominant issue is the filter rules that determine the "structural"
subset of destinations which are reachable under the "structural"
navigation functions.

How these destination options are presented to the user (see checkpoint
8.6) and how motion to them is commanded (see checkpoint ???) are
configuration options covered under different checkpoints.

3.  Question using control/configure distinction in setting minimums, here.

The forced distinction between "control" (i.e. adjustment through the UI
that affect the current behavior) vs. "configure" (adjustments that may
have to be done out of line with a use session, but persist) is unfortunate.

The strongest user requirement is that they be able to adjust the UA
behavior somehow.  Whether it fits into the narrower categories of
"control" or "configure" as discussed above is secondary or tertiary,
relative to this requirement.

In the most usable implementation, and this is also quite common today,
there is not a lot of difference between the user interface to
current-session and next-session adjustments, aside from a prompt as to
whether the user intends the adjustment to be temporary/local or
global/permanent.

Al


At 01:34 AM 2000-05-13 -0400, Ian Jacobs wrote:
>Hello,
>
>Per my action item of the 11 May teleconference [1], please
>consider this proposed clarification to checkpoint 7.7.
>
>* Background
>
>In the 7 May Guidelines [2], checkpoints 7.6 and 7.7 are:
>
><OLD>
>7.6 Allow the user to navigate efficiently to and among
>    important structural elements identified by the author. 
>
>7.7 Allow the user to configure structured navigation.

></OLD>
>
>This version of checkpoint 7.6 is the result of discussions
>around issue 233 [3]. We modified 7.6 but did not modify its
>companion, checkpoint 7.7. 
>
>In discussions about minimal requirements for checkpoint 7.6, it
>became obvious that there are two aspects to this checkpoint:
>
>a) Navigation capabilities. How should the user be able to navigate?
>   A proposed minimal requirement is forward sequential navigation
>   of the elements identified in the next point.
>
>b) The set of navigable elements. A proposed minimal requirement is
>   all elements, except that when the author has provided information
>   about important elements (e.g., known according to specification),
>   that the default set be the important elements (i.e., less than
>   all elements).
>
>Here are some questions that may be asked about checkpoint 7.7:
>
>  Q1: What type of configuration is being required,
>      configuration of the navigation capabilities, the set
>      of elements, or both?
>
>  Q2: If about configuration of the set of elements, is the 
>      requirement to be able to choose any subset of the elements 
>      in the document? Or just from among some element types
>      (e.g., headings, forms, tables)?
>      How does the user agent allow configuration for
>      XML applications about which it knows nothing (as opposed
>      to HTML, where the user could choose from among some known
>      element types)?
>
>  Q3: Is the requirement that the user be able
>      to change the set dynamically (control) or only statically
>      (configuration)? Might there be a difference in priority between
>      a configuration reequirement and a control requirement?
>
>Proposal 1: Make 7.7 only about configuration and leave it a P3:
>
>   <NEW>
>   7.7 Allow the user to configure the set of elements 
>   navigable according to checkpoint 7.6.
>   </NEW> 
> 
>  However, refer to question 2 above.
>
>Proposal 2: Make dynamic control a P2 requirement that is part
>   of checkpoint 7.6. Structured navigation would include,
>   therefore, the ability to select whether to explore the
>   contents of an element. There might be two approaches to
>   this: 
>       a) A skip functionality. This is an additional
>          navigation capability beyond sequential.
>       b) Shrink/Expand subtrees. This option change the
>          set of navigable elements.
>
>   There are probably advantages to both. The ability to hide content
>   can help people get a better sense of a document's overall 
>   structure when they have more than serial access to it. 
>
>I don't consider these strong proposals and I look forward to
>input from the Working Group.

>
> - Ian
>
>[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0359.html
>[2] http://www.w3.org/WAI/UA/WD-UAAG10-20000507
>[3] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#233
>
>-- 
>Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>Tel:                         +1 831 457-2842
>Cell:                        +1 917 450-8783
>

Received on Wednesday, 17 May 2000 16:36:33 UTC