Re: Menu guidelines updated

[Adam Elman <aelman users sourceforge net>]

At 9:02 AM +0100 8/10/01, colin z robertson wrote:
> On Thu, Aug 02, 2001 at 12:51:41AM +0200, Reinout van Schouwen wrote:
> >  * "Applications ... may rename this menu to either "Application" or, in
> >  the case of games, "Game".
> >
> >  I reiterate my objections against this idea. I am all for not having a
> >  compulasory 'File' menu item, but 'Application' is just as nondescriptive
> >  as 'File' is, and it does not take into account that some programs are no
> >  applications in the traditional sense. E.g. an utility that is used to
> >  view the system clipboard does not obviously operate on files. So should
> >  the leftmost menu item be called 'Application', then? Of course not, it
> >  should be 'Clipboard' (IMO). Please also see my post of July 10th.
>
> hmm. There are two schools of thought here. One is that the name of
> the first menu should be standard, the other is that it should adapt
> to its context even at the expense of consistency.

Well, remember that the whole point of consistency in UI is to allow 
the user to create a mental model of how to interact with the system 
which appears self-consistent and follows a set of rules.  As long as 
the rules are consistent and make sense, I think the user is better 
served by having names that adapt to the context.

OTOH, the problem there is that the "File" menu generally contains at 
least one important command which has nothing to do with a file per 
se -- "Quit".  I don't think it makes sense to have a "File" menu for 
an app that doesn't deal with files/documents, or doesn't deal with 
them as a primary operation.  But if you always have the Quit command 
under the File menu, you don't want it to go away either.  It's a 
catch-22.

I can think of two ways to fix this in the long-term (I'm sure there 
are many others):
1) Go the MacOS X route and add a window which is named with the name 
of the current application; this menu would always contain the 
"About..." dialog, the "Preferences..." option, and "Quit"; possibly 
other standard application functions as well (although I'm not sure 
what).  Apple also puts the "Hide" options that used to be under the 
app menu here, but I don't like that (and I'm not sure it'd work 
without significant WM modification anyway).  I like this option, as 
it also solves the "Edit -> Preferences..." vs. "Tools -> Options..." 
problem.

2) Get rid of the "Quit" option altogether; this involves moving much 
more towards a document-centric paradigm rather than the current 
app-centric one.  This is a little more radical. :)

>  > "...the user should be notified via a dialog that the file is already open
> >  and the window containing that file should be given the focus and raised."
> >
> >  What is the purpose of that dialog? The user has indicated he wants to see
> >  some file. Consequently the file is brought to the foreground. That the
> >  file was already open does not matter to the user, does it?
>
> hmm. Perhaps not.
>
> I'm actually a bit unsure about this whole thing. Should we deny the
> user the user the ability to have the same file open in two seperate
> windows?

Yes, I think we should, at least through this means.  There are, 
IMHO, better ways to provide that functionality -- have a "Clone 
Window" command of some kind (although not with that name), allow the 
user to split a window into different panes that show different 
views...allowing that functionality by simply bringing up a new 
window with the same document even if it's already open is far, far 
more likely to be confusing than useful.

>  > [File access, open recent]
>  > "...recently opened documents .. available via a submenu".
>  >
>  > It is common practice to maintain a list of the last n open files in the
>  > File menu itself, where n is hardcoded or a user selectable value. Let's
>  > not discourage this practical feature in the HIG.
>
> I'm not discouraging it. I'm encouraging a better way of doing it. You
> can fit more items into a submenu.

Yes, although submenus are much more annoying/difficult to navigate 
than single menus.  Which is not to say that I disagree with you, but 
I don't think that "you can fit more items" is a sufficient reason to 
use a submenu in and of itself.

Adam
--