Re: Menu guidelines updated

[Reinout van Schouwen <reinout cs vu nl>]

Hello Colin and others,

On Tue, 31 Jul 2001, colin z robertson wrote:

> I've updated the menu guidelines, and, as usual, I'd like to hear
> people's opinions.

A short critique before I leave for vacation:

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

* [File Access, Open]

"standard file open dialog"

What is a standard file open dialog? That of GTK, or a (mini) Nautilus
view of the folder perhaps? The default file selector of GTK is terrible,
which is why the gtkfilesel project exists at sourceforge, but it's not
making any progress AFAICS. [yes if I could program in C..., but I can't
so I'm on the usability list]

"...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? I can think of
one situation that something special should be done: the user tries to
open a file that is already open *and changed*. In this case, opening the
file should give a warning like the one given at 'revert' and if the user
agrees, the file should be reverted to the state it had on disk.

"... blank untitled document ..." - I propose using a terminology like
'dirty' and 'non-dirty' (or 'clean').

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

[File access, Save]

The example you give about jpg compression level is badly chosen IMHO. I
believe the JPG compression level is not saved with the file itself, so
the most an app could do is default to the last-used value or an
application-default value.
If there are extra options to be set there should be an 'Advanced options'
button in the save dialog or an extra dialog after clicking Save that
takes care of this.

[Save as]
"new filename" -> "new file" sounds better?
"selected" -> there is nothing to select if it is a new filename, so this
could be changed to 'entered' or something like that.

[Close docname]

Perhaps we could say something about the effect of a situation where all
documents are closed on the status of menu items. Should they be greyed
out or not? More general guidelines on when to grey out items would be
welcome.

[Edit]

"The Edit menu... searching and replacing".

If you have many, many possible search/replace actions ( like jEdit, for
instance ) you may want to put those in their own separate menu instead of
cluttering the Edit menu with it.

"Replace dialog"

A replace dialog should not be something totally different than the Find
dialog. Perhaps they could be the same, but the 'replace' part of the
dialog could be disabled by default if you choose 'find' (but easy to
enable).

[Clipboard Access and Deletion, Paste]

I suggest adding 'or inserts at caret position'. I use 'caret' because
'cursor' is ambigious whether the mouse arrow or the text cursor is meant.

* Related to Menus are Toolbars, but perhaps those deserve their own
chapter in the HIG.

* Last but not least, popup / context menus are not mentioned at all in
this document, but I think that really belongs in there.

* Something I mentioned earlier: when to use cascading submenus and when
not to? I believe there's a lot of information available on this subject
aready.

Reactions are welcome but I'll probably answer them in ~ 2 weeks 8-)

best regards,

-- 

Reinout van Schouwen
e-mail    : reinout cs vu nl
voicemail : 084-8750706

"...PowerPoint is a tool to make uncreative people think they're
creative." -comment read on Slashdot