Re: The Help Menu





On Thu, 30 Jul 1998, Bowie Poag wrote:
> 
> > John R Sheets <dusk@smsi-roman.com> wrote:
> > > Question:
> > > 
> > > What should the behaviour of the Help menu item be if no help
> > > exists for an app?  Should it be grayed out (and if so, how will
> > > it know of the help file's existence?)?
> > 
> > the current style guide (see gnome.org) suggests that help ALWAYS has at
> > least one item: the about box.

I agree, this should stay.  The Help menu is a relevant place for About,
and many people are already used to finding it there.


> Bad idea. 
> 
> About does not belong under Help, because it has nothing to do with the
> concept of "Help". Simply because no other suitable place can be
> immediately thought of for where to put it, doesnt mean that we should
> throw it under Help, IMHO. That would be just as illogical a move as if we
> were to throw it under Edit, or something equally uncalled-for.

Help is an appropriate place to put About.  In an Open Source program, if
you are having a problem, when all else fails, you can email the author.
The About screen is a critical piece of Help.  It is not anything else but
a critical piece of help.

 
> The final draft (again, after a fully formed document has been released,
> looked at, and subsequently revised by the public a gazillion times before
> it becomes a FINAL DRAFT) will likely propose a new addition to the
> standard gamut of "File / Edit / View / Options / Help / Preferences" ..

This is not a standard gamut, nor should it be.  I would argue strongly
against all of these menus being standard.  We need to require as few
menus as possible, so when the developers come up with all the other menus
that their application requires, the application can still fit in 800
pixels wide.


> For example, I see nothing wrong with:
> 
> +-+---------------------------------------------+-+-+
> |O| Application                                 |^|X|
> +=+=============================================+=+=+
> | 8'  File  Edit  View  Options  Preferences        |   
> +---------------------------------------------------+
> |  +-                                               |
> |  |\                                               |
> |    \                                              |
> |   Little Gnome Footprint                          |

I see many things wrong with it.  First off, having an Icon for a menu
heading will have new users not realizing it is a menu.  Second of all, it
will make it far more difficult to support GNOME users, a text menu you
can just say "Click on Main", and a user will look around for the word
"Main" on the screen.  I don't want, when giving phone support, to have to
say, "OK, now find file...ok, don't click on it, now see the little
footprint... no not the big foot on the bottom of the screen... yeah, that
little kidney-shaped thing right next to file, click there."  

Macintosh can get away with it, because no matter what happens to the
system, there will always be an Apple, and it will always be in the top
left corner of the screen.  GNOME applications will be coexisting with
non-GNOME applications.  Menus are standard, little pictures are not.
You'd be surprised just how many Netscape Communicator users have
absoutely no idea that that back arrow is a menu, even with the little
menu marker next to it.

Secondly, I see no Help menu there.  Many of the more compitent new user I
deal with, when first looking at an application, go straight to the Help
menu and start seeing what kind of information is there.  They don't read
through all the help, the just see how much and how detailed the help is.
I see no Help menu on your screen.

Thirdly, what is the difference between View and Options and Preferences?
Why are these menus?  View makes a certain amount of sense with
document-based applications, but no sense with many others.  I will assume
that one of the pair Options/Preferences is for controlling the documents
settings, and the other is controlling the application settings, although
it is far from clear which one is which.  Most applications I have seen
would bring up a dialog box for setting these.  The most complicated of
the applications would organize the dialog with a notebook.  Menus
should have more than one entry, and I don't see how these would have them
in most cases.


> A simple little Gnome Footprint present in the menu bar of each apps
> window would do the trick nicely, at first thought. I'm open to
> suggestions. Even yours, Tom. ;) hee

If all of these menus are standard, what is left to put in your Footprint
menu?


-Gleef



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