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. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list