Re: direct and spatial mapping to functionalities

At 09:36 AM 10/5/99 -0400, Ian Jacobs wrote:
>Al Gilman wrote:
>> 
>> At 02:10 AM 10/5/99 -0400, Marja-Riitta Koivunen wrote:
>> >
>> >>
>> >>2) Users need two types of access to user agent functionalities:
>> >>   serial (with context) and direct (e.g., activated through the
>> >>   keyboard, voice, or mouse). We don't have a checkpoint about
>> >>   this, although I did include prose in the 4 October version of
>> >>   the spec (in the intro) distinguishing types of access.
>> >
>> >I don't undestand serial? I think we have spatial mapping with pointing
and
>> >direct mapping without pointing. And both are important. It is important
>> >not to be be forced to point because some users have great difficulties
>> >with this.
>> 
>> AG:
>> 
>> a) Ian: 'serial' is not a good term here.  Think in terms of the intrapage
>> navigation flavors: sequential, hierarchical, and direct.  What we are
>> talking about is the same process-structure flavors 
>
>Yes, I agree.
>
>> to get to "an action in
>> the UI or page has been commanded" as opposed to "a point in the page has
>> been made the current [focus | point of regard]."  The classical GUI mode
>> is somewhat hierarchical with verbs collected under menus.  One is not
>> usually sequencing through all available verbs in the GUI to find one.  So
>> 'multistep' vs. 'direct' encoding of the comands is probably better
>> terminology to communicate what is going on. 
>
>The terms I used in the 4 October draft [1] were "contextual" and
>"direct":
>
><BLOCKQUOTE>
>
>  User agents should provide access to functionalities in different
>  ways to meet the skills and needs of different audiences:
>
>  * Contextual access (e.g., through cascading menus, 
>    through help systems, etc.) helps users with cognitive 
>    impairments and any users unfamiliar with the tool.
>
>  * Direct access (e.g., through keyboard or voice shortcuts)
>    helps some users with motor limitations and speeds up
>    use by experienced users.
></BLOCKQUOTE>
>
>> But we have the following
>> _three_ axes mixed together in the discussion so far: 
>
>1) >keyboard vs. pointing device for selection and activation; 
>
> Checkpoint 1.2 requires device-independent activation (there's
>            no mention of selection, but that's covered by 1.1).
>
>2) spatial layout vs. named hierarchy for orientation to the range
>   of verb options; 
>
>   So it sounds like we need to say something about being able
>   to access user agent functionality along the following
>   "axes of independence" (do I sound like Al here?? ;-):
>
>    a) Device-independence
>    b) Spatial-independence (I don't want to have to move a pointer
>                             in a 2- or 3-dimensional space).
>    c) Temporal-independence (Don't make me activate within 2 seconds).
>
>   Am I getting it? Al, how does that relate to your thought below 
>   (refer to "This leaves me thinking...".

This is really good, but I don't yet feel it is the final image.

I am nervous about the "device-independent" term.  It always sounds to me
too much as though one has to be able to do it without any device, and that
is not, AFAIK, the requirement.  The point is to have enough device options
so that there are no single-point failure modes.  No single sensory or
cognitive capability will put you out of the ballgame if it is weak or absent.

The problem with the "spatial" category is that its failure modes are
spread over sensation and cognition.  GUIs fail the blind on sensory
failure: the screen display is supposed to suffice to provide orientation
and context for the mouse clicks, and it doesn't.  On the other hand, I
consider that navigation plans or menu trees that are too multi-step for
people to follow are a cognitive failure mode related to navigation
coordiates or orientation.  These fail because the user cannot maintain
grok lock on the coordinates or orientation by which one is supposed to
find the desired action opportunity (c.f. menu verb or web page hotspot).
"Which menu would they hide that under?!!"


All of this is to say that we don't have to fill a three-dimensional space
with the axes you listed with available methods at all coordinates.  

Device independence is actually a go-between for the fact that each device
class has associated sensory and/or motor performance requirements to be
effectively usable.  Dimensionality -- geometry independence -- is also a
placeholder for a variety of failure modes where the user is unable to deal
either with the sensory or cognitive demands of the interaction world.
There is always some geometry to the interaction world, even if the primary
display medium is audio generated from speech synthesis.

What I see as the requirement is that the UI needs to be adaptable in
enough ways so that it can be profiled to avoid selected performance
limitations of the human user.

At this point I wouldn't want to commit as to the coordinates of a
Cartesian space of UI modalities or human performance that we have to care
about.  There are at least sensory, perceptual, cognitive and motor demands
of any interaction world.

I think we need to start with a look of "how we change the UI to work
around disabilities" and see a) what gets substituted and b) what
performance degrees of freedom get taxed to give relief where there is a
problem.

Direct commands give some relief in terms of actuation repetition or count.
 The can be arranged to tax either cognition (speech user remembers all
those Jaws commands) or sensation/perception (touch-screen applications
where waiter enters meal order).

That's not a polished set of axioms, but I hope it helps.

Al

PS:  The temporal thing is very real.  Doubleclick is great but not
universally doable.

>
> - Ian
>
>3) flat command list vs. hierarchical menus (multistep dialog).
>
>   Only the prose quoted above addresses this design issue.
> 
>> b) Marja: You say some people have trouble with pointing.  I thought that
>> one group that most wants a flat command list with many symbols but direct
>> activation from the long list are those who have trouble completing any
>> input action.  So they want to get to the bottom line with a minimum of
>> steps.  There are other people who have problems with pointing devices but
>> can type a mile a minute.  The latter group can use MouseKeys and the menus
>> work fine, or use the keycodes for the hierarchical descent through the
>> menus.
>> 
>> This leaves me thinking that the group that needs direct versions of
>> commands the most is not "those that have trouble with pointing" but "those
>> that have trouble performing any UI action, be it a keypress, mouse move,
>> mouse click, etc.."
>> 
>> Al
>
>[1] http://www.w3.org/WAI/UA/WAI-USERAGENT-19991004 
>
>-- 
>Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>Tel/Fax:                     +1 212 684-1814
>Cell:                        +1 917 450-8783
>

Received on Tuesday, 5 October 1999 17:09:25 UTC