Re: Preferences, System Tools



On Mon, Jun 07, 2004 at 12:09:38PM -0400, Havoc Pennington wrote:
> > Agreed the current approach is purely a resource saving measure
> > based on shuffling existing tools rather than changing the set of
> > tools.
> 
> I guess the main thing for me is to be sure we don't institutionalize
> the current approach in the control-center vs. system-tools module
> boundary.

<diety> forbid.
 
> > > "What to use?"
> > Do we want a tool to configure mime handlers or just assume it is
> > part of nautilus ?
> 
> "Part of nautilus" is what I've heard people saying so far.

I'm leaning the other way.  A successor to JWZ's 'Law of Software
Envelopment' will hopefully imply that other applications will
expand to support/embed complex mime types.  
 
> > Many of these are not pure accessibility features.  Most of them
> > seem more like 'Usability'. 
> 
> Well a11y here is taken pretty broadly - adapting the system to people
> with different motor skills, visual acuity, etc. There's a whole
> gradient between someone who just has a touch of arthritis to
> quadriplegic.
> 
> If everyone were the same you could just pick a good drag threshold, and
> not need to make it configurable.
> 
> Maybe think of the "a11y" category as "adapt to physical differences
> among people"

Sounds like we're saying the same thing.  My concern was that we not
pigeon hole these elements with the title 'accessibility'.  Users
are more likely to consider looking in here with a label of
'Usability'

One thing to consider would be the potential to violate the
principle (named ?) of having only one place to tweak any given
setting.  There appears to be a use case for a simple ui of
usability features vs a full on accessx style all singing all
dancing accessibility layout.  The current approach of having
a keyboard capplet launcher in the accessx capplet to get repeat
speed is not scalable.



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