Re: RSG

[John R Sheets <dusk smsi-roman com>]

Bowie Poag wrote:

> > the purpose of this document is to set forth guidelines for a consistant
> > Gnome Look & Feel.
>
> You cant dictate "look and feel". You can only describe the elements which
> make for consistant design and implementation. Its not the purpose of a
> Style Guide to preclude the user's personal tastes.

"Guidelines" _are_ suggestions, not dictations. And because we allow for different
degrees of GNOME compliance, an app can diverge from the look & feel and still be a
(lower compliance) GNOME app.

> > The additional goal of this Style Guide is to make the interface as easy
> > and intuitively as possible, without taking away power and customizability.
>
> This is impossible. Sacrifices are made across the board to arrive at an
> equilibrium between the needs of the user, the needs of the programmer,
> and the needs of GNOME.

And this is exactly the compromise that Tom (as I understand) is referring to here.
Intuitive vs. Powerful.  This is the central struggle of UI design.  This sounded
quite clear to me.  I don't see the problem.

> > the levels of compliance are:
> >
> > C1 - Mandatory (bare minimum)
> >      Contains only the essential styles, so current programs can be brought
> >      up to at least some level of compliance fast.
> >      C1 features are considered to be of primary importance and non-compliance
> >      will be considered a bug for Gnome applications.
>
> Non-compliance isnt a "bug". There will be (and will NEED to be)
> applications which are INTENTIONALLY non-compliant. Example: Kai's Power
> Tools. Doesn't follow a stich worth of the style conventions of Mac OS.
> Its still a good interface, strongly bound to its functionality. You cant
> enforce style--only suggest it, and offer incentives for improvement.

This is a good point.  The Style Guide should leave room for applications with
special UI needs; however, often times these special UI's are not as needed as the
programmer (or user) would like to think.  To cover this, the Guide should recommend
that apps carry the standard UI elements as much as is possible.

A solution is to keep the first one or two compliancy levels generic enough to
handle all apps.  An app with an unconventional interface might qualify as a GNOME
app at level C1, but not make it to a full-blooded C2 until it offers an alternative
(i.e. parallel) interface that is in line with the Guide (while still maintaining
its own more-efficient UI).

Programmers are free to use whatever UI they want, but if they want to be a GNOME
app, they'll have to play ball.

> Compliancy levels shouldalso  be in ascending order, not descending. C5
> should be bare minimum, not C1, if you insist on abbreviating them that
> way.

I thought about this before my original proposal.  The problem with going the other
direction is that if we ever want to add a level, we'd be out of luck.  C0? C-1?
Not as intuitive as C6...C7...  The higher levels imply more, greater compliance.
That was my reasoning, anyway.

And even worse, what if down the line we decide to totally do away with the C5
rating (C1 if we do it your way)?  Suddenly we have a ratings scale of C2
(suggested) to C5 (bare minimum).  That quite simply won't work.

> > C2 - Recommended (needed for a proper Gnome app)
> >      Features and behavior needed to make an app a full-blooded
> >      Gnome app.
> >      Only C2+ compliant apps should be considered "true" Gnome programs.
>
> Define "true Gnome programs". I wouldnt exclude programmers in this way,
> if I'm reading you correctly. Programmers would begin following eachother,
> and not the guide.

???  You've got it backwards.  The selection of styles that we associate with C2
will define what it is to be a "true GNOME app".  By developing the style guide, we
are answering this very question.  That's what the style guide _should_ do.  If we
programmers don't like something, it probably won't make it to C2 anyway.  C2 is for
universally-accepted features. If it's not C2-certified, then it's not a true GNOME
app.  How does this exclude the programmers?

To put it another way, we're not defining C2 to be equivalent to a "true GNOME
app".  Rather, we are defining C2 as the generic cut-off point to the core GNOME
features, whatever that may be.

> > C3 - Suggested (should be there)
> >      More advanced, harder-to-implement features, beyond the
> >      call of duty, yet still within the core group of styles.
> >      Should, but don't have to be implemented in finished programs, in no
> >      way mandatory for development versions.
>
> While we're on the subject, there ARE things which SHOULD be manditory,
> across the board, in order to be even rated for compliancy.

Yes, and that's exactly what C1 (& C2) are for.  Did you read the post that you
quoted above?

> > C4 - Optional (fringe feature)
> >      "Nice to have" features that are considered useful, but may not
> >      be appropriate for all programs and are not necessary even where
> >      appropriate.
>
> How the heck are you gonna judge this concretely? This is way too big of a
> gray-area. Try defining things more precisely here.

Each style will be judged for compliancy on a case-by-case basis.  These compliancy
levels should stay generic.  Each level will (as things develop) become defined by
the styles that get attached to it.  This rating system is (and should be) a simple
measure of how important each style is to GNOME.  The more questionable a style is
(i.e. the less broad-based agreement it receives), the higher (and more optional)
the compliancy rating it'll get.  Point being, things will take care of themselves,
and the compliancy levels will solidify as we go.  For now, this definition is fine.

> > C5 - Under Development (cutting edge, not official style yet)
> >      Experimental features that are not fully implemented or
> >      supported yet.  (Will fall into C4 or C3 when fully realized)
> >
>
> These types of applications dont belong in the public domain to begin
> with, and therefore should not be judged for compliancy.

What about WM hints?  Color-reactiveness?  We can't ignore a feature just because it
isn't fully-implemented yet.  However, it would be a good thing for apps to be able
to declare their progressive, experimental nature.  C5 is a simple, intuitive way to
do this.

The problem I do see is: what if an app tries to implement an experimental feature,
yet hasn't reached full compliance, e.g. a C1 app.  We'd almost have to tack C5 onto
a primary rating, like C1 (5), to differentiate it from C2 (5) and C3 (5).  I'm not
sure how I feel about this.  Anybody have alternate suggestions?  The same could
also apply to C4...does an app have to already be C3-rated in order to qualify for a
C4 rating?  Hmmmm, I don't know.

Perhaps the solution is to only classify _apps_ as C1-C3, while classifying the
styles as C1-C5.  This would fit more with the current situation, where the first 3
levels require that _all_ the rating's styles are met before the app qualifies for
that rating; contrarily, the app can qualify for C4 & C5 by implementing _any_ of
the extended features.

We want to be able to keep track of all potential styles in the style guide.  C1-C3
are the official styles.  And C4-C5 (...C6...C7?) are the unofficial styles.  An app
can only be judged against an official style, so it can only achieve a maximum of
C3-compliance.  However, we can use C4 to let people know that so-and-so styles are
fully implemented and available for use, but are completely optional.  We can use C5
to show that so-and-so other styles are NOT fully implemented, but here they are and
do what you will with them.  Using a C4 or C5 style will not affect your compliance
rating (unless that style is later moved to C1-C3, thus breaking -- or saving --
your compliance).  We could announce in the About box that "This application
contains level IV GNOME elements", or whatever, to warn the user that the app may
diverge from the straight & narrow.

That would solve the problem I think, with only a small increase to the complexity
of the rating system.  Any problems with this?

> > C4 - [Pie Menus]
>
> Untested theories do not belong in style guides. They belong in public
> forums for debate, and THEN subsequent inclusion. Notice I dont intend on
> mandating color-reactiveness into UISG V2.0 .. Despite the fact that I
> think its an excellent idea. :)

I disagree.  (Although I should have put Pie Menus under C5 because they're not
implemented yet for GNOME/GTK+.)  For features that GNOME intends to pursue, these
entries should all be in the style guide.  Otherwise, we'll end up with a handful of
alternate implementations that may or may not fit into the larger picture.  If
someone wants to sit down and design a good GNOME pie menu, for example, they should
be able to look it up and see exactly what GNOME needs in a pie menu.  A little
guidance (being a guide, after all) goes a long way to prevent unnecessary
fragmentation.  The experimental nature is implied by classifying it as a C5 style.
Plus, the more we settle up front, the fewer ammendments we'll have to make down the
road.

John