[HIG] REVIEW - 2: Menus+Toolbars

[Calum Benson <calum benson sun com>]

2. Menus and Toolbars
---------------------

This whole chapter written in passive language... needs to be active. 
Needs more in the way of concrete guidelines.

2.1.1 Drop-down menus:

"Applications may possess a menubar"-- when should they and when
shouldn't they?  Hard to give precise guidance here, but might be good
to say something.

Should probably say that in general, only top-level windows should have
menubars, not dialogs or other secondary windows.

2.1.2 Pop-up menus:

What should we call these? Haven't checked GDP, but also known as
"context menus" (Motif) and "shortcut menus" (Windows).

Popup menus *are* (or will be) accessible via the keyboard in 2.0.

Some suggested guidelines:
- First item on popup menu should be default action (same as
dbl-clicking the selected object(s)), followed by other actions in
expected frequency-of-use order, followed by transfer actions (cut,
copy, paste, send to, publish).  Last item should be Properties, if
applicable.
- Everything in a popup menu needs to be available directly or
indirectly (e.g. in a dialog) from the main menu bar too
- Avoid submenus in popup menus
- Show mnemonics but not accelerators in popup menus (if this isn't
determined by the toolkit)
- Limit popup menus to ~10 items max, if possible

2.1.3 Menu Organistaion

Perhaps include something about how menu items should be ordered within
a menu, i.e. place frequently-used groups towards the top and bottom of
a menu.

2.1.3.1 Submenus

Avoid >1 level of submenu if at all possible, as they're difficult to
navigate (as you already say).

2.1.3.2  Separators

Keep groups down to ~5 items max if possible, and try to avoid groups of
1 item except at the very top or bottom of the menu.

Within a group, order by logical task order if there is one (e.g. Paste
after Cut and Copy), or by expected frequency of use.

Don't mix actions (inc. items that open dialogs) and settings (i.e. menu
items with checkmarks) in the same group.

2.1.4 Naming Conventions

Perhaps reference to the section I wrote about capitalisation here (if
people think that section is appropriate)

Give examples of what common menu items have ellipses and which don't,
e.g. Open... and Properties.

2.1.5 Unavailable Items

Context help for each menu item should include a list of reasons that
menu item may be disabled, and what needs to be done to enable it
again.  Is it even currently possible to get context help for a menu
item, by selecting it and pressing Help/F1?  (If accelerators are
locked.)

2.1.6 Toggled menu items

Should give indication of when two use two separate mutually-exclusive
menu items as opposed to one with a checkmark.  This is normally when
the mutually exclusive terms aren't naturally opposite (e.g. if the
options are "red" or "green" rather than "on" and "off").

2.1.7  Shortcuts and accelerators

Perhaps want to add short discussion about the merits/de-merits of
assigning F-keys as shortcuts-- not all keyboards have F-keys, but F-key
shortcuts can be more suited to international audiences as they have no
mnemonic relationship.

2.2 Standard Menus

Think we at least need something about a View menu, here (for commands
like Zoom In/Out, Toolbars, Status Bar, Reload/Refresh).

Help... should not be flush right-- I assume this is handled by the
toolkit anyway, so probably don't need to say it?

2.2.1 File

Should Close All perhaps have the shortcut Shift+Ctrl+W?

Still slightly disconcerted that Close and Close All aren't beside each
other, but I can sort of see the logic...

Should maybe be suggesting something like "Send To" and "Publish"-type
items, for emailing documents and publishing them straight to a website?

2.2.1.1 File Access

Open: "user should be notified via a dialog that the file is already
open".  Whenever we say something like this, we need to specify what the
message should say and what buttons should appear in the dialog, at
least until we have GNOME stock dialogs in place.  In this case, for MDI
apps, I'd like to see buttons along the line of Use Existing, New Copy,
New View, and Cancel... or whatever subset of those are appropriate for
the particular application.

Open Recent: I'm still not sure about having this as a sub-menu; I doubt
if I could be bothered looking in a sub-menu every time I opened a file
to see if the one I wanted was still on the list.

Wherever they end up going, the recent file list items should probably
be numbered, with the numbers underlined to be used as mnemonics.

Save: Should be disabled if the file is read-only.  Dialog should pop up
in this case, offering choice of Save As or Cancel.  Should change to
"Save (required)" when a document has unsaved changes?  Title bar text
also ought to change to reflect unsaved changes regardless (e.g.
"file.doc*", or "file.doc [unsaved]")-- not sure where in the guide to
say this.

Revert: Is called "Revert to Saved" in the menu example.

Close: Have to confess I didn't immediately understand the difference
between "SDI" and "controlled SDI" interface.  In fact thought it was a
misprint, because it says "if it's the last open document of an
application", and surely an SDI interface can only have one open
document anyway?  And there's nothing explicit in this section about MDI
apps at all.

2.2.1.2 Printing

Print: "brings up a print dialog".  I assume we don't have a standard
Print dialog in GNOME yet, but it would be good if we could at least
come up with a model one for people to follow. (Or if we do have one, we
should say so here and include a screenshot).

Print Preview: This too should be a pretty standard window between apps,
with a standard set of commands available on a menu and/or toolbar (zoom
in/out, next/prev page, print setup, print, close, anything else?).  So
we ought to specify those, too.

2.2.1.3 Quitting

Close All: "user should be presented with a dialog listing those
documents".  You mean one dialog, with a list control listing the
unsaved docs?  This could work, if you didn't have to manually select
the docs you wanted to save, then press Save-- I'd prefer either:

- List the docs in a read-only list, with the first one selected.  Have
Save, Close, Save All and Close All buttons in the dialog.  Save or
Close performs that action, removes it from the list, and selects the
next in the list if there are any left.  Or...

- Just present one dialog per document, each with Save, Close, Save All
and Close All buttons.  Disadvantage here is that you don't know which
documents have/haven't been saved until a dialog appears for it.

2.2.2 Edit

For apps where there are selectable objects whose properties you can
view or change, "Properties" probably ought to be at the bottom of this
menu.  The Windows shortcut for this used to be Ctrl+Enter, IIRC,
although that never really caught on...

(Of course, if you can only ever view properties in a particular app
rather than Edit them, you could argue this belongs on the View menu...)

2.2.2.1 Modification History

Should Undo history be saved with document?  (Probably not).  Should
Undo history be cleared after document is Saved?  Should we specify a
standard multi-level Undo/Redo dropdown list type thing for the toolbar,
like M$ Office has?

2.2.2.2 Clipboard Access and Deletion

Delete: When is it appropriate to use "Delete", and when "Clear"?  They
have different stock icons, and different connotations.

2.2.2.3  Manipulating the Selection

Select None:  I personally prefer "Deselect All" as its more visually
distinct on the menu (and so quicker to find), and seems to make more
grammatical sense... the notion of actively selecting nothing seems a
little odd to me.

2.2.2.4  Searching and Replacing

Find: Ought to describe somewhere the difference between "Find" and
"Search", and their appropriate usage: Find should be used for functions
that locate text etc. in the currently focused window, with results
highlighted in-place; and Search should be used for functions that
locate text etc. in locations (potentially) other than the current
window, e.g. mail folders, website, disk partitions.  Search results
generally shown in a separate window.

2.2.2.3  Options

Personally not sure that there's ever enough stuff on this to merit its
own menu, I always look for it first on the Edit menu.  I suspect a fair
number of apps would end up with a single item on this menu called
"Preferences" (or whatever term we pick for 'how the app behaves'),
which is a bit of a waste of menu space, really.

"Developers are encouraged to put settings that are likely to be changed
frequently in the menus as checkboxes or radiobutton groups"-- fair
enough, but they might not necessarily belong on the Options menu.  E.g.
(plucking a random example from Netscape), "View attachments inline"
might well be in the Preferences dialog, but might also be a togglable
item on the View menu.

2.2.4 Help

Search Help:  This is a bit ambiguous, could also mean "Help on how to
search".  Probably need to change to "Search for Help on..." or
something similar.

Should add that any additional items (e.g. pointers to FAQs on websites)
should go between "Help Contents" and "About".  Actually, we need to
specify for all the 'standard' menus where app developers should add
their own stuff.

2.3 Toolbars

This section is obviously perfect  :)

Oh, alright then...

Toolbar types: there are obviously a few different toolbar types
floating around just now (GtkToolbar, EToolbar or whatever Evo's is
called, etc.), and they all have quite a profound effect on the look and
feel of the applications that use them.  This isn't really a Good Thing,
we'd obviously like them all to use the same type, but I don't think
that's really an option until they're all consolidated into a single
control in core GNOME.

So, for now, what should we recommend about which toolbar control to
use?

Probably also need to say something about Palettes, which are basically
a special type of toolbar (but can't actually be created with a standard
toolbar control AFAIK, unless that's changing for 2.0).

2.3.1  Designing Toolbar Icons

This probably needs to be merged with a lot of Seth's stuff on icon
design, or vice versa, but I'm not sure where that section should end
up.

2.3.5 Default Toolbar Layout - Browser Applications

Unfortunately, the proposed default layout breaks quite a few of the
other toolbar ordering guidelines I've given elsewhere  :)  Nonetheless,
I think a browser toolbar is conventionally different from a
productivity app toolbar... how can we/should we go about reconciling
the two, or rationalizing the differences for the purposes of the HIG?