[HIG] REVIEW: Menus

[Calum Benson <calum benson sun com>]

Menus
-----

- Is the opening section in a FIXME state?  Doesn't say so, but seems a
bit like a random collection of ideas that hasn't been written up yet.

- "Organise menus according to... freqency of use": freqency->frequency

- "Unlike other controls, once a menu is posted...": this sentence seems
to be of little relevance to the designer or developer, only the user--
is it worth including?


Drop-down Menus
---------------

- Here and elsewhere, "head items" isn't a term I've ever come across
before, is it used in the API?  They're called "menu titles" in anything
else I've read, and elsewhere in this document, so need to pick one. 
(Not sure what the doc styleguide calls them).

Popup Menus
-----------

- "Provide an access key for each item":  Also, if possible, make it the
same as the corresponding access key on the main menu.


- "It would look rather odd to have Properties after Input Methods": I'm
fine with this, as long as we have a suggested consistent structure for
popup menus.  The one I originally suggested was just lifted from
Windows as an example.


Menu Item Types
---------------

- "Provide an access key for kind every menu item": typo, remove "kind".

- "...except separators": and tear-offs, presumably.  (Is there a
shortcut for tearing off a menu item, BTW, and if not, should we define
one?)

- "Head items": see earlier comment

Separators
----------

- "groups of two to about five items should be separated...": passive,
rewrite as "separate groups of two to about five items..."

- "the items withing a group should be ordered...": passive, rewrite as
"order the items within a group..."

- Another useful guideline here is that mutable and command items
shouldn't be placed in the same group, as the command item could look
like a mutable item

Command Items
-------------

- "Use Control as the modifier key in the most frequently used shortcut
combination for a regular key": pardon? :)  Didn't understand this at
all... also, are we using "Control" or "Ctrl"?  Currently we use both,
need to pick one.  Dunno what the doc styleguide suggests.

- "should we reserve Alt as a modifier for window manager operations?" 
If we do, we need to decide what to use as access keys for the recently
used file list, apart from anything else.  The keyboard interaction
section would also need a little judicious editing :)

- "items should not be given an ellipsis to indicate only that...":
passive, rewrite as "do not give items an ellipsis to indicate only
that...".  Also, might want to list the most common items that should
not have an ellipsis, e.g. Properties, Settings, Preferences-- almost
any instant-apply window, in fact?

Standard Menus
--------------

- "best way to present menus given the known variants"?  I vote for
segments but with some context, e.g. include the menu items immediately
above and below the one you're illustrating to show where it should go
on the menu.

Creation and Opening Operations
-------------------------------

- "the New item may be a submenu containing entries for these various
types": pic required

- "how to provide second read-only view of the same document?":  I'd
vote for having these as alternative Open menu items, e.g. Open->New
View (alternative view on same document), Open->Editable Copy
(independent copy of original version), Open->Read-Only Copy, to open
new copies/views of the currently-focused document


Saved State Operations
----------------------

- If a document doesn't need Saving, should the Save item be disabled?  

- If document does need saving, this should be indicated in the title
bar in a standard way (e.g. asterisk) and/or by changing "Save" to "Save
(required)"-- need to specify this somewhere

- "Should this be Save Copy As...?": I would say so, especially as a
different file format may be specified

Export Operations
-----------------

- "Send by FAX": not an acronym, so surely just "Fax"?


Closing Operations
------------------

- Should Ctrl-Q for Quit go away?  I don't have any strong feelings
eithe way, except to say that I use it all the time on Mac, as do the
few Mac users I just asked.  What is the fear here?  Pressing it by
mistake should never cost you any data anyway.

Edit
----

- Figure 3. "Insert...": should this be "Insert >" ?  There is no
discussion of this item in this section, so I couldn't tell, but from
its brief mention under the Insert menu it seems like it should be a
submenu here, not open another window.

Manipulating Selected Data
---------------------------

- "Cut... content should be removed in the same manner as Delete": don't
refer to something that hasn't been covered yet-- describe it here and
say "remove in the same manner as Cut" under the description of Delete,
if you have to.

- "Should Delete be provided from a menu?":  I'm tempted to keep it for
two reasons.  First, accessibility: if we remove it, the only way to
delete stuff is by using the Delete key, there is no mouse-only method
except in apps that provide a trashcan, which may not be acceptable.
(Whereas with your arrow key example, you can always move the cursor
with the mouse, without needing the arrow keys).  Second, it can provide
useful feedback about whether a selection is deletable or not,
especially if it is tied to a Delete button on the toolbar.

Searching and Replacing
-----------------------

- "Find Next... should be insensitive if there is no next instance":
hmm, this could be a little disturbing... if we do this, I'd maybe
suggest changing the menu item text to "No Next Instance" or something
as well for the duration.  (Ditto for "Find Previous").

View
----

- Figure 4: Does Gtk allow any way of displaying "Ctrl+Plus" and
"Ctrl+Minus" rather than "Ctrl++" and "Ctrl+-"?  It just looks a bit
silly the way it is.

Insert
------

- Where does the number 6 come from here?  I appreciate its good to
provide a guideline figure, but 6 isn't one we've used anywhere else--
we suggest groups of "about 5" items should be separated, for example,
so I'd suggest using 5 here as well if that's a number we're comfortable
with.

Format
------

- Need a better description of what sort of commands should go here;
generally it's those that add data to the document to describe how it
should be presented, as opposed to the ones on the View menu, which
change the external view of the document without affecting its content. 
Or something like that...