Sjoerd Visscher wrote:
>
> "Matthew Thomas" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Sjoerd Visscher wrote:
> > >
> > > > Not at all. You don't Edit the Preferences simply by opening the
> > > > window. You have to manipulate the controls in the Preferences
> > > > dialog in order to change any of the preferences (and since the
> > > > window is modal, you need to click the `Ok' button too). More input
> > > > is required, therefore an ellipsis is necessary in the menu item.
> > >
> > > I don't agree. Each menuitem describes something a user would want to
> > > do. If the user can start doing that right away, you don't need an
> > > ellipsis. So Edit Preferences or View Preferences don't need an
> > > ellipsis because the user can start editing or viewing the preferences
> > > right away.
> > >...
> >
> > Sorry, but the UI guidelines of Apple and Microsoft both disagree with
> > you. They both talk about carrying out a command, not `starting' to
> > carry out a command.
> >
> > By your logic, the `Print' command in the `File' menu would not have an
> > ellipsis (because it doesn't start the printing, it just brings up a
> > dialog), but the `Print' button in the print dialog itself *would* have
> > an ellipsis (because it does start the printing). Obviously, neither of
> > these are the case.
>
> No. Why do you think I mean that?
>
> Once again:
> - User can start doing what the command-item describes right away: no
> ellipsis
> (edit preferences)
> - User cannot start doing what the command-item describes right away:
> ellipsis
> (open,save,print)
This semantic swordplay is all irrelevant. I select the menuitem, it
gives me a dialog to be manipulated before I can return to what I was
doing, therefore the menuitem must have an ellipsis.
Or, to put it another way, the negative-space argument: since selecting
the menuitem does NOT have an immediate effect on the application,
requiring no further interaction, it CANNOT appear without an ellipsis.
That's all there is to it, people. You're not "changing" or "editing" or
"starting to edit" something, you're breaking the workflow to require
user interaction, and that means you put an ellipsis. End of story.
> > If you ask users what they're doing when they're manipulating the
> > controls in the Preferences dialog, they'll tell you that they're
> > changing the preferences. If you try to tell them that they're not,
> > they'll think you've gone bananas.
> >
> > The mechanics of changes to the preferences file being committed when
> > the user clicks `Ok' are of no interest to the user -- as far as se is
> > concerned, we might just as well be making constant changes to the file
> > as the user manipulates the controls in the Preferences dialog, and
> > rolling back these changes if the user clicks `Cancel' (rather than just
> > storing changes to the preferences file, to be committed if the user
> > clicks `Ok' and later quits Mozilla without crashing).
>
> I don't agree. The user should know that, and most do I think.
I'm not the average user, but I think it's fair to say that the average
user would understand that the changes they make to a prefs dialog are
*intended* changes, to be implemented when the dialog is closed by
pressing something like an "Ok" button.
Not that this has anything to do with the central issue, which I believe
I resolved above.
-Xplo
