Re: mouse-grid selection for navigation [was: Re: Updated SVG comments document]

al wrote:
>
> At 1:25 PM -0600 11/24/04, Jon Gunderson wrote:
> This has to do with the keyboard navigation model for visual scenes.
>
> There is a suggestion in the current draft for incremental navigation
> by geometrical octants.  Comparable to the points of an eight-point
> compass rose: North, North-East, East, etc.
>
> But in voice command there is a precedent for another way of selecting
> something in a scene without a pointing device.  This is I believe called
> 'mouse grid' in at least one tool.

I think Heshem Kamel used a similar system with reasonable results, although
keyboard driven, in his IC2D drawing project at Berkeley.
>
> The rectangular canvass is divided into [nine] equal parts.
> The user selects one of these.
> The selected part is subdiivided again into a similar set of sub-parts.
> And so on until there is only one focusable item in the remaining
> region.  This is not only selected but gets the focus.
>
> The user can then activate the methods of this object.
>
> To my way of thinking this is a mode of operation that belongs ahead
> of any incremental navigation by quadrants as something for the
> mainstream players to support for all users (not relying on AT add-ons)
> as a means of ensuring access.

I think it depends on what we're trying to achieve.  The intention behind my
original directional system was to give the user a quick method to not only
move to an object, but to work out it's direction as well, and thus have the
spatial relationships between two objects exposed to them from which they
could ten associate semantic meaning.  This would also be possible in a grid
based system, but would rely on the user remembering which grid squares the
objects were in and then comparing the two vectors to get a direction,
before being able to evaluate it for semantic meaning, having said that,
grid squares would also make the distance available.  So, it comes at the
price of a higher cognitive workload, measurable using the NASA-TLX, for the
user.  There's also costs in terms of short term memory utilisation, as two
of the five to nine chunks that Miller said we have available in our short
term memories, would be used to store information about the vectors of the
objects.  This decreases the capacity a user would have to store information
and meaning which they derived from the diagram.
>
> It affords a systematic way to reach any 'enabled element' to use the
> UAAG term.  And it builds a breadcrumb trail that one can understand
> without seeing the visual display.
>
> It is definitely quicker with vision, but it has the advantage over
incremental
> navigation by quadrants in that it provides a comprehensible way to
> sweep through all enabled elements in the scene by parts.

Yup, it's a nice systems focused way to do document exploration, but comes
at a cost to the user.  The ultimate question, is whether a user wants to
examine the document with a view to extract meaning, or do they just want to
know what's there  I suspect that both are valid use cases, with a general
sweep probably being carried out initially, then the user homing in on
different parts to evaluate the diagramatical elements and their encoding
mechanisms for semantics.
>
> Think of this as a repair structure for a scene constructed with no marked
> or discernable structure.
>
> Questions:
>
> Did the User Agent group consider this functionality and reject it for
some
> reason?

No.  It seems a good suggestion, but IMO, serves a different purpose to that
which I intended directional navigation for.
>
> Should we add this as an option or another suggestion alongside
incremental
> navigation by quadrants?

Yes.
>
> [Note: there is [four?] directional navigation to author-designated
elements in
> CSS for the TV delivery context.  What we actually do in SVG should make
> sense as compared to the way that works, even if not identical.]

Al, I think we have to forget linking this to the CSS directional nav stuff.
Someone suggested this on WWW-SVG.  The feedback from the SVG WG, was that
using the CSS directional nav for moving to elements directionally had been
considered, but it was decided not to include this in the 1.2 spec, although
I forget why, maybe due to the ensuing war between SVG and CSS *smile*.

Will
>
>
> >
> >Jon
> >
> >
> >
> >
> >Jon Gunderson, Ph.D., ATP
> >Coordinator of Assistive Communication and Information Technology
> >Division of Rehabilitation - Education Services
> >MC-574
> >College of Applied Life Studies
> >University of Illinois at Urbana/Champaign
> >1207 S. Oak Street, Champaign, IL  61820
> >
> >Voice: (217) 244-5870
> >Fax: (217) 333-0248
> >
> >E-mail: jongund@uiuc.edu
> >
> >WWW: http://cita.rehab.uiuc.edu/
> >WWW: https://netfiles.uiuc.edu/jongund/www/
>
>
>

Received on Monday, 29 November 2004 19:35:09 UTC