Re: the keyboard accessibility capplet



Bill Haneman <bill haneman sun com> writes: 
> * 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.

This dialog is far busier and more inconsistent-with-other-dialogs
than required to offer the functionality, IMO.

> * 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.

By this argument we should be copying CDE in a lot more places. The
more important prior art in terms of number of users is probably the
Windows XP accessibility capplet - which is MUCH MUCH better arranged
than ours, but has similar features.

> * 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.

So dump the sliders and have only spin buttons? What is the reason for
the sliders in accessibility terms?
 
> * something that would take most users 10 seconds could take an accessX
> user several minutes (or worse) if AccessX is configured wrongly.

Presumably this refers to the global enable/disable toggle. But that
doesn't help anyone; because enabling it the first time doesn't _do_
anything, as all the sub-checks are disabled. The global toggle here
just slows things down.

Not to mention that poor usability and overcomplexity surely affects
disabled users as well as abled users. "How do I enable the BounceKeys
area?" would definitely stop a lot of users if the global toggle was
unchecked. The global toggle isn't even clearly associated with the
group of things it affects.

> * 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.

So the dialog should be easy to use.
 
> * 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.

How about losing some of the complexity from the dialog so you have
room to spell it out. ;-)

> * 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?  

If we have meaningful exact numbers that users want to set, we should
just use spinners _only_. Or use sliders with the draw_value thing
turned on, and with enough length to allow fairly precise
configuration.
 
> * 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 would buy that if the near future means 2.2. What are we adding in
2.2?

The problem is that a one-item menu looks like a bug. It's just
broken-looking.

> 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?

That would be perfect, and a big improvement.

Havoc



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