Re: the keyboard accessibility capplet

[Havoc Pennington <hp redhat com>]

Jody Goldberg <jody gnome org> writes:
> 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.

Calum, Seth, Anna, can you post the rationale and endorse using both
of these consistently across GNOME? Or give a guideline for when to
use both? Is this in the HIG?

To me slider+spinner is blatantly too complex. Just pick one. Windows
and Mac and every other dialog in GNOME all manage to do this.

If you need to set a specific value (the units are meaningful) then a
spinner is sane. Else a slider is probably right.

I do not believe that users need to set a specific number of "pixels
per second." The "msecs" fields should be spinners, and use the space
saved by losing the sliders to spell out "milliseconds."

The sliders in this dialog are mostly too short to be useful anyway.

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

All these changes are trivial if we can just go in and change them,
but this particular capplet seems to be really hard to get changes
into. ;-)

> >  - the title says "AccessX" which is UNIX-workstation-cruft
> >    terminology.
> It is apparently a recognized term in the accessibility community.

Anyone who's used to the word "AccessX" won't be confused by its
absence, because they are already computer people and will know terms
such as "Bounce Keys" anyway.

> Having it in the title in parenthesis is a compromise.

The whole capplet 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.

What I'm saying is that the requirement is wrong.

There are four check buttons to enable/disable specific features. 
This button lets you enable/disable those as a group.

Having the global checkbox gains you:

 - you avoid up to three extra clicks! woot!

Its cost is:

 - extra clutter in a highly overcluttered dialog
 - double-nested "enable the controls" checkbuttons - very hard to
   use, very _modal_ in nature
 - a label on the global checkbox - "enable keyboard accessibility" - 
   that is really hard to understand

If the settings are deemed complex/dangerous, we should have some
_real_ protection, such as a warning/confirmation dialog.

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

I guess what I'm saying is, maybe Sun and users coming from old Sun
machines care about this, but as far as most GNOME users are concerned
it's unnecessary dialog clutter that makes them stop and go "what's an
AccessX?" and "what's a CDE?"

> >  - abbreviation "msecs" is not good.
> This is what the docs and usability folk requested.

Probably because there wasn't room to spell "milliseconds" due to the
sliders and pointless icons.

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

Good.

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

To me this is a "we can't make a decision, let's just make it
configurable!" kind of choice.

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

When? If there wasn't in 2.0, and I haven't seen a suggestion for 2.2,
then we have things looking broken for a year and a half while we wait
for some future accessibility control panel.

A one-item menu _looks really broken_. I couldn't ship Red Hat Linux
8.0 with that in there, and GNOME upstream shouldn't ship that way
either.

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

Yes, I would like to change them. Please.

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

As I said, I hate to keep bringing it up, but for whatever reason it's
still broken... to me if I put all the other control panels next to
this one, the accessibility capplet sticks out as very different.

Does no one else agree?

Havoc