Re: 2.4 Proposed Modules - gok
- From: David Bolter <david bolter utoronto ca>
- To: Bill Haneman <bill haneman sun com>
- Cc: Murray Cumming Comneon com, peter korn sun com, jdub perkypants org, desktop-devel-list gnome org, gnome-accessibility-list gnome org
- Subject: Re: 2.4 Proposed Modules - gok
- Date: Fri, 09 May 2003 10:43:27 -0400
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]