Re: i've asked the question; now i'll give my opinion

[Bowie Poag <bjp primenet com>]

In response to..

> the question i've been begging everyone to answer is, what line are we
> drawing? are we aimed at compatibility with existing guis, or are we
> aimed at good design? here is my response to this question:

..and..

> 
> if the "interesting new techniques" comprise better design than what
> other ui's have now, why shouldn't we?


A) If a style guide is to tie itself to the present, what begins as a
   foundation to work from soon becomes a 600 ton boat anchor you
   cant get rid of. So long as you have the opportunity to, IMHO, you
   should start clean. By starting clean, I mean, take what looks good
   now...analyze WHY it looks good, and performs well, and has all the
   attributes of good design. Ask yourself, "What are these attributes?"
   or "What facets of this program are more enjoyable to use than
   similar methods used in other programs?" .. Once you know what works
   best most often, you can begin constructing a document which lays
   out this stuff in detail. Analyze first, then write -- Not
   "analyze as you go" , as is so often the temptation.

   A style guide should be a reflection of both what exists already,
   and what SHOULD be done.. It should NOT be a reflection of, "People
   seem to like this, so we should keep doing it this way without
   regard for the future."

B) On the topic of interesting new techniques, these things were
   eventually going to be *included* within our style guide, but
   not as requirements for any compliancy levels. Specifically, they
   were to have been placed in the Appendix, and simply *referenced*
   in the doucment. That way, provisions were made for coders who
   DID want to include such things, and not break compliance with
   the guide. Nobody seemed to notice this a few months ago, why
   we ended up doing it this way..bleh.

   Overall, I have to say that I dont think there is much of a place
   for exotic technologies within a style guide, as far as mandating
   them goes. Trust me, i've authored a few papers on just such 
   things. While mine and others are certainly good ideas, they 
   need a little more "time in the lab" before theyre ready for any
   sort of mainstream use. Such things occur in the natural evolution
   of a system.. They'll eventually rise to the surface if theyre
   meant to.. Self-documenting interfaces, color-reactiveness, and
   others should (and must) remain with question marks hovering over
   them until the needs of the future mandate their inclusion.

With any style guide, you want to START by making a document as solid
as possible, and end its lifespan by making as few amendments and
changes to it as possible. A good document wont need to be put
through the revision process very often. 

Try shooting for a target lifespan, like we did. Aim to construct a
document that you could still deem viable in X number of years, and
keep chipping away at the goal until you HAVE that level of consist-
ancy required to pull it off.

Moses didnt go up on the mountain to come back down and give his
people utter shit. :) So long as youre going up the mountain,
make it worth while.. Moses came back with a style guide that
(so far) has lasted a few millenium. Surely, we can at least aspire
to do the same for a cause as holy as GNOME. :)

Bowie