Re: 2.4 Proposed Modules - gok



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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]