Re: Err..To Desktop Or Not To Desktop? writes:
> Lemmie clear a few things up, here..
> IMHO, Gnome would suffer greatly if there were no underlying foundation to
> work from; You can call this foundation a "desktop" if you wish, or at
> least something similar. Whatever you call it, it needs to be there,
> absolutely. Gnome, without an underlying foundation, would effectively be
> an incomplete design--And a good way to completely torpedo any hope of it
> becoming successful in the future.
> Gnome needs a desktop. Period. Now, whether or not >my< scope of influence
> is large enough that I can mandate how such a desktop is to be constructed 
> via the Style Guide, I dont know. I'll be talking to Marc Ewing (and a few
> others) at Red Hat on monday, to discuss this very issue. Some people want
> the Style Guide to simply address the format, layout and appearance of
> apps.. Others want it to be a completely communist manifesto on the visual
> layout and default appearance of everything top to bottom. Im prepared to
> do both, if asked.
> To stop with simply describing the form aplications are to appear in,
> without at least attempting to address the functionality and appearance 
> the underlying desktop, would, IMHO, leave the greater picture totally
> incomplete. Theres no use in my writing the Style Guide if im going to be
> forced to leave such a gaping hole in the overall design. An incomplete
> design leaves the door wide open to inconsistancy, and the tendency of
> coders to stray from established guidelines, which blows the whole point
> of the Style Guide to begin with.
> Now, if it turns out that following my talk with Marc and the others, that
> my creative freedom in this DOES extend further than just covering the
> appearance of apps, you can be absolutely certain that I will end up call
> for a standardized desktop. By standardized, I mean only in its
> functionallity. The physical appearance of which can't be enforced by a
> style guide--Its up to the users own personal tastes and preferences.
> "Standardized functionality" roughly just means "Were going to have a
> desktop. The desktop must have these things..blahblahblah, blahblahblah, a
> clock, and a trashcan.".. Just the same as describing something like a
> flag as a "Were going to have a flag. A flag is a sheet of fabric,
> blahblahblah, optionally displayed on a pole." ..And NOT describing what
> colors it has, what emblem it shows, etc. Thats not my job.
> I've been asked to write a Style Guide. What that encompasses, right now,
> is still a little up-in-the-air. Its not my place to decide what the style
> guide SHOULD encompass.
> Any feedback regarding the issue would be greatly appreciated, in the
> meantime.

I apologize for quoting this message in full, but I couldn't find
convenient pieces to respond to individually. IMO, you are missing
several important points.

1) The Style Guide is to be a standards document, not a design
document. The point of the style guide is so that any Joe Application
Author can read it and meet all the criteria, thereby coming up with a
compliant application which will fit into the desktop. While a design
document for what the Gnome desktop as a whole should look like may be
worthwhile, it has no place in a standards document. Who would it be a
standard _for_? There aren't going to be multiple implementations of
Gnome which need to be made compatible. Hell, you could just post on
the list and say, "when the default Gnome install pops up, it should
include X, Y, Z and a trashcan, IMO" and if people think that's a good
idea, they will implement it. Further, if this hypothetical "standard"
would mean that I, as a user, could not remove some of these
components if I didn't like them, then in _my_ opinion it has no place
in Gnome at all.

2) To get anything you write, whether a proposed standard or a
proposed design document, to be adopted and actually used, you must
seek consensus. There is no one person, neither Marc Ewing nor Miguel
de Icaza nor even Richard Stallman himself whose blessing could make
the community accept your as-yet unwritten designs. The only way you
can do that is to get a rough consensus, and that can best be achieved
by presenting all your work to the community while it is progress for
constant feedback and refining.

3) Wether or not someone wants a monolithic overall design imposed by
a single person from above is irrelevant, because it can't work. This
is not proprietary software development. You can only get the coders
to do what you want by convincing them they want to do it.

In summary, your creative freedom extends exactly as far as you are
able to convince others to follow it.

 - Maciej

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