On 22/01/2008, Francesco Fumanti <[EMAIL PROTECTED]> 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 _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list