Re: Proposed deletion of checkpoint on spawning windows

At 07:55 PM 8/27/99 -0400, Ian Jacobs wrote:
>Al Gilman wrote:
>> 
>> The basic requirement is that the user must be able to maintain control of
>> the composite process. 
>
>The proposal was to push control of spawned windows (5.11
>of [1]) to checkpoint 10.1: 
>
>   10.1 Provide information about document and 
>        viewport changes (to users and through
>        programming interfaces).
>
>If I understand, this doesn't satify your basic requirement 
>since it only involves notification (and not decision-making).
>
>[1] http://www.w3.org/WAI/UA/WAI-USERAGENT-19990809/
>
>> People's recognition memory far exceeds their recall memory.
>
>Yes, I believe I've heard that somewhere, but I can't
>remember where... <wink>
>
>[snip]
>
>> systematic means for user supervision of process
>> sprawl to manage complexity must be incorporated throughout as 
>> built-in principles of operation.
>
>This suggests to me a guideline about user control of "processes"
>that would include checkpoints about script execution, window
>changes, form submission, etc. I'm afraid to go there. Do you have
>any creative suggestions for how to stop short of a comprehensive
>plan for managing process sprawl and cover the 5.11? (Yes,
>I'm asking for a proposal.)

It's not all the same thing.  I don't believe that scripts per se run in
detached processes and maintain a concurrent window.  Form submissions (I
hope it's still this way) are heavyweight transactions and there should
already be language in the guidelines indicating that the user has to be
able to require that they be handled with extra care (see Gregory's issue
-- was 10.6 I think).  Form submission is defined as submitting a
transaction to a server process, so it does not increase the number of
processes that the user is accountable locally on the client node.  So
here's a rough swing at language:


Possible language:

[normative]

Allow the user to manage the proliferation of separate navigation cells.
When the user's locus of interaction is moved into a new navigation cell,
disorientation may result.  If one cannot return from following a link by
the browser 'back' function, the user's control of the interaction process
is violated.  Moving between different navigation contexts and particularly
spawning new cells of navigation context should be controllable at
user-selectable levels.  The fineness of control policy selectablility
should be roughly as follows:

a) alert but don't wait -- for example by a sound.

b) alert and wait -- for example by a popup message which requires
acknowledgement before the interaction starts up in the new window or other
context.

c) request confirmation -- popup dialog equivalent, but there are both OK
and CANCEL actions available in the intermediate buffer step of the transfer.

[informative -- goes in document set somewhere]

Windows and frames are local navigation cells that are best understood
hierarchically, i.e. orientation involves knowing which one you are in and
what you can do in terms of navigation within or between such navigation
cells.
People operating with no visual display or a reduced viewport into the
current process set are more dependent on what they can remember for
maintenance of orientation.  In this case it is necessary to have services
which help them maintain awareness of where they are, and what other places
they could be.  Part of helping them keep track of this is allowing them to
keep the set of active processes from growing too large.

In particular, the normal browse process is very dependent on the browser
'back' function for the user's maintenance of control.  Opening a new web
page in a new window, when it breaks the navigation path back via the
browser 'back' operation, is a violation of what the user should be able to
assume as the terms and conditions associated with following a link.  Where
the normal terms and conditions are going to be violated, it is
particularly important to warn the user and allow them to cancel the
pending change.

>
> - Ian
>
>P.S. I paraphrase you here: "If you won't be able to undo a change
>with the back button, you should be prompted for the change." That
>is interesting and I wonder how we might integrate it into the
>guidelines.
>

The whole thing could be described as "provide clear _and stable_
navigation mechanisms."  Orientation requirements are derived from the
'clear' part.  If you need to reset what the user is remembering as their
navigation options, it undermines the 'stable' part.  Stable navigation is
the topic where one finds the fact that link-following normally implies
"can be reversed with browser 'back' funtion."

The stability of web navigation which is provided by the browser 'back'
function is one of the fundamental things that makes the Web work.  The web
works with half-explained links because it is easy to go back when what you
get is not what you expected. 

[Notes to the workign group -- not intended for the document:]

There is a legitimate question how much of this functionality is and should
be provided by the operating system, and I am open to learning about how
different operating systems handle this.  But the browser is responsible
for sustaining the user's understanding of where they are when changes
arise from link activation or from script action.  Notification and
confirmation should be applied in rough proportion to the discontinuity in
the forward-looking context of navigation possibilities.  Continuity is
measured by how obvious the new repertory of navigation options is, given
the old repertory and the user action that was taken.  [This establishes
the derivation trail back to the root principle of "the system response to
user action should be predictable."  In this case, if changes in available
navigation options are not obvious, the predictability principle has been
violated.]

Al


>
>
>
>
>
>

Received on Sunday, 29 August 1999 14:41:23 UTC