Re: 2.4 Proposed Modules - gok

[David Bolter <david bolter utoronto ca>]

Bill Haneman wrote:

> On Fri, 2003-05-09 at 10:00, Murray Cumming Comneon com wrote:
>
>  
>
> > > Is this just to distinguish different _types_ of keys? e.g. 
> > > alphanumeric
> > > keys and modifier keys? Is there a good reason why all keys 
> > > must be some
> > > shade of blue? 
> > >      
>
> They're not all blue, so I am not sure what you mean.  But yes, it's
> very helpful to distinguish different _types_ of keys, as you point out.
>
> Al alternative, though possible not a practical one due to space
> requirements, would be to add images to GOK's buttons: this is RFE
> 108055.
>
> However, since GOK must be a "topmost-always" window, and must compete
> for space with the user's foreground application, space is very much at
> a premium.  This impacts all the UI decisions regarding the GOK main
> window.
>
>  
>
> > > > GOK is unusual in several ways, but it does need to be in 
> > > > order to meet
> > > > the specialized needs of its users. 
> > > >        
> > > It would be interesting to hear more about this.
> > >      
> > I would really like to hear answers to these questions. I'm happy to believe
> > that there are good reasons, but it's still nice to know what they are.
> >    
>
> What specific questions do you have?  Giving a general "what is GOK and
> why" discussion, in full technical detail with rationale, might take a
> lot of typing and I still might miss your question.
>
> The GOK core team at the University of Toronto designed the UI; they may
> not be particularly expert in GNOME UI design but they are very much
> experts in the UI design of onscreen keyboards.  I think it does and did
> make sense to start from UT's experience and then try to adapt that to
> the GNOME context rather than build something that "looks like GNOME"
> but fails to build on the clinical experience and on UI precedents in
> the accessibility/OSK world.
>
> If you have questions about specific aspects of the GOK UI I am sure
> David or Simon will be able to answer you best; however I can take a
> stab at explaining them as well.
And you have been doing a great job I think.

I am not a clinician but I do work along side such glorious creatures.  
What I would like to do is simply give a small glimpse into a scenario, 
and see if it illuminates an additional possible affordance other than 
the important one of telling the 'type' of key.

Ian has mobility concerns to deal with.  He finds it difficult to hold 
his head still and face one direction for any significant amount of 
time.  He has movement in his arms but the movement is fairly 
ballistic.  Fortunately this mobility allows Ian to use an on-screen 
keyboard and two switch inverse scanning (a row column scanning 
method).  Now suppose he has a mozilla email compose window up and he is 
using the compose gok keyboard, as his face and gaze sweeps across the 
screen during a rudimentary head movement, he notices that the current 
highlighted row is two before the row he wants.  He hits the 'advance 
selection' switch twice.  During the next sweep he recalls that the key 
he wants is a blue key that is three blue keys to the right of the red 
key, and notices that the red key has one key to the left of it, his 
math being lightening fast, he instantly knows to advance the 'selected 
key' highlight the correct number of times.  During the next sweep he 
double checks the label  of the key he wants (which is a pretty small 
font, but if it was much bigger the keyboard would be too big for his 
resolution), and also implicity notes the color.  Confirming the correct 
key is selected he press his other switch to select it.  This all might 
happen in a second or two or ten...

Note: this scenario is currently fiction for the since the gok compose 
keyboard doesn't currently have a red key.

As for the gok having different shades of blue, that choice was not made 
specifically on some empirical clinical research.  We can use whatever 
colors and color properties are suitable, and we can base them on the 
user theme which I must admit Bill has being nagging me about for a 
while :-) .  It is just something that got left.  If the user requires 
high contrast then the theme will tell that tale and gok should be able 
to proceed from there.  If the user doesn't care for key type based 
color coding, they can turn it off and use the default gtk themes (as 
Peter noted is available in the gok settings).  If we convince ourselves 
that gok should use gtk+ themes by default, we can go that route.  I am 
not there yet.  Best to get more feedback from the target users I think.

Me, I used to put stickers on my keys when I was learning to play quake...

Lastly, it might help to not think of the gok keys as gtk buttons.  They 
are simply keys, gok keys, on a dynamic-branching-keyboard.  We almost 
decided to draw our own keys.  Maybe I should pull some of our old 
design notes and post them on the gok site.  If I do, I will let you know.

cheers,

David

> - Bill
>
>  
>
> > Murray Cumming
> > murrayc usa net
> > www.murrayc.com 
> >
> > _______________________________________________
> > desktop-devel-list mailing list
> > desktop-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >    
>
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>