Re: efficient osk - was GNOME A11y: where do we need to improve?

["Steve Lee" <steve fullmeasure co uk>]

On 22/01/2008, Francesco Fumanti <francesco fumanti gmx net> wrote:
> maybe I should
> list the main features that I would like to see
> (they also are in the GetInvolved page):
[snip]

Can you put these on the wiki so they get captured?
This is really useful.

> as
> far as I know, the usual layouts (qwerty?) were
> designed for technical reasons to maximize the
> distance between two subsequent letters; for
> onscreen keyboard that distance should be
> minimized to type faster:

Yes to stop typewriter keys jamming
The trouble is QWERTY has become the standard though there are
alternative layouts (Dvorak). Perhaps an OSK frquency-based standard
could be devised (language dependant).

> Should onboard be enhanced, should gok be
> improved (for example the setup wizard idea,
> concentrating on uses cases instead of technical
> aspects; refine the composer; core pointer
> issue,...)?

Any solution should do that (e.g using 'Personas') ;-)

> Two moving references; this surprises me: I
> assumed that eyetracking required a resting head.

I tried MyTobii/Grid and it was quite resilient to my attempts to
confuse it with lateral head motion. My thought was that headtracking
could be used to help compensate for motion by helping to locate the
eyes.

> Are you talking about porting all (if not most) features of gok to python?

That has been discussed. Technically it would be great if pyatspi
became the standard that AT authors used to access applications. If
you would like to know more there is an introductory article in the
latest edition of python magazine (http://pymag.phparch.com).

> By the way, there are a few words concerning
> switch input in the specifications of sok.

My understanding is that switch access was added in a later release
after basic pointer access. GOK started with switch access as a
requirement. As an alternative Jambu's jambuinapp gives another option
by allowing switch users to directly move around a User Interface (e.g
Firefox).
http://www.oatsoft.org/trac/jambu/wiki

> I don't know whether it would really make sense
> to have a variable keyboard for the use case that
> I have in mind (a user without problems to move
> the pointer). It would require more learning from
> the user. Maybe that I get you wrong: what
> behavior are you talking about?

It might be worth making a distinction between text input and
application control. If a program has complete keyboard access then it
is possible to control it from an OSK with a sticky keys feature.
However 'keyboards' with context sensitive menus of actions do give a
simplified experience with less cognative load (no need to remember
all those key combinations). A more extreme case is highly reduced
'option sets' that are useful for people with multiple and/or learning
disabilities who need simplified and graduated UIs and not exposure to
raw applications.

> PS: I have not named the exact AT that I am using
> because I don't know whether it is good practice
> to name commercial items in a free software list.

I don't know, I don't think it is a problem as they all help users.

BTW there are some interesting resources on the ACE Centre site that
include info on prediction and head mice.
http://www.ace-centre.org.uk/index.cfm?pageid=B2592F93-3048-7290-FED2AED562D4432C

-- 
Steve Lee
--
Jambu - Alternative Access to Computers
www.fullmeasure.co.uk