Re: fundamentals of the gnome user interface

[sungod <as387 yfn ysu edu>]

Bowie Poag wrote:
> 
> >
> > also, be aware (bowie, this is for you, because it applies directly what
> > you said about "levels" and programmable icons and such) that
> > implementing tier 2 does _not_ necessarily mean sane keyboard shortcuts.
> > for a text editor or irc client it does, but a power user in the gimp
> > should not have to take his hand off the mouse while stretching a
> > rubberband box to reach the "p" key while pressing "control" in order to
> > apply a transformation of some sort. see what this means?
> 
> Of course...

{deletion]

okay, folks, well, the general principle of what this post was
originally about has been generally agreed upon so i'm going to type it
up in a "style-guide-friendly" format after i finish my homework so it
can be included in the fundamentals section. any last-minute thoughts
about "casual users" vs. "power users" (which i've started calling "tier
1" and "tier 2" for some stupid human need to organize and categorize),
please send them to me asap.

> By describing the macro icons thing (i'll spare you the formal name..hee)
> that we worked on in InSight, I was merely trying to point out in an
> exterior sense that new ideas should be flexible enough to meet the
> definition of "Gnome Compliant", by their very design. We dont wanna nail
> any coders down to a standard from which they may NEED to stray from, in
> order to be original, and unique. Sometimes, the best approach ISNT to
> have easy to read menus, keyboard shortcuts, etc.. The wording has to be
> flexible enough to encompass any "good" application.

i stated my disagreement with this back when we were talking about, say,
kai's power tools and all the other diy interfaces that have started
cropping up in defiance of apple's style guide: the style guide is to
_enforce_ consistency, not to be so vague as to give every programmer a
warm fuzzy feeling that his nasty interface with no design thought is
"okay." as authors of a style guide, all we have to do is write the
bitch then sit back, prop our feet up, have a cold one, and cope with
the fact that some people don't give a damn about our style guide and
are going to do whatever the hell they want to do anyway. :)

the fact that the apple style guide does not allow for kai krouse to
design his own interface does not mean that kpt is a bad program, nor
that the apple style guide is a bad document. nor, i doubt, are the
authors of that document losing any sleep whatsoever. let's try to
follow this model.

before you flame me for this, let me add my agreement that flexibility
_is_ still important, and that's why i am so keen on getting the
founding principles laid out first. for example, while you say we
shouldn't specify "easy to read menus," i say we _should_ specify this
but not specify that menus must have exactly .50000 inches between menu
labels.
-- 
 ______(sungod)_____________________________________
| To ensure privacy and data integrity this message |
| has been encrypted by using dual rounds of ROT-13 |
 --------------------------(as387@yfn.ysu.edu)------