[Desktop_architects] Printing dialog and GNOME

[Havoc Pennington]

Hi,

On 12/13/05, Linus Torvalds <torvalds at osdl.org> wrote:
> And the fact is, everybody uniformly seems to agree that gnome isn't
> customizable. Whether the reason is "usability", "avoiding clutter", "I
> couldn't get it to work" or anything else. Even you seem to agree, you
> just don't agree that it's needed.

My laptop here appears to have over 6000 settings in the GNOME config
system, not that this is a meaningful metric.

I do agree that it's *less* customizable than some alternatives,
though I think it's *more* customizable than say, Windows, which would
be the most interesting alternative to compare with if we had any
perspective here instead of infighting about which tiny-marketshare
software product most deserves its tiny userbase.

Jeff and Nat for example (two more relevant people to speak for GNOME
these days) have historically disagreed with my point of view, and
felt GNOME has gone too far away from the original "traditional
Linux/UNIX user" base. To me GNOME (and the Linux desktop in general)
is stuck in an untenable intermediate position; it's trying to make
that group happy, and enterprise purchasers, and also the proverbial
"home user." And while in theory you could do that, in practice I
think it's nuts, because resources are finite, developer cultures can
only prioritize so many things, etc. A design focus is necessary and
so are hard choices. Another way to think about it is that
commoditization and innovation are very difficult to pursue at the
same time with the same organization(s). Making it harder, it really
isn't just GNOME; look at all the other organizations involved on this
list. Good lord.

I'd rather see several efforts focused on more tightly-defined goals,
rather than one big mishmash of all-things-to-all-people.

But, my opinion doesn't matter in the end. Time will tell.

> And quite frankly, regardless of whether you agree or not, the
> overwhelming evidence is that gnome eschews user configuration.

I do agree, fwiw. The first choice should be to fix something in a
more root cause way (let me cite that gmail example again since it
turns out to be a good one - auto-expand the text box to fit in the
browser window, and offer a "new window" button; both better fixes
than adding some dumb config option). And indeed Google I would say
also avoids user configuration more so than some of their competitors.
Compare Google Talk with the AIM client sometime. I think GNOME is
right to follow this "please fix the root cause" path, or "get the
default design right and then tweak it with a few options" path,
rather than a "just start coding as many options/features as possible
as fast as possible" kind of thing. Nat had some nice parody summaries
of these two extremes.

But GNOME (to the extent that we can say GNOME has an opinion) is
definitely not blanket "against" config options, it has piles and
piles of them. It has tons of control panels, and then tons of hidden
prefs also. (Firefox similarly has a bunch of stuff in the dialog, but
then also about:config with hidden stuff; OpenOffice.org I think may
cram it all in the dialog someway, but their dialogs are pretty
mindblowing)

> > Is your proposed guideline here that if any alternative OS/WM has a
> > feature, GNOME has to have it? If not, which "flexibilities" do you
> > consider important? How do you decide? That's the guideline I'm asking
> > you to think about and suggest here.
>
> The very fact that you even _ask_ is telling.
>
> The fact is, developers don't know what their users are going to need.

That's why most software sucks, yes. Developers just throw up their
hands and implement some junk that they would personally enjoy instead
of going out and learning something about non-developer people or
listening to competent design teams.

> That's a very fundamental issue in any software engineering. The other,
> almost as fundamental issue, is that asking users is usually not very
> productive either, because (a) different users will give you different
> answers and (b) users often don't even know.

That's why designers don't usually take surveys. The usual method is
ethnographic observation; you watch people going about their life, or
using the computer, and you look at how you could improve that. You
watch a lot of people and you look for ways a single piece of software
or feature could improve things for some identifiable group. You go
meet people and look at what they're doing and learn about them.

I completely agree with you that web polls and idle speculation by
engineers does not result in accurately predicting what people would
benefit from, and that one can never know with 100% certainty even if
you do some research. But one can do far better than random/uninformed
by making an effort, in my opinion.

But perhaps our fundamental disagreement (and you're making the same
argument many others have) is that you seem to feel that "making it
configurable" is a way to not choose, not decide, or not figure things
out.

Even ignoring software, I have a fundamental life-philosophy belief
that it's impossible to not choose. Failing to act is a choice the
same as acting; you have to do something, and it's going to be either
A or B or C. In light of that, one should take responsibility for
attempting to get it right.

In the software context, the only way to allow "infinite choices"
would be to offer a programming language. Or... ship the source code
and permit modifications! ;-)

If we overlook that, we're talking about some small, finite number of
configuration options, whether it's 10 or 1000. And that means you're
making a hell of a lot of choices, because even the list of
*reasonable-sounding* options is way longer than you'd ever get around
to coding. There are also (shock horror) worthwhile features to code
besides config options.

To me this means taking responsibility for what to do first, and
what's most important.

Even if you do a Sawfish or Emacs type of thing, there's value to
pre-implementing some stuff, and leaving other stuff open for people
to code as extensions if they like. And which stuff to pre-implement
is a choice. Only a tiny number of your users are going to code
extensions, and the rest will suffer (or benefit) from your choices
about what to pre-implement and default to.

Firefox having extensions hardly makes the defaults irrelevant. Nor
does it make popup blocking irrelevant, and they could have added more
options instead of working on that.

Failing to choose is just irresponsible. Maintainers aren't perfect,
but if they don't think they can do statistically better than randomly
rolling dice, or Joe off the street, they really shouldn't bother to
be the maintainer. We could just put up a source code wiki, or
world-writable CVS.

Being in charge of anything is about saying "I can make this different
by imposing my vision on it" - your maintenance of Linux for example,
even if we understand your vision as "anything goes!" (which I don't
think is accurate), that in itself is an imposed vision different from
what others would have imposed. Yes, responsibility is always an
arrogance on this level.

> Or maybe the functionality just _isn't_ there, and metacity just doesn't
> do it. I know you've had people complain about mouse button configuration
> (because you told me that the only people who _do_ complain are UNIX
> people), so there must be some reason why you ignore user requests.

I told you the whole story of this; I did in fact spend some time
hacking on it, and didn't get a patch I liked. The current status is
that I don't personally have time to do it, no paying customer has
ever had this on the top of their list, and I've never gotten an
adequate patch. It's really that simple.

After your posts here I would imagine we might get some people who
want to try to do the patch, count it as a benefit of the Slashdot
coverage. I'll keep an eye on bugzilla.

I take full responsibility for not implementing your feature first. I
thought about it, even wrote some code for it, and in the end decided
to do something else. I could have done your feature instead of the
something else, but on whatever day this was, I had to make a choice.
I coded a different feature, that hopefully someone else appreciated,
and I did not code your feature. You're more than welcome to flame me
and as you have, not use my software. Those are the consequences of
the choice I made and I really have no objection to complaints about
what my software does, or to people using something else.

I happen to try and make these choices with an overall idea that I'm
optimizing for group A and not group B, in an attempt to create a
fairly coherent piece of software; but in theory I could optimize for
UNIX users on Monday, Windows users on Tuesday, teenage girls on
Wednesday, artists on Thursday, or something like that. I don't think
competent software developers are unfocused like that, but in theory
you can do it.

If I have an overall point here, it's that all of us who are
maintainers should be willing to make choices and take the heat, and
that it breaks our ability to make good software if we start thinking
"all things to all people," or "I can't do anything, so I'll just punt
or bow to the flames." Either we have something to contribute due to
our professional skills, or we don't. Users (like Linus) vote with
their feet on whether we contributed the right things for them
personally, or focused on someone else instead, or just failed to do
anything useful for anyone at all.

If nobody uses my software, I want it to be my fault. And the same if
they do use it. Why else would I bother trying to be better or worse
at my profession?

Havoc