Re: Menu Guidelines

[Sinzui Kobalt <sinzui cox rr com>]

In scenarios where the application doesn't support documents,
'Application' should replace 'File'.  Besides games, I can
think of CD players, system monitors, and instant messaging
that don't use documents.  Allowing developers to
chose any menu name to replace 'File' introduces confusion
to users.  When the user sees 'Application' as the first
menu, they should immediately know they are using a stateless
tool.

I think 'File > New' is fine in most circumstances, but I
think it may optionaly have a submenu.  Some applications
support templates, and they may be listed under 'New'. Some
applications manage complex forms of data, such as Evolution,
which may create a message, a task, or something else. In
Evolution's case, it also has accelerator keys for each kind
of new thing, and uses 'Shift-Ctrl' with a key to create
the data type.  Should there be a convention like 'Shift-Ctrl'
to create new data types?

'File > Close' may need to establish context for multi-document
applications. 'Close abcdefg.txt', one of several documents
open in the current window for example.  If there is only one 
document open in a window, the file name may be omitted, but I think
it's good practice to always name the file that is being
closed.  Consider if foobar, aka menubar, evoloves to swallow
the menu bar of the active app.  In this circumstance, 'Close'
may refer to several windows, and some of those windows may
hold multiple documents.  Many gnome users desire a smart
menu bar, and we should have menu guidelines that don't break
when gnome gets one.

'File > Quit' is fine for now, but in the scenario of a smart
menu bar, it breaks.  The menu should read 'Quit xyz' if the
menu is divorced from the application/window it belongs to.
Actually, the user can move the menu bar outside of the window
now, so I think the application's name should always be dipslayed
next to "Quit'.

'Cut', 'Copy', and 'Paste' are fine in most circumstances, but
as the recent Nautilus debate illustrated, those names don't
make sense in cases like files, even though their function does.
I don't want to start another semantic fight, but if someone
has a cleaver answer to resolve this, I'd like to hear it.

Would adding 'app session' to 'Options' be smart? do any apps
support options that live only for the session?

'Help' could be better.  I think 'Search' would be a valuable
addition to the menu.  Could medusa be tamed to focus on just
the documents related to an application?  A good gnome help
system would let the user search just the application's 
documentation, or expand the search to the whole system.

'Help > About' has little to do the applications.  It is always
about the authors.  I have never read an 'About' that in one
sentence says what the application does.  Few 'Abouts' include site
information where the user can learn more about the application
or if upgrades are available.  Maybe I want better guidelines
about how to create an about dialog.

__S i n z u i___________________________________
sinzui cox rr com
Guilty of stealing everything I am.