Re: Preferences [Was: a whole lot of other things, too]

On Mon, 2002-04-29 at 15:59, Havoc Pennington wrote: 
> Rui Miguel Silva Seabra <rms 1407 org> writes: 
> > I read your article, and I believe it is fundamentally flawed because of
> > bad premises.
> So refute the premises. ;-) 
> You haven't answered the questions.

I thought you where just quoting yourself :) not quoting yourself
expecting a reply. So here it is then: 

So how do I decide which preferences to have? 

  You keep the preferences as they show up, and only prune those that
can become unnecessary if you can fix the problem they're there for. 
  Other than that, you should still set a resonable (this is very
subjective) set of good (this is also very subjective) defaults, so you
reduce the need of tuning for joe user, but still keep the advanced
settings in an area you're only going to if you want to 

> > Exactly, keep all of them. Some may need relocation.
> You can't have all possible preferences; there are an infinite number.
> This is just a fact. Do you refute that?

Yes and it's quite simple: that argument is demagogy.
Of course you can't have all possible preferences.
Of course there's a theoretically unlimited set of preferences.
Of course both are facts.

They are also (ALL three points) "impassioned appeals to the prejudices
and emotions of the populace" [1].

> If not, then explain how you would decide which to have. "all" is not
> an answer. "All" is not even possible. So Question One: what is your
> guideline?

Not scrapping, but selecting an advanced (level? tab? you choose) area where
those options lie hidded.

My stance has consistently been that I agree that the environment should be
made easier to inexperienced users, but that should not have to be at the cost
of usage experience to a significant number of others.
The option of changing source code on each and every release to do just that is 
not a reasonable option, and almost as bad (if not worse) is blindly
pointing to gconf keys, when gconf suffers from the same clutter problems
regedit does.

> So far everyone complaining about loss of preferences has failed to
> answer this question. If you don't answer this question, you are just
> complaining, you aren't offering a reasonable solution.

I've offered at least two options, one of them suggested by Jesper Skov.

> Each preference has a number of costs, as I outlined in my article.
> Do you disagree with those costs?  Question Two: If you disagree, why?
> Give rationale addressing each specific cost.  If you don't disagree,
> how do you suggest we have "all" preferences without incurring massive
> costs?

The world is not black and white.
man gcc, count the options.

I would fully agree with you if Free Software was developed only by comercial
companies. That is not a fact, not even by close calls. Most Free Software
is the sum of many contributions done on spare time.
The investment companies like RedHat, Suse, sadly gone Eazel, Ximian, and others
is a good bonus to Free Software developers, but this has not inverted the
Most Free Software got where it is now without other QA than it's developers
did by using the software themselves, and most testing was done by its users,
downloading and reporting bugs (even in pre-bugzilla days).

Not the other way around.

> GNOME will always have some "traditional free software user" features
> such as window manager focus mode; don't worry. But if we let
> traditional users bully us into doing the wrong thing for 
> the future users GNOME is intended to acquire then we are incompetent, 
> plain and simple.

Bully? The only ones being bullied here are people like me, that like being
able to set almost every option to their liking, without having to loose time
making a patch against every release.
I'm certainly not (yet) a major contributor to GNOME (though I am changing
that slowly), so I am not bullying anyone, BUT I am being bullied into accepting
dumbified versions of good software.
If I cringe with that is because I like this software, and am not just going to
act like a vampire running away from a cross, but instead first try to do
something in my current reach... it's not being fruitfull at all yet.

> In the immediate future our future users are mostly technical users -
> sysadmins, software developers, btw. They _are_ advanced users. But
> they're advanced users who are not used to bad UI.

It depends on what you call advanced users.
A lot of mouse-engineers are considered advanced users in some circuits!
What is "not used to bad UI" ?
bash is way more effective than nautilus :) whoever doesn't buy that, can't be
considered an advanced user. He may be advanced in, perhaps, medicine, though.

> > However, there's no law against new ways of doing things. So I'd
> > suggest, in addition to the existing pref tabs, we get one that's called
> > "raw options", "advanced", or something like that, containing *all*
> > options.
> If you want a different UI for advanced settings, please, feel free to
> write one.
> I've always encouraged people to write a "power toys" prefs
> application that exposes the hidden options in a nice way. Please feel
> free to do that. Just don't dump the UI for this in the main control
> panels.

You had this already (in at least two apps: nautilus and sawfish), why change
it for worse?
So, now I not only have to make power toys for each and every app I like,
tweaking non documented features that may disappear without notice, I also know
for sure it ui (that could just hold them all together) won't even be in the
main control panels section... how exciting! It's all good news to convince me.

No Havoc, I have to disagree with you in this respect: you're not a ui guru.
You may be an excellent coder and technician that I admire a lot, but
not on ui, I'm afraid.

I'm not one either, but I know the difference between being confused with too
many options in a row and feeling stuck with too few options.



+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Ghandi
+ So let's do it...?

Attachment: signature.asc
Description: This is a digitally signed message part

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