RE: 2.4 Proposed Modules - gok

[Murray Cumming Comneon com]

> From: David Bolter [mailto:david bolter utoronto ca] 
> 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...

See, I knew you had your reasons.
 
> 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.

That sounds good. Hopefully there's a bugzilla bug for that so it doesn't
get forgotten about.

I had just been thinking that, even if the idea is to look different to the
rest of GNOME, then it would take some cooperation with the theme system to
make sure that's always true.

>  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.

I'm sure that all such information is helpful, and might avoid someone
mistakenly undoing the design later.

Although I haven't actually been able to run gok yet (see my other email)
what I've read and seen so far suggest that things gok is a pretty good,
though unusual, candidate for GNOME. 

Murray Cumming
murrayc usa net
www.murrayc.com