Re: [Nautilus-list] Mounting preferences - the death of options.

[Havoc Pennington <hp redhat com>]

Hi,

So I'm worried this is the kind of overly-abstract
no-concrete-issue-at-hand thread that results in endless discussion
with no possible useful outcome. ;-)

Michael Meeks <michael ximian com> writes: 
> 	I just want to register my serious concerns that options provide a way
> for more than 1 person to work on a project without serious
> disagreement, that is without overt fascism [cf. Metacity ].
> 
> 	I really, really don't want to see Gnome go down the Metacity route of
> no options whatsoever [hearsay is that correct ?]

Not quite correct, Metacity does have some options (focus mode, number
of workspaces) and some others planned for when I feel like it
(keybindings). However Metacity is not GNOME, Metacity is my toy
project where I am the supreme fascist and can do what I want. ;-) I
recognize that compromise will require more options from time to time,
for GNOME desktop components. I don't have a problem with that.

However I don't think we should let dumb flamewars result in lack of a
good UI decision - and the usability project has been doing pretty
well at this, so far. The HIG has lots of perfectly reasonable
decisions and going back to see what other options were considered and
making all the decisions configurable isn't IMO worthwhile.

The right place to have preferences is when the thing to change is an
individual preference, and all options are equally good. For example,
colors and fonts. Or mouse speed. Or number of workspaces.

> 	Sometimes 'fixing' such things is a very individual thing, is it worth
> creating the mass flamage ? I'm personally in favour of an option as to
> whether to include a 'Close' button in whatever dialog - if it helps
> someone - it's pretty harmless - and might save hours of fruitless
> opinionated discussion.

I just didn't read the discussion, since I don't care _that_ much what
we pick, however I do care a lot that we _pick something_. If that
makes sense.

As many UI books say, bad preferences often result from the programmer
not making a decision. As a project, we have to be able to make
decisions, instead of pushing them on our users. If we can't then we
suck, and it's a fundamental suckage in the open source model.

However I think we can; we just have to learn that not everyone is
going to agree, and making some decision is more important than
whether a flame or two appears on the mailing lists.

We have two ways to decide on UI topics; we can have the usability
team vote on it for project-wide stuff, and we can have maintainers
make the call for their projects (hopefully following project-wide
guidelines when appropriate). So we can make decisions, we do have a
place where the buck stops.

> 	Finally some settings are not appropriate for display in a generic
> GConf tool, such as enumerations, and some settings interlock in a
> relatively complex fashion, that mandates more careful treatment -
> unless one wants a horribly confusing auto-generated dialog with
> conflicting options, some of which are invalid at any given time, the
> program receiving invalid states or excessive validation of the
> state.

Sure, there's room for a hand-coded TweakUI app like Windows XP has.

XP also has the gconf-editor feature (complete with docs for each key
- but I had that first dangit! they stole my idea!)

Apps do ideally need to be robust against any crap that appears in the
gconf database, same as they need to be robust against any crap that
appears in the filesystem - thus "gconftool --break-key" for testing.
It's easy enough to write a script that goes through and runs
--break-key for every key with a schema installed, so we can test the
whole desktop at some point.

> 	All I want is a gentle assurance that this isn't the start of a 1 man
> crusade to rid the world of the majority of the options that people have
> coded for their use, removing code, and replacing it with someone's
> hard-coded idea of what is best. I'm particularly concerned about any
> options I personally use :-) And of course, I have no problem with
> removing the user-level, or the idea that a few appropriately obscure
> options should be shoved into a gconf-tool type access. 

Of course we'll still have sensible preferences. We just won't have
"hi the programmer has no idea how this works, so we're making users
configure it" preferences.

We also have to recognize that in-the-prefs-dialog preferences are a
limited resource; the prefs dialog can only be so big before it
becomes totally confusing and even advanced users can't find what they
want. So that means you want to use the available space for worthwhile
stuff.

The clean prefs dialogs of OS X or even Windows XP or even
gnome-control-center HEAD (when compared to GNOME/KDE current) are
just so much more usable, and so much nicer, IMO. And the way to get
that is to think hard about what goes in them, and stand your ground
when people make wrongheaded requests, same as you stand your ground
when people request silly stuff in APIs.

My experience is that if a user doesn't like how something works,
their first impulse is always to ask for a preference, I think out of
humility - they figure someone loves the current default. However if
you dig deeper and ask them _why_ they want the preference, _what_ was
annoying, and think about other possible solutions to that, then
frequently you can find a way to just change the defaults, instead of
needing a preference. i.e. fix the root cause of the problem instead
of adding a "please_fix_this_app=true" preference. It's the
responsibility of maintainers to dig deeper to really make things work
right - user feedback can demonstrate that a problem exists, but they
don't necessarily have the expertise to come up with the best
solution.

Anyway, don't worry - we'll always have preferences - but they should
be a secondary priority after having it work right in the first place,
and they should not interfere with usability, that's all.

Havoc