Re: Menu Guidelines



colin z robertson wrote:

> As always, tell me if I've done anything wrong or if there's anything
> that you can't understand. I apologise for the fact that this is even
> less interesting to read through than the dialogs stuff.

Looks fairly non-controversial so far  :)  Here are my comments...


File menu
---------

Mac standard or not, I've seen "Close" and "Quit" in the same menu cause
considerable confusion before.  People sometimes hit "Close" expecting
it to close the application rather than the document, and sometimes they
hit "Quit" expecting it to close just that window rather than all the
application's windows (e.g. in the Netscape/Mozilla model).  The
confusion isn't helped by the fact they're right beside each other on
the menu.

Since "Close" only makes sense in a document-based app, perhaps it would
help to always include the relevant document and application name in
those menu items?  E.g.:

   Close myhomepage.html  Ctrl-W
   Quit Mozilla Ctrl+Q

Or if that idea doesn't appeal, perhaps the recent files list could be
used to separate the two items instead, to minimise the risk of error,
since presumably any app that has "Close" should also have a recent
files list?  That is:

Close Ctrl-W
---
<Recent File list>
---
Quit Ctrl-Q

(This admittedly brings the recent file list back out of the sub-menu
you've suggested for it, but personally I prefer that as it's supposed
to be quick to access.  But maybe I'm just too used to the Windows Way,
I guess the sub-menu is still quicker than the File>Open dialog.)

"If the window being closed is the last open window of that application
then the application should exit."  Hmm, I'm not sure about this one at
all, people often want to close all their open documents before they
start a new one, so they'd be rather annoyed if the application closed
before they got the chance.  

On a similar note, I'd quite like to see a "File > Close All" menu item
on all applications that support multiple open documents (which would
prompt you to save any unsaved changes, of course).  It's a really
convenient feature in those apps that have it today.


Edit Menu
---------

Separate Undo/Redo menu items tends to suggest multi-level Undo... if
the app only supports one level, should we suggest a single menu option
whose label changes between Undo and Redo instead?  Or would one of
"Undo" and "Redo" just always be greyed-out?  (Can't say I really care
much either way, but traditionally it's been done the first way, so the
guidelines should probably at least say something about it).

What about the concept of "Repeat" (which is basically "keep redo-ing,
but to my new selection", as supported by M$ Word etc.), is this
useful/widespread enough to be worth providing a guideline for?


Options Menu
------------

Ah, okay, you've solved the "Preferences/Settings" debate by using the
most neutral term for the configuration menu title :)  

If I was being particularly perverse, I'd mention that in the past, when
working on financial applications, I've had to go against guidelines
that recommend an "options" menu, because "options" means something very
different to stock traders and the like.  Entirely coincidentally, those
apps were being designed to run under CDE on Solaris, which rather less
coincidentally will soon be replaced by GNOME on Solaris, so when they
port they'll have to break the guidelines again  :)  

But admittedly that's a very specific and isolated situation where the
guideline would have to be broken, it just happened to come to mind.


Help Menu
---------

Personally, I'd also like to see a "Search Help" menu item by default,
possibly even above "Help Contents"-- searching is probably about the
most common thing people do with a Help system, and support for an
(initially primitive) Search capability is being added to
Scrollkeeper/Nautilus Help sidebar as we speak.  (This assumes that
everyone would be using Nautilus or some other search-enabled viewer,
though, which may not be a valid assumption?)

"About appname..." -- don't think this should have the trailing
ellipsis?  Well, not if we're sticking to the traditional definition of
what the ellipses mean, anyway.

Er..., that's it :)

Cheeri,
Calum.

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

Any opinions are personal and not necessarily those of Sun Microsystems




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]