Review of M. Rothberg's "Control and Configure" Comments, Also Sy nchronization Definition

Control and Configure - Review of M. Rothberg's Comments

I feel quite torn on this issue.
1. I would like to simplify things for developers, but I am not sure what
will be simplest for them in some instances.
2. I agree with Jon's interest in avoiding complications for developers and
focusing on the word "control" (I have pushed in that direction), but it
appears to me that checkpoint 10.7 ("For the configuration requirements of
this document, allow the user to save user preferences in a profile.
[Priority 2]") will not be helpful in bringing to bear configuration
requirements unless the term "configure" actually appears in the those other
checkpoints. If we really want developers to configure, I think we need to
say it in the specific checkpoint (of course, the developer still needs to
figure out what level of granularity, etc.) to use in developing the
configuration feature.
3. I agree with Al Gilman's concern about the hard distinction between
control and configure have offered a revised definition of "Control (and
Configure)" that attempts to soften the distinction. I have a general unease
about locking user agent developers into too rigid of a software model.
Nevertheless, I think there is a distinction to be made and if we are going
to use both terms, I think that we need to explain even more clearly what we
mean.
4. As I stated when I first read Madeleine's suggestions, I found myself
generally agreeing with her. In saying that, I guess that I am also saying
that it is probably not enough to say "control" only for some of these
checkpoints.

I hope that this is helpful. 

MR = Madeleine Rothbergs comments
(http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0354.html)
EH = Eric Hansen's comments.


MR: Here is my opinion on which checkpoints need a "static choice" (go to a
preference dialog somewhere and set a configuration option which then
applies generally) versus which ones call for the ability to control
dynamically (quickly change the content I'm looking at right now but don't
save the change as my new default, or maybe offer me a choice of whether to
make this my new default), versus which ones would be best served by having
both a default configuration set statically but also an easy way to control
dynamically.
========
MR: One checkpoint would be reasonably served by only dynamic control,
though I can see an argument for it having both configure and control:

MR: 4.8 Allow the user to configure the audio volume. [Priority 2]
This should be changed to "control" rather than "configure" or to both.
Configure alone is not appropriate because audio level varies greatly
between presentations and you don't want to dig through preferences dialogs
every time you want to change the volume. (In practice, multimedia players
generally make it easy to control audio volume. There tends not to be a
configuration choice. I think the SYMM group recently discussed whether
authors should be able to specify volume and ended up with the status quo,
which is that everything starts at 50%.)

EH: Generally agree. I think that control-only may be OK. This should be
Priority 1, thus yielding:
"4.8 Allow the user to control the audio volume. [Priority 1]"
An alternative would then be to split things out and say:
"4.8A Allow the user to control the audio volume. [Priority 1]"
"4.8 Allow the user to configure the audio volume. [Priority 2]"

Nevertheless if one splits them, then one has to have a better definition of
the terms.

========
MR: Here are 11 checkpoints for which I think "configure" is an appropriate
term:
====
UA Document: 
2.2 For presentations that require user input within a specified time
interval, allow the user to configure the time interval (e.g., to extend it
or to cause the user agent to pause the presentation automatically and await
user input before proceeding). [Priority 1]
EH: Agree to keep as is.
====
UA Document: 
2.3 If content available in a viewport has equivalent alternatives, provide
easy access in context to the alternatives. [Priority 1]
For example, if an image in an HTML document has text equivalents, provide
access to them by rendering them nearby, allowing the user to configure the
user agent to render them in place of the image, or allowing the user to
follow a readily available link to them.

EH: Generally agree that some kind of "configurability" is appropriate,
though I am not sure that we need to mention it. Would the wording be as
follows?

<POSSIBLE NEW>"2.3 If content available in a viewport has equivalent
alternatives, allow the user to configure how the alternatives are rendered.
[Priority 1]"
"For example, if an image in an HTML document has text equivalents, provide
access to them by rendering them nearby, allowing the user to configure the
user agent to render them in place of the image, or allowing the user to
follow a readily available link to them." </POSSIBLE NEW>

I wonder if to have such a requirement might be over-reaching. Maybe the
note about configuration should go in the techniques document. At the same
time, I wonder about why it is limited to "in a [single] viewport". But
perhaps it is OK.
====================
EH: Madeleine made no comment on checkpoint 2.4, but if the term configure
is mentioned in connection with checkpoint 2.3, then a checkpoint dealing
with configuration might also be added.

"2.4 Allow the user to specify that text transcripts, collated text
transcripts, captions, and auditory descriptions be rendered at the same
time as the associated auditory and visual tracks. Respect author-specified
synchronization cues during rendering. [Priority 1] 
Techniques for checkpoint 2.4 "

See my Part 4 of an old memo
(http://lists.w3.org/Archives/Public/w3c-wai-gl/1999OctDec/0165.html) for my
analysis of some of the configurations that might be presented.

I am not exactly sure the term "author-specified synchronization cues" is
exactly the best term. See comments below.

ADDITIONAL CHECKPOINT:

"2.4.A Allow the user to configure the synchronization between text
transcripts, collated text transcripts, captions, and auditory descriptions
and any other equivalents" [Priority 2]

Configuration of synchronization may be important when the size, duration,
or other facet of two or more equivalents threaten to limit the usefulness
of a presentation. 

==
Whether or not a new checkpoint is added, I think that it is important to
acquaint people with some of the synchronization issues that might arise. In
order to address this issues, I present a proposed definition of
"Synchronization" for the glossary. This is an "enhanced" version of the
definition offered an Part 2 of an old memo
(http://lists.w3.org/Archives/Public/w3c-wai-gl/1999OctDec/0165.html)

<Proposed Definition of Synchronization>

"Synchronization"

"Synchronization refers to sensible time-coordination of two or more
presentation components, particularly where at least one of the components
is a multimedia presentation or audio presentation {Note. The main or only
synchronization that may be needed for audio presentations is if captions
are required for audio presentations. That is another issue.}"

"For Web content developers, the requirement to synchronize means to provide
the data that will permit sensible time-coordinated presentation by a user
agent. For example, Web content developer can ensure that the segments of
caption text are neither too long nor too short and that they map to
segments of the visual track that are appropriate in length.

"For developers of user agents, the requirement to synchronize means to
present the content in a sensible time-coordinated fashion under a wide
range of circumstances including technology constraints (e.g., small
text-only displays), user limitations (slow reading speeds, large font
sizes, high need for review or repeat functions), and content that is
sub-optimal in terms of accessibility.

"The idea of "sensible time-coordination" of components centers of the idea
of simultaneity of presentation, but also encompasses strategies for
handling deviations from simultaneity resulting from a variety of causes. 

"Let us briefly consider how deviations might be handled for captions for a
multimedia presentation such as a movie clip. Captions consist of a text
equivalent of the auditory track that is synchronized with the visual track.
Captions are essential for individuals who require an alternative way of
accessing the meaning of audio, such as individuals who are deaf. Typically,
a segment of the caption text appears visually near the video for several
second while the person reads the text. As the visual track continues, a new
segment of the caption text is presented. However, a problem arises if the
caption text is longer than can fit in the display space. This can be
particularly difficult if due to a visual disability, the font size has been
enlarged, thus reducing the amount of caption text that can be presented.
The user agent must respond sensibly to such problems, such as by ensuring
that the user has the opportunity to navigate (e.g., scroll down or page
down) through the caption segment before proceeding with the visual
presentation and presenting the next segment. 

"Developers of user agents must determine how they will handle
synchronization challenges, such as:
 
"1. Under what circumstances will the "primary" presentation automatically
pause (e.g., the segment of caption text is more than can fit on the visual
display; the user wishes more time to read captions or the collated text
transcript; the auditory description is of longer duration than the natural
pause in the audio)?
"2. Once the "primary" presentation has paused, then under what
circumstances will it resume (e.g., only when the user signals it to resume,
or based on a predefined pause length)?
"3. If the user agent allows the user to jump to a location in a
presentation by clicking on a text equivalent (or some outline of it), then
do all rendered equivalents jump at the same time? Will one be able to
return to one's previous location (or undo the action)?

"Developers of user agents must anticipate many of the challenges that may
arise in synchronization of diverse equivalents.

"The term _synchronization cues_{checkpoint 2.4} refers pieces of
information that may affect synchronization, such as the size and expected
duration of equivalents and their segments, the type of element and how much
those elements can be sped up or slowed down (both from technological and
intelligibility standpoints), user preferences, etc."
<Proposed Definition of Synchronization>
========

MR's List from UA Document: 

4.2 Allow the user to configure font family. [Priority 1]
4.3 Allow the user to configure foreground color. [Priority 1]
4.4 Allow the user to configure background color. [Priority 1]
4.11 Allow the user to configure synthesized speech pitch, gender, and other
articulation characteristics. [Priority 2]
4.13 Allow the user to configure how the selection is highlighted (e.g., 
foreground and background color). [Priority 1]
4.14 Allow the user to configure how the content focus is highlighted (e.g.,
foreground and background color). [Priority 1]
4.15 Allow the user to configure whether the current focus moves
automatically to a viewport that opens without an explicit request from the
user. [Priority 2]
4.16 Allow the user to configure the user agent to limit the number of open
viewports. [Priority 2]
Some users may become disoriented when there are too many open viewports. 
Refer also to checkpoint 4.15, checkpoint 5.5, and checkpoint 9.3.
9.3 Allow the user to configure notification preferences for common types of
content and viewport changes. [Priority 3]
For example, allow the user to choose to be notified (or not) that a script
has been executed, that a new viewport has been opened, that a pulldown menu
has been opened, that a new frame has received focus, etc.
All of the checkpoints and discussion in Guideline 10.


EH: I think that I agree with all of these. I am not as sure about the last
entry (based on our discussion of some of the checkpoints in Guideline 10).
I assume then, that Madeleine wishes to keep all wording in Guideline 10 as
is.

In connection with checkpoint 10.7, I assume that the minimal case for this
would be to have one available profile beyond the user agent default
settings. Essentially, that is what I recommend.

10.7 For the configuration requirements of this document, allow the user to
save user preferences in a profile. [Priority 2] 
Note: This includes user preferences for styles, presentation rates, input
configurations, navigation, viewports, and notification. Users must be able
to select from among available profiles or no profile (i.e., the user agent
default settings). 
Techniques for checkpoint 10.7 

==========
MR: 
Here are 6 checkpoints which I think would be better off with both control
and configure. You may notice that the text after the first one (checkpoint
4.1) gives examples of both static and dynamic changes:

4.1 Allow the user to configure the size of text. [Priority 1]
For example, allow the user to specify a font size directly through the user
agent user interface or in a user style sheet. Or, allow the user to zoom or
magnify content.
4.9 Allow the user to configure synthesized speech playback rate. [Priority
1]
4.10 Allow the user to configure synthesized speech volume. [Priority 1]
7.7 Allow the user to configure structured navigation. [Priority 3]
For example, allow the user to navigate only paragraphs, or only headings
and paragraphs, etc.
8.5 Allow the user to configure the outline view. [Priority 3]
For example, allow the user to configure the level of detail of the outline.

Refer also to checkpoint 8.4 and checkpoint 5.4.
8.7 Allow the user to configure what information about links to present. 
[Priority 3]
Note: Refer also to checkpoint 8.6.

EH: I think that I generally agree with all of these. However, if we want
both terms then I think that we must see whether the same priority should be
assigned to both terms. Since Madeleine did such a good job on this last
task. Maybe she should take a crack at that.

===========================
Eric G. Hansen, Ph.D.
Development Scientist
Educational Testing Service
ETS 12-R
Princeton, NJ 08541
609-734-5615 (Voice)
E-mail: ehansen@ets.org
(W) 609-734-5615 (Voice)
FAX 609-734-1090

Received on Friday, 19 May 2000 17:46:33 UTC