"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)
> > Change Preferences however should have an ellipsis because
> > the user cannot start changing the preferences. Only after he clicks
> > OK preferences will be changed.
> >...
>
> 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. That's why
there is an Apply button. Users are used to this. When a user edit a
document, it is not changed until the document is (auto-)saved. When a user
fills a form on the web, it has no effect until the form is submitted. ->
When a user changes the preferences, he expects he can fiddle around with
the widgets, without having an immediate effect on the program.
How many users would be confused when they edit the color of the desktop,
and the desktop color would not change. Not many. They know they'll have to
press Ok or Apply first.
Sjoerd Visscher
