[g-a-devel]Re: desktop-devel-list digest, Vol 1 #655 - 12 msgs

[Bill Haneman <bill haneman sun com>]

Brian Cameron said:

> From: Bryan Campbell <bryany pathcom com>
> Subject: Re: GOK Information and or Help call idea
> 
> 2002-08-29 Bryan Campbell
> >> HI. Upon reading GOK wont trap any keys as the onscreen keyboard meant to
> >> pass keystrokes to other programs I thought, what if I want to see Help or
> >> configure it? that is a real matter to me being local to the developers I
> >> might be early tester. My idea is that GOK show help if F1 is typed 3 times
> >> in a row. that makes it similar to how Sticky keys is toggled On Off by
> >> typing Shift 5 times in a row. 

One problem is that most of GOK's target users can't use the keyboard,
so as Brian C. says, they can't reach the F1 key.  I would suggest some
other way of getting help in GOK, for instance a Help key on the main
virtual keyboard.

But you raise a good point about bootstrapping; what if GOK is
configured poorly/improperly for a user's needs and the user therefore
can't access the 'Help' button?  (The F1 solution would not solve this
problem for most users, though it would for you)

I believe that the folks doing GOK development are accustomed to the
scenario where a physical therapist or other specialist helps a
motor-impaired user get their system set up, and thus this specialist
would help customize and configure GOK.  However since we'd like to
bundle GOK with the GNOME desktop, I suggest that this solution will not
always be the best, and we'd like to have a means for end users to
configure and learn GOK by themselves whenever possible.

This suggests several things to me; in order to make sure that GOK's
help and configuration are available to as wide an audience as possible,
we may want to provide more than one way to do basic tasks like bringing
up a Help menu, and bringing up the 'Settings' menu.  We could also
configure GOK in a default mode that would be the most likely to work
without additional hardware, for instance using mouse buttons for input
events.  Also the first time GOK is run it could put up a
multi-input-method dialog, a sort of 'Input Method Wizard' (planned by
the GOK team I believe), which could be designed so that users could
select an appropriate input method regardless of their disbility. 
Therefore the wizard would have to work with both point-and-dwell
methods, direct click methods, mouse button presses, joystick input
events, etc. depending on what the user had available.

The use of GOK which we have been discussing, basically using it as a
keyboard 'intermediary', is somewhat more unusual but could be
configured the same way.

I suggest that we could continue this discussion on the
"gnome-accessibility-devel gnome org" list

http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

where I think the GOK maintainers will see the discussion and be able to
reply more directly.

The 'bootstrapping' and configuration part of GOK is important and these
are good questions to raise.  Personally I like the idea of including
'Help' in the GOK onscreen buttons.

-Bill

> >Given that the main gok screen has a permanently unused 'back' button,
> >perhaps that could be changed to a help button?
> 
> But suppose on-screen part of gok isn't working the button is no help, gok
> builders likely have ideas. & i work the keyboard like a Chess match maybe
> i'll get idea :)
> 
> 
> Regards,
> Bryan Campbell