Re: RSG




-----Original Message-----
From: Bowie Poag <bjp@primenet.com>
To: Tom Vogt <tom@lemuria.org>
Cc: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Saturday, August 01, 1998 4:33 PM
Subject: Re: RSG


>> 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.


Gotta disagree with you here, Bowie.  Part of the "Look and Feel" of Windows
is the absolute mess the Start Menu gets into.  It's the responsibility of
the style guide to define a base look and feel such that if the user *wants*
to diverge, they can, but only to make things even better, not to correct
our mistakes.

>> 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.


One can have impossible goals.  World peace is an impossible goal but we can
and should still work towards it to get as close as possible.

Sacrifices may be made, but I've never been a fan of assuming dumb users
should stay dumb.  That's why I love the keybox--through simple pavlovian
reinforcement, the user becomes more and more of an expert.

>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.


KPT breaks all sorts of rules, but it's really an exception app.  I see your
point, but I think what's being said here is something like "Any time
control-C is highlighted and text is selected, that text must be copied into
the clipboard."  I have ZERO problem with saying that any app that doesn't
do this is buggy.  NONE.

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


The big problem I see with C1 through C5 is that Microsoft claims C2
compliancy.  Couldn't we use GC1, or just G1?

Ascending v. Descending...hurm, things get MORE compliant, not less, no?

>>
>> 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.


True gnome apps have Gnome-specific features that *may* be missing but
aren't exactly bugs if they're not there.  I don't have a problem with this,
really.  The name is more bothersome.

>While we're on the subject, there ARE things which SHOULD be manditory,
>across the board, in order to be even rated for compliancy.


That would be the C1 category.

>>
>> 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.


A completed suggestion that isn't really mandatory would go in here.  I
don't really like this category--what if a user expects C4 functionality in
an app without it?  They'll bitch about an inconsistent interface.  But,
then again, C4 gives the style guide permission to describe cutting edge
functionality without mandating that C3 apps be upgraded if they want to
keep their compliancy through a style guide upgrade.

>>
>> 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.


This is a *perfect* place to put all "in development and are probably better
than existing methods" appendix items.  However, I think that C5 items could
fall into C2 or even C1 as the style guide gets revised.

>> 3.1  MENUS
>> ----------
>> C1 -  If an application uses a menubar, it must contain at least
>> two entries: "Prog" and "Help". A third entry, "File" must be available
>> if appropriate. In the event that the name "File" is not
>> appropriate, another label may be used in its place. In the
>> remainder of this document, this menubar entry will always be
>> referred to as the "File" entry.
>
>Again, "Prog" is an indeterminant word. There is absolutely no reason to
>truncate this from "Program". If you do so, you break visual consistancy.
>Thats a no-no. If youre going to do that, theres almost no point in even
>writing a style guide to begin with. If you dont set a good example, do
>you think anyone is going to come along that will?


I REALLY DON'T WANT THIS MENU:

Fil  Edt  Vw  Ins  Frmt  Tlz  Cmpz  Hlp

>And where do these buttons go? Stuff to think about as the clarification
>process continues.


Style guide must be heavily illustrated.

>> C2 - The "Help" menu must contain at least one entry called
>> "Gnome", that starts the Gnome helpbrowser with its main page.
>
>Hmmm.. Ill think about this one more before commenting.


I like the concept, but not the name.

>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. :)


Pie menus have been proven by research; it's really not our place to deny
them.  Anyway, if we want the programmers to do something a certain way,
it's up to the style guide to describe it, no?

I see your worry, though.  If *every* single proposal made it into the C1-C5
heirarchy, it'd be a HUGE style guide.  But lets do it like this...really
good proposals get put into C1-C5, and stuff that's Not There Yet or
conflicts with C1-C5 goes to the appendix.

>> 3.2  DIALOGS
>> ------------
>> C1 - All dialogs should have at least one button that is labeled
>> "Close", "Cancel", "OK", or "Apply."
>
>This is vague. Do they need all four? Does the "OR" mean all three, with
>the option of a fourth? ..Get my drift? You have to keep these kinds of
>things in mind when writing a Style Guide--Because someone IS going to
>come to it, looking for clarification.


Yup.

>>
>> C2 - Modal dialogs should be avoided wherever possible.
>>
>
>Agreed.


No.  This needs to be EXTREMELY clear, with the hows, the whys, the whens,
and the what-else-you-should-do's.  Or else, it just gets ignored.

>Some mention needs to be made around here, of the physical location of
>such buttons. There's a whole chapter in UISG V2.0 dedicated to window
>construction issues like this.


Lets study the hall of shame here.




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