Tutorial and guidelines: Menus (long message)

From: Otto Wyss (otto.wyss_at_orpatec.ch)
Date: 06/28/04

Next message: Nick Landsberg: "Re: Tutorial and guidelines: Menus (long message)"
Previous message: NoSpan: "Re: artsmidi.h"
Next in thread: Nick Landsberg: "Re: Tutorial and guidelines: Menus (long message)"
Reply: Nick Landsberg: "Re: Tutorial and guidelines: Menus (long message)"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Mon, 28 Jun 2004 23:15:44 +0200

# Do only discuss this guideline, for any other remark change the
# subject send it only to wxguide-users mailing list. Do not
# answer after the next message is sent or only to wxguide-users.
# If you think it's just "bull***" or simply "not worth" just
# stop answering. I'll stop if I don't see any interests.
#
# Please shorten your answer and quote as less as possible. I know
# what I've written or can look in the archive.
#
# All samples have been removed to shorten the message

3. Menus
First of all only top level menus have a menubar, child windows don't. A
child window usually does just a specific task, easily handled by some
buttons. If this isn't sufficient for a child window it should be
changed into a top level window itself.

Menu entries provide access to any action or command an application
provides within a graphical user Interface (GUI). While each action
usually has a menu or a submenu entry, it is common practice to move
seldom used actions into dialog boxes, etc. Menu entries which do this
are shown with ".." appended.

Menu entries are a kind of minimal help which show which actions an
application provides. Therefore actions (i.e. their menu entries) which
don't apply are still shown but disabled.

Menu entries should be generally being static, inserting and deleting
entries should only be performed if other conditions (such as a changing
set of files) requires it. Entries which are currently unavailable
should be disabled.

Menus have a limited count of entries ranging from 1 to about 15
depending on the size of the application top level window. A larger
window may allow for more a smaller for less entries. To reduce the size
of a menu submenus for related entries may be used. Or if the
functionality allows a menu may be split into several. Be carefully it's
obvious for the user to find out where an entry is located.

There is a convention of several standard menu entries in a defined
structure which an application should follow. If a standard action is
never available in an application the corresponding entry should be
removed. Such entries can't be reused by other actions unless these
actions follow a similar principle.

3.1 File menu
This is a standard menu, always the first. Most of the entries in this
menu are also standard, sometimes some might be missing and some might
be additional (i.e. not all application have recent file entries).
Usually this menu looks rather similar between different applications.

In case an application doesn't act on files this menu might be removed
or renamed to a more appropriate name. I.e. games should use a "Game"
menu, databases should use a "DB" menu.

The entries in the file menu have their defined command keys as shown in
the sample, if they have any. These keys are reserved and may not used
elsewhere, not even if the corresponding menu entry is missing.

3.2 Edit menu
This is a standard menu, always the second. All the clipboard entries
are standard, the others are optional depending on the functionality of
the application. Also depending on the application there might be
several additional entries.

If there were lots of entries in this menu, all the find and replace
entries could be packed into a submenu. This applies also to the
additional application specific entries.

The preferences entry depends highly on the used platform and might be
located in a tools menu (Windows) or in the file menu (Macintosh). It is
up to you if choose the native form or the cross platform form but never
us a native one on another platform. Cross platform applications should
keep the preferences as the last entry in the edit menu.

A similar problem arises with the shortcut key for the "Undo" entry,
it's either Ctrl-Y (Windows) or Ctrl-Shift-Z (all others). Do the same
as above.

The standard entries in the file menu have their defined command keys as
shown in the sample, if they have any. These keys are reserved and may
not used elsewhere, not even if the corresponding menu entry is missing.

3.3 View menu
This is an optional menu, always the third if present. All the entries
in this menu are optional.

3.4 Application specific menus
These are optional menus. Usually they have some common names like
"Extra", "Tools", etc.

3.5 Window menu
This is an optional menu, always the second last if present.

3.6 Help menu
This is a standard menu, always the last.

3.7 Menu shortcuts
The shortcuts for standard menu entries are always reserved and may not
be used for other entries. I.e. if there isn't a print action and
therefore the "Ctrl-P" not used, it should not be used for another
action.

Shortcuts aren't translated in international version as long as the used
character set allows it. I.e. the action print, in German "Drucken"
still has the shortcut "Ctrl-P".

Shortcuts always follows the platform dependent notion, this means
"Ctrl" is on Windows the control key, on Linux/Unix the meta key and on
Mac the command key.

See "http://wxguide.sourceforge.net/guidelines/menus.html".

O. Wyss

-- 
See wyoEditor at "http://freshmeat.net/projects/wyoeditor/"

Next message: Nick Landsberg: "Re: Tutorial and guidelines: Menus (long message)"
Previous message: NoSpan: "Re: artsmidi.h"
Next in thread: Nick Landsberg: "Re: Tutorial and guidelines: Menus (long message)"
Reply: Nick Landsberg: "Re: Tutorial and guidelines: Menus (long message)"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]