Re: [g-a-devel]gnopernicus command keys

[Peter Korn <Peter Korn Sun COM>]

Hi Bill,

> Peter: I know you are talking about the numberpad, but the reality is that not all X servers and
> keyboard drivers distinguish between the numpad and arrow keys in some configurations.  So in fact,
> anything that grabs the numberpad has a very high clash potential for the arrow keys.  I suspect that
> the situation gets worse for non-English keyboards.

Are you saying that it is more likely that an arrow-key NumPad assumption 
clash is *more* likely when used with modifiers (e.g. Ctrl-NumPad-8 for 
Ctrl-Up-Arrow vs. NumPad-8 for Up-Arrow)?

I think there are two issues here, and I think it would be helpful if we 
discussed each separately, rather than potentially confusing them.

 1. From the user's point of view, what is the best interface?  Do users
    generally prefer the existing "layering" keypad approach, do they prefer
    to use modifier keys with the keypad, do they prefer to use the main
    keyboard (presumably with modifier keys or a similar layering), or
    is there no clear "center" of preference?

 2. How do we best deal with keyboard conflicts?  If we can agree that
    "the screen reader always wins" (and it is up to the user to choose
    command mappings that don't clash, and the screen reader vendor to
    choose intelligent defaults that have few known clashes), then the
    issue is whether and how we can achieve this.  I believe a low-level
    interception of the keyboard will be the only guarenteed way of doing
    this, hence our work in that area.

Fundamentally, the more keyboard commands we have, the more likely we'll 
have conflicts.  So long as we can guarentee that the screen reader always 
wins (e.g. with an X extension), why doesn't the conversation simply become 
a discussion of item #1 above?  Do we really want to put a lot of effort 
long-term into a world without such an extension?  And, is there really a 
significant case in which we'll find clashes with modified NumPad keys but 
not with the unmodified NumPad keys?  I mean, I'm sure there exist legacy 
specialized apps that use such key sequences (e.g. a Motif image 
manipulation program), but in reality is this something a blind user is 
likely to encounter on a GNOME desktop (and if so, won't that app otherwise 
be inaccessible anyway)?


Regards,

Peter Korn
Sun Accessibility team


> Peter Korn wrote:
>
> > Hi Mario, Bill, gang,
> >
> > Mario wrote (in the single quote):
> > >>>
> >
> > > > > I also have a question here.  Why is it that Gnopernicus uses such a
> > > > > complicated layer of keys.  Being new to the program it makes it quite
> > > > > difficult to use.  I wonder if this could be changed?
> > >>
> > >> ...
> >
> > > > The alternatives are:
> > > >
> > > > 1. have far fewer commands available by default
> > > > 2. use Ctrl/Shift/Alt-keypad combinations instead of layers
> > > > 3. use Function keys or them main keyboard with Ctrl/Shift/Alt combinations
> > > >
> > > > Of these, I think really only option #2 is worth considering.
> > >
> > > From past experiences with other screen reading products,
> > > option #2 is doomed to fail in the long run IMO.
> > > I see two immediate disadvantages:
> > > 1. Computer newbie users generally have a hard time coping
> > >   with complicated key-combinations.  They are hard
> > >   to remember, and cumbersome to press.
> > >   Also, reember that a screen reader user will have to use
> > >   the screen reading commands quite often, so having to press
> > >   some more or less complicated key-combo will slow him down.
> > > 2. If you use Ctrl/Alt/Shift modifiers on normal keyboard
> > >   keys to create screen reader bindings, your bindings will
> > >   at some point collide with shortcuts defined in some
> > >   application the user is running.
> > >
> > > It is of course acceptable to bind certain commands to
> > > Ctrl/Alt/Shift+something combinations, but those should
> > > be very carefully chosen, and perhaps only by the user himself.
> >
> > And then Bill:
> >
> > > #2 however has the distinct disadvantage of clashing with commonly-used GNOME keybindings.
> > >
> > > It might be worth investigating whether we can use less-common modifier keys, such as the
> > > 'Windows' key, etc. in conjunction with numpad or arrow keys, for some functions.
> > >
> > > It also might make sense to use the Function keys (with a modifier, say Ctrl-F1, etc.) to
> > > switch gnopernicus 'modes' or 'layers', and the use numpad/arrow keys (possibly
> > > with shift/alt/etc.) for gnopernicus-specific navigation within that 'layer'.  This might have the potential
> > > for less conflict with GNOME keybindings, while retaining the convenience of the number pad
> > > for the most frequent gnopernicus command keys.
> >
> > I think you guys may have misunderstood me.
> >
> > Mario - your comment about newbies potentially having problems with modifier
> > key combinations is well taken.  However, it seems both of you may have
> > missed the fact that I'm suggesting modifier key combinations *only* with
> > the numeric keypad.  I'm not aware of any application that would collide
> > with Ctrl-NumPad-1 (any more so than colliding with NumPad-1 for example).
> >
> > I think the only real concern is the newbie concern.  Perhaps the caliber of
> > users coming from Windows/JAWS is different than what I remember from the
> > outSPOKEN days (Macintosh and Windows).  In both of those products we used
> > the numeric keypad with modifiers.  I'm not aware of any significant level
> > of tech support calls about those combinations.  In fact, my recollection is
> > that outSPOKEN was prasied for how intuitive its user interface was
> > (Macintosh and Windows), and how users coming back to it after using other
> > products found themselves working productively inside of 10 minutes, where
> > it took them far longer to remember the key commands of other screen readers
> > when the moved (back and forth) to those.
> >
> > The key, of course, is in designing a set of key commands that make a high
> > degree of logical sense.  I think that was one of the accomplishments of
> > Marc Sutton and Josh Miele in the design of the outSPOKEN for Windows key
> > command scheme.
> >
> > Also, it seems to me to make more logical sense to say that Braille is the
> > ALT key (for example), and magnification is Ctrl and Shift-Ctrl than it is
> > to say that these are layers 9, 6, and 7 respectively.
> >
> > Regards,
> >
> > Peter Korn
> > Sun Accessibility team
> >
> > _______________________________________________
> > Gnome-accessibility-devel mailing list
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel