Re: [Usability] Question: design choice of menubars

[Curtis Hovey <sinzui cox net>]

On Mon, 2004-09-20 at 10:39 -0400, Sean Middleditch wrote:
> 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.

Rage on comrade.  Why can I not change the file to +w to save my changes
from the file menu?  While the application may have special operations
it can perform on a file, like encrypt, or set metadata, I think it
should also have some of the options from the nautilus context menu too.

<snip>

> 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.

Yes. Yes. Yes.  App preferences.  About this app.  Check for updates.

> 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.

Sean, give us the name of the truth serum your on.  This could be the
very word from $god herself.
 
-- 

__C U R T I S  C.  H O V E Y____________________
sinzui cox net
Guilty of stealing everything I am.