Re: Sorry State [Was: NLD10 and GNOME]

[Havoc Pennington <hp redhat com>]

On Wed, 2006-02-08 at 04:49 -0200, Evandro Fernandes Giovanini wrote:
> 
> There's also the issue of who you target with the changes. Novell might
> find in a usability test that the menu they designed is a lot better for
> their target audience but most people in the GNOME community would
> reject it in favor of the current panel layout (I'm one for example).
> Should that stop Novell from doing what's best for their customers
> (people used to Windows but now using GNOME because their company went
> with NLD)?

Since everyone must chime in on this thread ;-) and I'm not above a
potshot from the sidelines while not doing any work anymore, my comment
is that deciding the above, community-wide, is a much larger issue than
the one Jeff raises (or than whether we have XGL or panel changes at
all). In fact this question should define a project, rather than
defining a project as a particular set of tarballs and source code.

Is GNOME for UNIX and shell users? Is it for Linus Torvalds? Is it for
ourselves? Is it for American college students? 35-year-old corporate
office workers with an IT staff? And are we willing to tell whoever it's
*not* for to jump in a lake?

The blog thread this weekend brought up the old "are we too dumbed down,
not dumbed down enough, or just right" line of thinking which (apologies
to whoever feels offended) I find to be a shamefully lazy, wholly
misleading, and simply completely broken way to think about software. A
close second, which is the "let's be simple and avoid confusing people"
school of thought, is really just the same limited approach, rephrased
to sound better. Yes I've been guilty of it myself. Doesn't make it
right.

The replacement for this should be:
1) who, specifically, is the software for? (ideally much more specific
even than stuff like "technical vs. nontechnical users")  [1]
2) why, specifically, do they want to use it? what does it help them do
that they want to do?

Helping them do it without being confusing is a hygiene kind of thing,
like code maintainability; but doing something someone wants to do at
all, and knowing the who and what, is the first-order problem. And you
have to do something they want, that they can't already do, *considering
the entire reality of what software (and non-software) they are already
using*.

There's no way anyone can rearrange the panel menus and add eye candy,
in order to convert something appealing to nontechnical college kids
into an enterprise/corporate thing, or convert a
programmer/sysadmin/shell-user desktop into something plausible for
college kids. It's not about surface cosmetics, guys. The overall
direction needs to be in the roots of the project, it answers the
question what should the software _do_. What should it _be_. Should it
be a "desktop" at all? Going back to my blog posts last month, define
the hole, not the drill.

Until the project answers that, it will create building blocks that get
rearranged and reshuffled into other projects, whether NLD10 or Maemo or
Red Hat. The extent of the rearranging can be large or small.
No shame in that, but if that's the plan (as it _definitely_ is for e.g.
the Linux kernel) then suck it up and optimize the project for it.
Lots of times the kernel developers' thoughts and practices very much
assume this. They are writing a component for use by developers, not an
end-user product. And they aren't ashamed of it and they optimize for it
and they do it well.

Jeff, you're right that Steve Jobs style "big press release" is
incompatible with community development (though I don't think it's a
moral issue perhaps, I think it's legitimate to make the tradeoff as
long as one is willing to eat the consequences).  But the larger problem
right now is what I described above, the lack of direction; if the
community had that, they would just steamroll over the cosmetics coming
in from the Linux distributions.

And also a lot of "stop energy" would go away, because it usually arises
from lack of agreement on the big picture (which gets expressed through
nitpicking about details).

btw, choosing an audience and effectively making something for them
*will* alienate other audiences, possibly even losing the support of the
Linux distributions. That's the reality. Don't think you can move in a
direction without *not* moving in a different direction.

There _is_ a default audience if a project doesn't find a way to choose
one deliberately, and it's what I've called "by and for developers." If
there's no way to stay out of that gravity, it's better to embrace it
wholeheartedly IMO than to be there de facto and keep poking developers
in the eye. e.g. whether to expose paths in the UI; if most of your
users are shell users, GNOME probably made the wrong call. A developer
orientation could also concentrate on making the project a good building
block for integrators creating custom solutions, whether NLD or Maemo,
by modularizing it, making it customizable, and not flaming about the
customizations.

If you guys want a specific productive suggestion, I think these are two
de facto directions that could just be adopted; one is a kind of
building block platform shared among the GNOME desktop, Maemo, GPE, XFCE
even [2]; it might benefit from becoming explicitly targeted toward
multiple projects? Emphasize fd.org more. I don't know. Two is a GNOME
desktop that is still largely UNIX/shell-user/developer-oriented,
designed for the customers of today's Linux distributions. Focus on this
more and do it better.

If the community wants to go beyond these de facto directions, I think
it's possible, but only if people have the courage to commit to their
chosen audience and recognize that it means not serving some other
audiences. In the past, we lacked that courage for whatever reason.

If I could "do over" on GNOME 2 when I was heavily involved, I'd
advocate much more radically in a direction; would have pushed to either
completely drop the UNIX professional audience, or really design for
them as the primary.

In "The Inmates are Running the Asylum," there's a picture of a mutant
combination truck/sportscar/van/whatever, contrasted with focused car
designs like, say, a sports car or truck. That's what GNOME needs to
avoid. It's cool to make parts used in both sports cars and trucks; it's
cool to make sports cars; it's cool to make trucks; but nobody wants a
sports car with a truck bed on it. That's why you have to pick a
direction and stick to it.

I hate to be sounding all "in my day..." and "here are the lessons of
the past," but hell I'm almost 30.

Havoc


[1] One way to think of this is the old nautilus "user levels" feature
(novice, intermediate, advanced); the fallacy is the same as the "dumbed
down" debate, it assumes there's only one relevant dimension, call it
"1337ness"

In reality there are lots of relevant dimensions, such as age and
interests and personality and nationality and work vs. play and
historical computer usage and whatever. So if nautilus had modes for
"shell user administering UNIX systems," "college kid who doesn't like
computers but is used to Windows and DJs at night," etc., or even more
specific, that would have made a lot more sense, but it also would have
revealed the absurdity of trying to code for all those people at once.
And maybe caused someone to step back and ask which of these groups want
a Nautilus at all, and which might love something else we could write.

The old usability cliche "users are busy not stupid" is exactly right,
because the issue is that they are busy _doing something_ and they will
always only care about things they need to care about to do that thing.
So the relevant question is not whether they find something confusing,
but whether a specific person would _care_ about it at a particular
point in using the software. Much better to talk about "interestingness"
than "confusingness" when deciding what to strip down (not least because
interestingness is more obviously relative to the audience)

[2] This list (Maemo, XFCE, etc.) btw illustrates at least how different
a GNOME tuned to a specific audience would probably be from today's
GNOME. In fact those are still both fairly developer/technical oriented
projects and already feel pretty different.