Re: [Usability] Question: design choice of menubars

[Sean Middleditch <elanthis awesomeplay com>]

On Mon, 2004-09-20 at 15:17 +0100, Calum Benson wrote:
> > Given that context menus generally aren't supposed to show you anything
> > that you can't already get done using other buttons or the menu bar
> > itself, that wouldn't be too huge of a problem, would it?  It would just
> > get rid of having two separate menu for doing largely the same thing.
> 
> That's true of course, but they do save you the trouble of hunting
> through the entire menu structure for things you can do to the selected
> object.  Once you know what those things are and where they live on the
> menus, their advantage is certainly somewhat reduced, although the
> interaction required to select something from a context menu is still
> likely to be less than from a full set of menus.

I'd argue that means the main menu is designed poorly.  In fact, the
current menu structures, even as defined in the HIG, seem fairly poorly
chosen.  The main menu entries are group by broad and/or abstract
topics, and not on function.  The File menu is a perfect example.  It
works "on the file."  Although many of the operations in that menu
aren't even related to the file; there might not even _be_ a file.

Another bad menu is View.  Many apps mix entries that affect application
behaviour, document behaviour, and current context/selection behaviour
into that menu.  When someone is thinking about viewing a particular
type of information/item (like a toolbar), they don't think "view-
>toolbar", they think, "toolbar->view".  Even us English speakers (with
out subject, verb, object sentence structure) usually think in terms of
object->verb, not verb->object.

One thing I'm rather fond of in OS X is how the menus have an
application entry for things that affect the app as a whole.  (Although
OS X still gets it wrong by mixing some document-stuff in there.  Also,
I believe the entry should use the generic name, not the applications
name.)  All app-wide settings should go in this menu.  About,
preferences, etc.

Instead of File, then, there should be Document.  And non-document
oriented apps should not be required to have a menu entry named File
just to stick things like Close in.  (I get a lot of "What?"s when I
tell people to go to File->Print; they don't seem to associate Print
with the File.  Document->Print makes a lot more sense.)  The Edit menu
is another one that could use some rethinking.  Copy isn't an edit.
Edit->Copy doesn't seem to make a lot of sense.  Clipboard->Copy might.
(Although I'm not sure one wants to make heavy use of the word
Clipboard...)  Find also probably doesn't really belong in Edit - it's
not an edit.

Also, the actual menu items shouldn't be limited to being in only one
menu.  If you have two main menu entries that both seem fit to have the
menu item, why not put it in both?  It's like the difference between
hierarchal bookmarks and Epiphany's keyword based bookmarks.

> 
> One solution could be to have a menu on the menu bar that just had the
> context-sensitive items on it... but then you still have to select then
> move, rather than just right-clicking an object to both select it and
> display its context menu at the same time.

If we're talking about something like a radial menu, it might make sense
to have the initial ring display the context-specific entries, with one
ring entry being the more general application entries.

I don't really have a whole lot of experience using radial menus,
though; they are a bit rare.  I'm not sure how bad they would get if
they were really cluttered (compared to a normal menu bar) or the best
exact behaviour.  (Click to select an sub-menu vs delayed hover, display
both parent ring and current ring, display child ring on hover, etc.)

> 
> Cheeri,
> Calum.
> 
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.