Re: Proposed deletion of checkpoint on spawning windows

No.  This leaves the user with too much garbage-collection liability.
Telling is not enough; the system must recognize that it opens new
processes under the user's permission and it is at the user's discretion
how closely they wish to hold that permission-granting.

Living with a littered desktop is easy in a GUI world.  I do it in hardcopy
all the time.  It is not a condition that an eyes-free user can operate in;
her environment has to be neater and more tightly controlled.  The maximum
degree of user control needs to be the base level and shortcuts added over
that; not the other way around.

Al

At 01:09 PM 8/25/99 -0400, Charles McCathieNevile wrote:
>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:34:25 UTC