Re: [Usability] Question: design choice of menubars

[Calum Benson <Calum Benson Sun COM>]

On Mon, 2004-09-20 at 15:39, Sean Middleditch wrote:

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

Well, the HIG does say that you shouldn't use "File" if your application
doesn't handle files.  But yes, there is a certain amount of historical
baggage in there as well (like always having "Quit" on the File menu),
which we've certainly talked about resolving via a Mac-like Application
menu before.

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

Just to confuse things, "View" is really a noun (as most menu titles
should be)-- it contains items that affect the view of the document or
application.  Unfortunately, most of the standard menu items can also
(and in some cases only) be regarded as a verb, which has led to some
(now-standard) ambiguous usage over the years.

> 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 an interesting thought.  Possible downsides that spring to mind
might be:

- an increase in the time taken to visually scan menus.
- consistency/learnability problems: an item may appear on menu X and Y
in one app, and the user might habitually use the one on menu Y.  When
they install an app that doesn't have a menu Y, they have to re-learn
it's "new" position on menu X, when they could just have learned to look
for it there all along.
- documentation issues (which menu item would you document?)
- user uncertainty (users wouldn't *really* know that the same menu item
on different menus did the same thing, unless they tried it)

It could also somewhat encourage developer laziness => distorting the
user model-- given a choice between user testing to work out the best
place(s) for a menu item, and just putting it in all the places it
seemed to make sense, I can't believe all of them would prefer the user
testing route :)

>   It's like the difference between
> hierarchal bookmarks and Epiphany's keyword based bookmarks.

Well, almost.  I still find hierarchical bookmarks far easier to work
with, but that's because *I've* decided where to put them, not some
developer :)

Cheeri,
Calum.

-- 
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson sun com            Java Desktop System Group
http://ie.sun.com                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems