Re: From talking to developers...

My new comments interspersed and marked CMN (my old ones all start with
checkpint x.y)

On Fri, 4 Feb 2000, Ian Jacobs wrote:

  > > Checkpoint 2.2: For presentations that require user interaction
  within a > specified time interval, allow the user to configure the time
  interval > > Does a pause function satisfy this?
IJ  
  The note in the checkpoint says it does. Was the question whether
  that really addresses the issue?

CMN Actually this one was raised in a rushed look through the checklist. As I
recall it wasn't clear that pause was sufficient.
   
  > Checkpoint 3.3: allow the user to turn on and off rendering of video
  > 
  > In a window-based environment, is it satisfactory to hide the rendering
  > window, or does there have to be control over the video rendering
  > separately to other parts (e.g. caption track)
IJ  
  My first reaction is that hiding does suffice (the issue is distraction,
  isn't it? Not one of performance where you might want to stop the
  processor from handling video). If the caption is part of the video
  (i.e., a single track with both), I don't know how you could still
  have the captions if you turn off the video. If there are separate
  tracks, you should be able to view captions alone.
   
CMN This sounds sensible to me.

  > Checkpoint 4.5: Allow the user to slow the rate of audio, video and
  > animations
  > 
  > In the case of animations, does this mean a requirement to step through or
  > slow the speed as well as being able to turn it off? (My own thought is
  > yes - if there is content in an animation it is important to step through
  > it).
IJ 
  Yes. One question: do you think it's a violation of a spec (e.g.,
  GIF) to control the rate of the animation? Note that our applicability
  clause would cover this case; the user agent doesn't have access to
  the properties of the content (i.e., might not be able to regulate the
  speed). 
  
CMN I don't think it is a violation of the spec to control the final
behaviour, since we are not altering the actual content, and since it is
still possible to render it as specified where that is desired. Except in a
live presentation, where they only possiblity may be to use a stop-motion
approach (leading, at the right speed, to that rather cool effect discos
achieve with strobe lights, but presumably at even lower speeds to an
improvement) there is no reason the technology cannot control the rate of
presentation. It is a particular piece of work required of the devlopers, and
it can be complex in cases where there is acompanying audio.
  
  > CHeckpoint 7.2: For user agents that offer a browsing history mechanism,
  > when the user returns to a previous viewport restore the point of regard
  > in the viewport.
  > 
  > In a timed presentation does this mean return to the time that the user
  > was at (where possible - it wouldn't necessairly work in live streaming
  > for example)
IJ  
  If the technology doesn't allow, then the requirement wouldn't apply.
  Otherwise that's a good point and should be mentioned in the techniques.
   
CMN The technology allows it if it is built that way (the technology can be
built to buffer endless amounts of live stream as well, but only at
considerable cost). The question is when it is appropriate to go back to the
middle of something and when it is appropriate to start it again, or let it
keep running and return to its new state.

  > Checkpoint 1.5: Ensure that the uesr interfaces provides information
  > through redundant output modes
  > 
  > This could be worded a bit more clearly.
IJ  
  Any suggestions?

CMN Ensure that user interface information is available in a
device-independent manner (I'm not sure that's ideal either, but it seems to
convey the requirement. THis seemed really incomprehensible the first time I
looked at it, and my first guess at what it meant turned out to be wrong.)
   
  > Checkpoint 6.2: Conform to W3C specifications when they are appropriate
  > for a task
  > 
  > It is a bit unclear how to verify when the specification is appropriate to
  > the task. Is the requirement to conform to the specification, or is it to
  > use appropriate W3C specifications for graphics if you render graphics, or
  > is it both requirements? (Actually, if it means use W3C specifications
  > does it mean exclusively, or does it mean include handlig of those?)
IJ  
  I think it's both. I propose this clarification:
  
     "Use and conform to W3C specifications when they are 
      available and appropriate for a task."
  
  We could drop the conformance part, but the whole reason we're
  pushing them is that they promote interoperability and have
  accessibility
  built-in. If you don't conform, what's the point? I do recognize that
  conformance is hard in some cases. It makes that the conformance part
  is P2. 
  
CMN I don't think conformance is P2 becuase it is hard. I think there may be
a case that it is P2 becuase it is possible to provide accessibility without
it (which is how P2 is actually defined - in terms of end user requirements,
not easy development paths)

IJ  As to the exclusive part, I don't think that's implied. However, for
  checkpoint 11.1 we do make the clarification that there must be "at
  least one"
  version of the documentation that's accessible. We might make a similar
  clarification in the checkpoint or a note after.  
   
  > Checkpoint 10.7: Allow the user to configure the User agent through a
  > profile
  > 
  > It is not clear what the minimum satisfaction is - allowing the user to
  > configure their name? The window size? at least both of those? Use a local
  > CSS stylesheet?
IJ  
  That is true. A couple of ideas:
  
  1) Demote to P3 and the text as is.

CMN I think that is a terrible idea. If it is unclear, then changing the
priority will not make it clearer, it will just give people the justifiable
understanding that P3 requirements are things that were never properly
specified and may as well be ignored.

IJ
  2) Identify the key requirements, for example presentation and input
     configuration. 

CMN This sounds like a good approach
  
  > 
  > Checkpoint 8.4: Make available to the user information that will help the
  > user decide whether to follow the link.
  > 
  > Does this mean make available all the information the tool has? Or just
  > some of it?
IJ  
  Since it's a P3, why not all of it?
  
CMN
Because if I happen to meet the other P3s, and happen to allow the user to
find out the expected size of the resource (where available) then I could
claim triple-A conformance for nothing, without providing much benefit. What
does the user need? (type, filename, whether it is local or not?)

  > 
  > Checkpoint 10.8: Provide default input configurations for frequently
  > performed tasks
  > 
  > There is by definition a default input configuration. The wording of the
  > checkpoint itself (rather than the additional information) should make it
  > explicit that what is required is a "simple, obvious, rapid method" to
  > activate the functionality.
IJ
  I propose the following clarification:
  
  1) I think "a default input configuration" makes more sense than
  "default
     input configurations" since there is only one default. Even if
  several
     modes may be covered (voice, keyboard, etc.), there's still only 
     one default input configuration.
  
  2) Every browser comes with a default configuration. What are we
     requiring exactly?
  
     I propose that 
  
      a) Either we drop this checkpoint, or
      b) We make the requirement much more specific. For example:
         "Ensure that the default configuration allows the user to
  navigate
          content and user interface controls simply, obviously, and
          quickly." 
CMN I prefer the secon solution, but I think we should try to specify it
better. My attempt that I would like to see improvements on is
  "ensure that the most often used functions are the most obvious and easily
actvated in the default configuration"

Charles McCN

Received on Sunday, 6 February 2000 06:41:43 UTC