Re: [g-a-devel]Proposed implementation agnostic GNOME Speech API.
- From: Peter Korn <Peter Korn Sun COM>
- To: Mario Lang <mlang delysid org>
- Cc: n7zib bresnan net, desktop-devel-list gnome org, gnome-accessibility-devel gnome org, Rich Burridge <Rich Burridge Sun COM>
- Subject: Re: [g-a-devel]Proposed implementation agnostic GNOME Speech API.
- Date: Mon, 15 Dec 2003 17:03:31 -0800
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]