Re: the keyboard accessibility capplet



Hi Jody:

Thanks for a good explanation of some of these issues.  As may be
becoming apparent, this ground has been plowed plenty times before.

A couple of things I would make note of:

* keyboard accessibility settings tend towards the opposite of "one size
fits all", they are all about custom tailoring, and users have very
specific needs and preferences.  That tends to make them complex.

* there is "prior art" in GUIs for this (yes, known to users as
"AccessX"), and users who need keyboard accessibility help have grown
strongly attached to features in that prior art.  That includes not only
the CDE AccessX control panel, but GUIs for AccessX from several rehab
centers, etc.

* users may want specific, exact values for settings, rather than the
rather mushy "small, medium, large" behaviors that most users experiment
with for desktop settings.  Thus we have the complex valuators, to
accommodate both qualitative and quantitative valuation.

* something that would take most users 10 seconds could take an accessX
user several minutes (or worse) if AccessX is configured wrongly.

* many accessX users will want to change their settings to accommodate
specific applications, or to adjust for day-to-day changes in their own
capabilities.

A couple of questions:

* do you have a better abbreviation for 'msec' ?  Though not a proper
"SI" unit, it seems better than "ms", and typing in the units in
seconds, in decimal form (i.e. "0.0050 s"), seems worse.

* we are getting complaints from AccessX users about the Keyboard
capplet not including the entry fields in the valuators, since they
consider this an accessibility feature.  Any chance we can make them the
same as the accessibility capplet?  

And a couple of opinions:

* it's much better to temporarily have a submenu with only one item than
to rearrange the menus from release to release, especially if we already
have identified the need for more items in the submenu in the near
future.

* I agree with Jody, it's exactly as complicated and confusing as it has
to be, but no more so ;-)

As for the "Import CDE AccessX File" item, I believe that it's not even
CDE-specific.  I am not 100% sure at the moment but I believe that CDE
copied the exact file format used for persisting AccessX settings from
other, previously-existing GUIs.  However, I think this may be a good
candidate for a popup dialog, like this:

1. when you start the Keyboard-Accessibility capplet, it looks for
preexisting AccessX files in the home directory;

2. if it finds one, it pops up a dialog letting the user know this, and
asking if the user wants to import the settings.  It could include the
classic "don't ask me again" checkbox.

This would seem more like the rest of GNOME in terms of user migration
strategies.  What do you think?

otherwise I think that the import feature needs to be available
on-demand somewhere, even if it's not a big button in the main UI.

regards,

-Bill

Jody said: 

> On Wed, Sep 25, 2002 at 04:13:24PM -0400, Havoc Pennington wrote:
> > Maybe it's just me - here's what I think is wrong with it:
> > 
> >  - Having both a slider and a spinbutton for one setting makes the
> >    whole thing look awful and 10x more confusing.
> This is a specific accessibility request.  In various capplets we've
> had
>     - option menus : and bug reports that this was too limiting
>     - sliders : and bug reports that it is impossible to set
>                 a specific value
>     - slider + spinner : and bug reports that it is too complex.
> 
> The choice in and of itself is simple and should be consistent
> across the capplets.  Lets trust Calum and the usability folk and
> let them make the choice.
>  
> >  - the title of the window is inconsistent with other capplets 
> >    ("Configuration" not "Preferences").
> >  - putting a space before colons in labels is just wrong.
> UI review missed them, changing is trivial.
> 
> >  - the title says "AccessX" which is UNIX-workstation-cruft
> >    terminology.
> It is apparently a recognized term in the accessibility community.
> Having it in the title in parenthesis is a compromise.
> 
> >  - the "enable keyboard accessibility" checkbox is bad; most users
> >    here will interpret it to mean "make my keyboard work" and wonder
> >    why they would uncheck it.
> This is also a specific request.  The accessibiltiy settings some
> some users make it difficult for others to use the keysboard.
> However, the settings are sufficiently complex that it was deemed
> a requirement that you should be able to enable and disable them
> en-mass without losing the state.
> 
> >  - the "Import CDE AccessX file" button should be in a
> >    Solaris-specific --enable-solaris-stuff compile option, and absent
> >    otherwise. And probably does not belong in the dialog button box
> >    anyway, it's not a dialog action.
> It is not solaris specific.  Anyone coming from CDE can use it.
> 
> >  - abbreviation "msecs" is not good.
> This is what the docs and usability folk requested.
>  
> >  - the mouse prefs are duplicated from the "Mouse" control panel, 
> >    adding to the extra clutter.
> There is no overlap.  Those are completely different settings.
> mouse != mouse keys
> 
> >  - the button to open the Keyboard capplet is bogus; if people want
> >    Keyboard settings they go to Preferences->Keyboard. It would make
> >    more sense to have an Accessibility button in the Keyboard control
> >    panel, if anything.
> This was requested because keyboard repeat rate is sometimes
> considered an accessibility setting.  After much debate the current
> appoach was selected over other versions, such as merging the
> controls into the keyboard capplet.
> 
> >  - unless it was fixed recently, it still appears as the only item 
> >    in its own submenu.
> This is transitional.  The belief is that there will be other
> accessibility configuration elements.  
> 
> > So this thing is twice as big and confusing as it needs to be, due to
> > extra sliders/spinbuttons, extra buttons in general, duplication of
> > mouse capplet; and it adds a whole submenu to the Preferences menu.
> >
> > I don't know if I have the right answer to all the problems, but can
> > we _at least_ lose the slider/spinbutton stuff, and the AccessX stuff,
> > and the extra one-item submenu?
> 
> It is as small as it could be and still meet the requirements.
> If you'd like to change the requirements that's fine.
> 
> Havoc please contact me if you'd like me to go over the damn thing
> with you.  So many people have made so many conflicting requests
> about this dialog that it amazes me that it is no uglier than it is.
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
> 
> End of desktop-devel-list Digest





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]