Re: Ang: Ang. Re: [GOK] Why ui grabbing in direct selection mode of gok?

[David Bolter <david bolter utoronto ca>]

Hi Mats, all,

As a waning GOK maintainer, I'm delighted at the thoughtful criticisms
I'm reading about GOK as I've long agreed with a lot of them. Please see
http://live.gnome.org/Gok (particularly Zero-conf GOK) for more of the
same. I'd love to see us capture all the good ideas by adding them to
this wiki page and even better, to have people willing to help out!

I agree that clinicians (support persons) are really the front line when
it comes to traditional AT sales/support. If a clinician inds a product
complex, that will effect the delivery to the end users. I've worked
with clinicians for a long time.

cheers,
David

Mats Lundälv wrote:
> Hi Francesco and all,
>  
> Thanks for reminding me about onBoard!
> Back to GOK:
> The distinction between a support person and the end user is nothing more 
> sophisticated than allowing the helper to set things up through an additional 
> setting in the existing settings menu, and allowing the end-user to have 
> convenient access to this settings via the OSK interface, if required.
>
> But it is a problem that both the basic and advanced features of GOK present a 
> number of system settings dependencies that are thrown onto the user (either the 
> end-user or a helper for a potential user) when you want to give it a try, like:
> A) the physical keyboard setting for sticky keys must be turned on for the OSK 
> to work ...
> B) the standard pointing device should not be used for stable functionality, add 
> another one ...
> C) the Assistive Technology has to be activated - please log out and back in ...
>  
> As long as this is the situation, we have a big usability problem with GOK that 
> will discourage a substantial part of potential users from even giving this tool 
> a fair trial and chance. It will (continue to?) be regarded as a difficult and 
> very exclusive tool for a very marginal number of users - which is very 
> unfortunate with the many interesting, advanced and potentially very useful 
> features of GOK.
>  
> These problems are also nothing that a user from any other environment (Windows 
> or Mac) would be used to, or find normal and acceptable.
>  
> The A) dependency above should definitely be removed (as in onBoard then)
> The B) requirement should also be removed - at least for users who may use the 
> standard pointing device for direct selection (but stay an option if you want to 
> se a second mouse as a switch interface)
> The C) dependency is of course necessary if the ui grabbing is active - but 
> should ideally and as far as possible be handled under the surface - a first 
> time permission should be ok though. If the ui grabbing could be turned off 
> (more permanently) for some users, this shouldn't be needed. Perhaps it is no 
> significant problem to have at-spi available/activated then also, but then why 
> isn't it by default? Security issue I suppose?
>  
> Cheers,
> Mats Lundälv   
>
>
> -----Francesco Fumanti <francesco fumanti gmx net> skrev: -----
>
>     Hello,
>
>     Mats Lundälv wrote:
>      > I appreciate the arguments for the ui grabbing in GOK - both for
>      > switch input and direct selection users.
>      >
>      > But there are also reasons for wanting to disable this functionality
>      > for some users in some situations - in fact for some users of both
>      > these categories: GOK is currently targeted towards advanced
>      > alternative input users. For them the ui grabbing will often make
>      > sense, unless for direct selection users who master the ordinary gui
>      > without major problems.
>      >
>      > But for some other potential users, e.g. individuals with additional
>      > cognitive difficulties, it may be preferrable to have a more stable
>      > interface with less functionality. The dynamic features of the ui
>      > grabbing may be disturbing and confusing rather than helpful.
>      >
>      > So does it have to be either or? I don't yet know the inner secrets
>      > of GOK well enough, but I would like to have an easy way to turn ui
>      > grabbing on/off - both for a support person and possible to provide
>      > for the user him/herself. Is that possible? If not, could it be
>      > added?
>
>     I was now going to propose to add an option to disable ui grabbing in
>     direct selection mode. But after reading your explanation above, it
>     might be sensible to add it for all access methods.
>
>     Moreover, you make a distinction between the support person and the user
>     itself. Does this mean that you would like to have such a distinction in
>     gok? Or is it already available (non-core input device?)?
>
>
>      > Another aspect that I have found very awkward is the fact that GOK
>      > (and I believe also OnBoard) requires the adaptive features for the
>      > physical keyboard (like sticky keys etc) to be activated for the OSK
>      > to be fully functioning. This is really unfortunate and weird, as
>      > well as totally non-standard for all other OSK solutions outside the
>      > unix-linux sphere: Why should the OSK - being provided for users who
>      > cannot use the physical keyboard - be depending on alternative
>      > settings for the physical keyboard? This is a totally unmotivated
>      > interference in the basic system settings, and in fact creates
>      > accessibility problems for people supporting the OSK user. I regard
>      > this as being a design flaw that should be removed asap. Any comments
>      > on this?
>
>     I suppose that you are talking about the requirement to enable the
>     sticky keys feature. Or are you talking about Assistive Technology
>     (at-spi).
>
>     As far as I understand, Assistive Technology is at least required for
>     the ui grabbing feature. So I don't think it will be possible to remove
>     that requirement. And for what concerns the sticky keys, I don't know.
>     Maybe somebody with more knowledge than me will add its comments.
>
>
>     Concerning onboard: it does not need any assistive feature of the
>     hardware keyboard to be turned on. It even does not need Assistive
>     Technology. But on the other hand, it does not offer switch input, there
>     is no word prediction, no ui grabbing,... The first two are part of the
>     specifications, but still have to be implemented.
>
>
>     Cheers
>
>     Francesco
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>