Re: ANNOUNCE: Style Guide available for review.

["Shawn T. Amundson" <amundson CompleteIS com>]

On Fri, 13 Feb 1998, Peter Norton wrote:

[explainations deleted]

You explainations were OK.  They are all highly debatable, but so
would be anything I would respond with.  (such are gui discussions)
Perhaps they would serve as a good starting poing for enhancing the
style guide even. ;-)

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

Here is a sample of what I think the style guide should contain:

1 Intro

[Insert that bit I wrote in the old style guide somewhere somewhere here, 
 and include pointers to good books and other sources of information about
 GUI design.]

2 Application Appearance

2.1 Menubar 

Menubars serve as a consistant starting point in an application.  For
applications that do not have their nature as a 'utility' program, this 
is essential.  For an explaination of 'utility' program appearance see
section 2.19.

Menubars should contain a 'File' menu which is the first menu button
on the left side.  Usage of the 'File' menu in all GNOME applications
guarentees a consistant interface, and allows the user to find the
'Exit' or 'Close' function quickly.  For more information on why we
do not allow things like a 'Game' or 'Task' menu, please consult
[insert some reference material on UI design here].

The 'Help' menu should be contained for all applications.  Under the
'Help' menu should be an 'About' menubutton which will pop up 
information on authors and copyright.  The GNOME about dialog is 
provided in the GNOME UI libraries for this purpose.

[Perhaps a code example of how to properly set this up using the C 
 GNOME libs, and definately screenshots.]

...

2.19 Utility Applications

In general, your program should not be considered a utility program if 
you present the user with more than one dialog of information.  Examples 
of utility programs include a calculator, system volume control, and cd 
player tool.  Even these are debatable because you may need dialogs for
configuration, in which case you should not consider your application
a utility program. 

You can allow the user to configure the menubar and status bar in the 
application to not show up, see section 2.xx on when this is allowed.  If
this makes sense for your application, it is not a suited to be a utility 
application.

A utility application must follow the guidelines for displaying a dialog
to the user, as described in section 3.

...

3 Dialogs  

3.1 Provide an Exit

Provide the user with an easy, clearly defined, non-destructive
exit.  This should usually be in the form of a 'Cancel' or 'Close'
button.

...

--
Shawn T. Amundson		Complete Internet Solutions
Senior Systems Administrator	Minneapolis, Minnesota, USA
amundson@CompleteIS.com		http://www.CompleteIS.com/~amundson

while (i) { last }
    i, do exist.
    forever;