Re: the keyboard accessibility capplet
- From: Havoc Pennington <hp redhat com>
- To: Bill Haneman <bill haneman sun com>
- Cc: desktop-devel-list gnome org
- Subject: Re: the keyboard accessibility capplet
- Date: 25 Sep 2002 20:14:06 -0400
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]