Ang: Ang. Re: [GOK] Why ui grabbing in direct selection mode of gok?
- From: Mats Lundälv <mats lundalv vgregion se>
- To: Francesco Fumanti <francesco fumanti gmx net>
- Cc: gok-list gnome org, Gnome Accessibility List <gnome-accessibility-list gnome org>
- Subject: Ang: Ang. Re: [GOK] Why ui grabbing in direct selection mode of gok?
- Date: Wed, 22 Oct 2008 00:00:14 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]