Re: ANNOUNCE: Style Guide available for review.

[Kai Wetzel <k wetzel welfen-netz com>]

Shawn T. Amundson wrote:
[...]
> > > My only point is it needs to explain *why*.  It needs to give specific
> > > examples and explainations, not be a list we have all noticed about
> > > windows.
> >
> > I'm sure that in this sort of a venture, Sometimes the reason will be
> > "because it works".
> 
> I find no reason to follow the style guide if that is the reasoning
> behind the items on the list.  I think the reasons are there, they
> just need to be stated.

Good point.  This will also make it likely that people write
apps in the spirit of the guide even for areas not mentioned, yet.

> Here is a sample of what I think the style guide should contain:
> 
> 1 Intro
[...]
I'd like to see a section explaining fundamental HI guidelines
(like the Mac guide) in brief form as a rationale (kinda).

> 2 Application Appearance

How about introducing "Kinds of Applications" or "Categories
of Programs" (or similar) first ?
That way some forward references can be avoided.
I'll mention some below, but there are probably more good
categories which are special for one reason or another.

> 2.1 Menubar
> 
> Menubars serve as a consistant starting point in an application.
[...]
Hmm, I must admit that I don't like "starting point".
It's the central point where commands can be found, but
a "starting point" ?  Does the Mac guide explain this nicely ?

> Menubars should contain a 'File' menu which is the first menu button
> on the left side.
[...]
> For more information on why we
> do not allow things like a 'Game' or 'Task' menu, please consult

I think it's good that/if we do allow this.  In some cases
"File" is not only inappropriate but doesn't make any sense
at all.
 
[...]
> The GNOME about dialog is
> provided in the GNOME UI libraries for this purpose.

I like this part better then the new text.

[...]
> 2.19 Utility Applications

I would suggest the use of the following terms instead:
- "Desktop Accessories", like a calculator, a movie/cd player, etc. and
- "Control Panels", like a mouse configurator, an Apache configurator,
etc.
  Individual apps could expose their Options dialog to be invoked
  seperately, too.

> In general, your program should not be considered a utility program if
> you present the user with more than one dialog of information.  
> Even these are debatable because you may need dialogs for
> configuration, in which case you should not consider your application
> a utility program.

Which indicates that the amount of dialogs may not be
a sufficient indicator for beeing a "real application" or not.
Maybe we find some other indicators, but I expect it to
be anything but exact science.

[...]

kai