Re: Proposed editorial changes based on Aaron Leventhal review

My proposal is for _A_ technique for doing this in a really cool and helpful
way (i.e. goes way beyond the P1 requirement of the checkpoint). That's why I
proposed it as a technique.

I explicitly suggested not changing the checkpoint. I still don't see how the
checkpoint fails in any way to cover your requirements a and b as written,
and that the proposed change would preclude the technique that I have
suggested.

Therefore I object to changing the checkpoint in the manner foreshadowed.

Charles

On Thu, 8 Mar 2001, Ian Jacobs wrote:

  Summarizing:

   - The proposal was "don't do the refresh"
   - Charles says that's too restrictive, since the UA might
     do the refresh and provide the user with a useful diff
     on demand.

  I still support the proposed change for the following reason:

   a) The user need is stability.
   b) The minimal requirement is "don't make the change unless
      the user says it's ok"
   c) Charles' proposal goes beyond the minimal requirement that
      I believe the checkpoint was meant to accomplish.

  (It would seem that the proposed change is not editorial.)

  I propose therefore that the minimal requirement is
  "don't do the change unless the user says ok" and that the
  checkpoint be changed to reflect that.

  The user agent can do more (e.g., provide useful diffs on demand),
  but I don't believe that's ever been the intention of the
  checkpoint.

   - Ian

  Charles McCathieNevile wrote:
  >
  > OK...
  >
  > My assumptions:
  > The point of the checkpoint is to keep the page stable if the user
  > desires. What the user agent does behind the scenes has more or less no
  > impact for accessibility.
  >
  > Where there are in fact changes being made to the page, it would be helpful
  > for a suer to know what they are to some level of detail lower than "the page
  > changed (somewhere, perhaps)".
  >
  > My conclusions (I figure we all have the same information to work on :):
  > The existing wording meets the accessibility requirement.
  >
  > Aaron's potential interpetation of it is a valid interpretation.
  >
  > Aaron's approach gives rise to the following technique for doing something
  > even better than just  not doing the refresh, viz:
  >
  >   Get the new version and find out what, if anything, has changed in it
  >   (simple markup-aware diff). Store that information, sequentially (a la a
  >   markup-aware version of CVSWeb, and Aaron probably has access to such).
  >   Allow the user to view that information at any time, as a seperate function
  >   to doing the update.
  >   This allows the user to work out what is going on in the original page, and
  >   then just find out what changes. (It is probably helpful to know if nothing
  >   changes, too). A couple of iterations of this should be helpful in deciding
  >   whether to turn off auto-configuration, and read changes from this function
  >   as desired, or turn it back on.
  >
  > A working example of sorts:
  >
  > Cricinfo - http://www.cricinfo.org - provides real-time (more or less) score
  > and commentary of cricket matches from around the world. If I use a standard
  > scoreboard, it auto-refreshes frequently, but it only changes a few parts of
  > the page - the current batsmen/bowlers, the current score, and the most
  > recent commentary in full and abbreviated form. The scoreboard for batsmen
  > who are already out, and for previous innings, remains unchanged.
  >
  > With a system like I have described, I could look at the scoreboard, and look
  > at the changes. This would enable me to find out which bits are being
  > changed, so I know which bits to look at again when the page is updated, and
  > which bits to ignore. Or I could decide to stop the autorefresh, and do it
  > manually when I want. (I often do this, and there is an option on the site to
  > get a version which does it too). Or I could start from a known page, and
  > read the changes made in subsequent (unseen) versions - updated commentary,
  > or scores...
  >
  > Cheers
  >
  > Charles
  >
  > On Thu, 8 Mar 2001, Ian Jacobs wrote:
  >
  >   Charles McCathieNevile wrote:
  >   >
  >   > Yes, I object. I am proposing to do something different with the same
  >   > information, for the reasons given.
  >   >
  >   > Also becuase I think it places operational constraints on the User agent that
  >   > may be in line with normal implementation methods but are not actually
  >   > enhancing the accessibility of the user agent, and may detract from it.
  >
  >   I'm sorry, I simply don't understand your point I guess.
  >   I thought the checkpoint has tried to say "Don't do automatic
  >   refreshes". Aaron said that wasn't clear. The proposed rewrite is
  >   supposed to be clearer.
  >
  >   I don't understand what the operational constraints you are talking
  >   about are.
  >
  >   I also didn't understand your technique.
  >
  >   Could you expound further on the source of your objection?
  >   My goal here, mind you, is only editorial clarification, not
  >   alignment with existing implementations, etc.
  >
  >    - Ian
  >
  >   > cheers
  >   >
  >   > Charles
  >   >
  >   > On Thu, 8 Mar 2001, Ian Jacobs wrote:
  >   >
  >   >   Charles McCathieNevile wrote:
  >   >   >
  >   >   > I don't see that there is a problem using the method Aaron suggested. It
  >   >   > would enable a user agent to seperately queue the changes to a document that
  >   >   > gets updated on the fly, which seems like a good thing since they could be
  >   >   > offered to the user who had asked for a page to stay still, as a seperate
  >   >   > item. It might be helpful to have this available, and I  can't see that it
  >   >   > breaks anything we need.
  >   >   >
  >   >   > So I would propose to instead add this as a technique.
  >   >
  >   >   Would you object to the editorial change?
  >   >
  >   >    _ Ian
  >   >
  >   >   >   Reference document 24 Feb 2001 draft [1].
  >   >   >
  >   >   >   1) Checkpoints 3.5/3.5
  >   >   >
  >   >   >      3.5 Allow configuration so that client-side content refreshes
  >   >   >      (i.e., those initiated by the user agent, not the server)
  >   >   >      do not change content except on explicit user request.
  >   >   >
  >   >   >   Aaron suggested that this might be interpreted as meaning
  >   >   >   "compare and see if the refresh changed the content or not".
  >   >   >
  >   >   >   Proposed change:
  >   >   >
  >   >   >      Allow configuration so that the user agent does not
  >   >   >      perform client-side content refreshes (i.e., those
  >   >   >      initiated by the user agent, not the server)
  >   >   >      except on explicit user request.
  >   >   >
  >   >   >   I propose the same type of change to checkpoint 3.6:
  >   >   >
  >   >   > [snip]
  >   >
  >   > --
  >   > Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
  >   > W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1 617 258 5999
  >   > Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
  >   > (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)
  >
  > --
  > Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
  > W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1 617 258 5999
  > Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
  > (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)



-- 
Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1 617 258 5999
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)

Received on Thursday, 8 March 2001 11:54:07 UTC