Re: Proposed deletion of checkpoint on spawning windows

I think this is not as bad as unacceptable. What we want to achieve is the
continued orientationof the user. One of the suggestions Hakon Lie made for
dealing with multiple windows is to open new windows which then inheirt the
history of their parent. Opera behaves more like a traditional window-based
application, which keeps track of how many windows it has opened and what
they are, than explorer or netscape, which abandon responsibility for this in
favour of the Operating System.

It seems to me that Hakon's approach would satisfy the requirements, so long
as it was clear that the user knew they were being transferred to a new
window. After all, this is how prompting and alerts often happen, and that
does not, of itself, cause a problem (there are good an bad
implementations...)

Charles McCN

On Wed, 25 Aug 1999, Al Gilman wrote:

  The proposed change is unacceptable.
  
  It is not enough, in general to only inform the user.  The way the
  currently active set of processes grows in a GUI environment is not
  suitable for an eyes-free enviroment where the memory of the user, and not
  the imagery of the screen, retains the overview of "what is there."
  Therefore stricter user supervision of the proliferation of concurrent
  entries in "what is there" is required in the eyes-free environment than in
  a GUI environment.
  
  Simply turning off the opening of new windows is too severe, too, as you
  have noted.  But any action that does not come with a guarantee that use of
  the browser "back" command will accomplish an "undo" of that action is an
  action of a hightened severity class and the user should be able to set "on
  confirm only" or "disallow" as policy rules for that class. 
  
  The whole issue of concurrent process management is a can of worms that we
  have not gotten to the bottom of.  Last I knew there was not a consistent
  philosophy between DHTML and SMIL.  But a laissez-faire "fire and forget"
  policy where a document can cite a URI in a link, and when the user
  activates the link the author's recovered content of the new document
  orders the initiation of a new user-interaction process without its being
  reversible by the standard navigation error recovery mechanism of the
  browser back button means that the browser has ceded too much control to
  the author in a way which fails to faithfully serve the interest (and in
  the case of PWDs acute need) of the user.  [Sentence too long; you can edit
  it.]
  
  This is related to generic control of link-related actions under discussion
  between WAI-PF and X-Link working groups.
  
  Al
  
  At 11:39 AM 8/25/99 -0400, Ian Jacobs wrote:
  >Hello,
  >
  >In [1], checkpoint 5.11 reads:
  >
  >    Allow the user to turn on and off support for spawned 
  >    windows. [Priority 1] 
  >
  >In SYMM Working Group teleconference, we discussed
  >the meaning of this checkpoint. There are many instances
  >where opening a window is vital to the functioning of the
  >page (e.g., when, from a SMIL presentation, one opens
  >an HTML media object in a new window. Note that SMIL
  >players do not currently render HTML themselves.). 
  >
  >I believe the intent of the checkpoint is to prevent
  >disorienting changes to view, selection, or focus,
  >a goal covered by checkpoint 10.1:
  >
  >   Provide information about document and view changes 
  >   (to the user and through programming interfaces).
  >
  >Note: I propose adding the words "focus" and "selection" 
  >explicitly to 10.1.
  >
  >While turning off spawning of windows may be one solution
  >to avoiding disorienting changes in views, I don't think
  >it's an effective solution since so much functionality
  >may be lost. Instead, in the techniques, we should tell
  >user agents how to inform users of changes to the view.
  >For instance, by emitting an audio cue, by speaking
  >"title" text of the linked resource along with some
  >warning, etc. 
  >
  >I propose deleting checkpoint 5.11 and ensuring that the
  >goal of not disorienting users is clearly stated in 10.1.
  >
  > - Ian
  >
  >[1] http://www.w3.org/WAI/UA/WAI-USERAGENT-19990809 
  >-- 
  >Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
  >Tel/Fax:                     +1 212 684-1814
  > 
  

--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, 25 August 1999 13:09:46 UTC