Re: NLD10 and GNOME

[Luis Villa <luis villa gmail com>]

On 2/7/06, Dan Winship <danw novell com> wrote:
> Luis Villa wrote:
> > On 2/7/06, JP Rosevear <jpr novell com> wrote:
> >> The changes that were implemented were not as radical as the
> >> mockups. Basically what Nat F. showed in Paris is what was
> >> implemented.  The code will be released to the community soon.
> >
> > To ask the obvious question, why not now, and why not discussed
> > publicly earlier?

I should have been not quite so hasty and added 'and if the answers
are real problems (which I think they probably are) any suggestions on
how to solve them?' I'm swamped at work, so I can't go into much
detail ATM, but it seems like these are very real issues we need to
solve...

Luis

> So here's my (ie, not Novell's) answer.
>
> Two words: "bike shed"[1]. Or actually, "stop energy"[2] works too. Your
> pick.
>
> Although the changes aren't nearly as radical as the original mockups,
> they are a big change from the current GNOME panel menu. If we had
> proposed the changes on the mailing lists, it would have started a huge
> discussion about what people hated about the design ("you can't make the
> panel menu depend on beagle!!!") and how it should be different. And
> then we could have either (a) completely ignored everyone and done it
> ourselves anyway, or (b) had a long conversation about the merits of the
> design and then not actually finished the code in time for NLD10.
>
> So we did it ourselves, and now either GNOME will like what we did, in
> which case, yay, free code for GNOME, or GNOME won't like what we did,
> in which case, no harm no foul for GNOME, and yay, brand differentiation
> for Novell. (And anyone who yells "fork" deserves to get one stuck in them.)
>
>
> An equivalent answer to the question is "because you can't do design by
> committee". Everything good in GNOME is good because one person or a
> small number of people working closely together made it good. Much of
> what is bad in GNOME is bad because lots of people have contributed
> without having a single vision of what the end result is supposed to be.
> I mean, look at the stuff John Williams has been blogging about the last
> week[3]:
>
>     * Evolution's UI blocking on I/O SUCKS. Due to lack of design in the
>       early stages of development
>
>     * Evolution's integration with gaim and tomboy RULES. Both of these
>       happened because specific people (ChipX86, orph) made them happen.
>
>     * Multimedia integration SUCKS. No one has ever sat down and tried
>       to fix the big picture. (Although I think the gstreamer team is in
>       the process of doing this now?)
>
>     * Apps not remembering their window size and position SUCKS. Again,
>       needs someone to take this problem and make it their own. I
>       remember xkahn was trying to fix this a few years ago, but never
>       finished.
>
>     * Bug-buddy SUCKS. Jacob's original UI was simple and brilliant. But
>       as more and more people added more and more features without
>       looking at the big picture, it got unwieldy. (But now a small
>       team is putting the simplicity back in again.)
>
>     * Deskbar applet RULES (kikidonk), dashboard RULES (Nat), and beagle
>       RULES (trow and joe). None of these was done *exclusively* by
>       those people, but each of them reflects one person's (or a few
>       people's) vision, as opposed to the current state of bug buddy,
>       which just sort of happened.
>
> This is just another aspect of the UI "simplicity" thing. We like UIs
> that try to do the right thing (metacity, epiphany/firefox, evince)
> rather than UIs that try to make every possible user happy
> (enlightenment, mozilla, gpdf/acroread). If you try to design something
> by committee, you either have to end up with the latter sort of messy
> does-everything UI, or you ignore and hence piss off a large chunk of
> the committee.
>
> And that's where we are with NLD. There is no way that everyone in the
> GNOME community is going to like the changes we wanted to make. But we
> did the user testing, and we believe in it, and we want to make the
> changes anyway. So we're doing it. Maybe it will turn out good, and
> maybe it will turn out bad. Either way, the GNOME community learns from
> it. Think of it like this: wouldn't it have been cool if we could have
> tried out spatialus on our users, found out that they hated it, and then
> reverted back to browserlus, without ever having to actually piss off
> our users? This is essentially what is going to happen with NLD10. If
> Novell's customers like the NLD changes, then GNOME can adopt them. If
> Novell's customers don't like the changes, then GNOME can stand off to
> the side and say "yeah well, we never liked that UI anyway. Not at all
> like how we would have done it." :-)
>
> But some people will still say "But couldn't you have discussed it with
> the community before doing it?" No, we couldn't. If we had, it would
> either not have happened, or it would have sucked. It's inevitable. It's
> not a problem with the GNOME community, it's a problem with communities
> in general. The wisdom of crowds[4] only works in situations where there
> are clear right and wrong answers. If you try to apply it to a design
> problem, where there are many entirely different right answers, then you
> end up with a wrong answer. Always[5].
>
>
> So to sum up: design by committee is bad, endless debates that result in
> code not actually being written are bad, design by very small teams is
> good, software with a unified vision is good, trying out cool new UI
> ideas is good, free code at least doesn't suck, and of course, for
> Novell, not shipping NLD10 is bad. I don't think there's anything we
> could have done to get more of the good without also getting more of the
> bad.
>
> -- Dan
>
>
> [1] http://www.unixguide.net/freebsd/faq/16.19.shtml
> [2] http://www.userland.com/whatIsStopEnergy
> [3] http://gnomerocksmyworld.blogspot.com/, Jan 29 to Feb 6
> [4] http://www.amazon.com/gp/product/0385721706/102-7630748-5396113
> [5] http://www.diacenter.org/km/usa/most.html
>