http://developer.gnome.org/projects/gup/hig/2.0/controls-buttons.html states
"Do not add an ellipsis to commands like Properties, Preferences, or Settings,
as these open windows that do not /require/ further input." 

Do you disagree?

Yes.
<http://developer.gnome.org/projects/gup/hig/draft_hig_new/menus-design.html#menu-item-types>
says "Label the menu item with a trailing ellipsis ("...") only if the command
requires further input from the user before it can be performed. Do not add an
ellipsis to items that only present a confirmation dialog (such as Delete), or
that do not require further input (such as Properties, Preferences or About)."
But that is an error. Editing your Preferences *does* require further input,
otherwise you're not editing them.

It is not a requirement in the sense that it is not an obligatory requirement to proceed. You may simply press "Close" in that window without changing anything.

You might just as well say that "Print..." shouldn't have an ellipsis because further input is not required, since you can click Cancel. Cancelling is not the primary goal of the command; printing is. Similarly with Preferences, looking at your preferences is not the primary goal of the command; changing your preferences is.

Windows and Mac OS X both get this right, even though their respective items aren't in the "Edit" menu; "Options..." and "Preferences..." respectively have ellipses because the primary goal when choosing the command is to change your preferences.

I think that's not a very good analogy, because every irreversible action should be given an option to cancel somewhere. Besides, Preferences don't have Cancel buttons since they are not even actions per se.

Changing preferences is not the primary goal. The primary goal is "get me my preferences." On the other hand, selecting Print without the "need further information" idea (depending on the application) could make it terribly broken.

Huh? What does "get me my preferences" mean?

Sorry. I meant "give me my preferences".

I don't understand that either. Preferences are something you have. You can never be given them.

Ok, it is more like "show me my preferences".

Again, that's not the primary goal. Changing the preferences is. If "show me my preferences" was the primary goal, the item should be in the "View" menu.

Well, this is only my interpretation of the HIG about it explicitly saying that Preferences don't have ellipsis. I think that Preferences is not really an action and that is the reason why gnome-terminal changed "Current Profile..." (wrong according to the HIG) to "Edit Current Profile..." (right).

As a matter of interest, which Windows apps use "Preferences..." btw?  We actually copied our ellipsis guidelines directly from the Windows guidelines, which specifically cite Preferences as a menu item that shouldn't have an ellipsis:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch14a.asp

Cool, that makes it a much easier decision to change.

First, Microsoft don't follow that guideline in their own software, including Windows itself. The standard menu item for configuring a program's behavior in Windows is "Tools" > "X Options...", with an ellipsis. Examples:
*   Windows Explorer
    <http://rucus.ru.ac.za/help/notes/samba/windows_explorer.png>
*   Internet Explorer
    <http://www.library.unr.edu/authenticate/images/ieproxy1.gif>
*   Windows Media Player
    <http://sidelinesports.com/support/forum_pics/wm_player.gif>
*   Word <http://academics.georgiasouthern.edu/etd/images/word_tools.gif>
*   Excel <http://www.uwo.ca/its/doc/hdi/email/images-password/ex-tools.jpg>

Second, while Microsoft aren't following the guideline to the letter, they're following it in spirit. The guideline uses "intended primary action" language similar to my "primary goal" language above, and its claim that "Even though the user can use this command to change options, the command's intended primary action is to display those options" is obvious nonsense. Occasions when Options windows are used to change options would outnumber occasions when they're used to display options by several hundred percent.

And third, to answer your question about which Windows apps have a "Preferences" item, with or without an ellipsis: By far the most popular would be iTunes, which has "Preferences..." with an ellipsis.
<http://www.ebayjournal.com/images/itunes/Prefs1.jpg>
And the QuickTime Player, also with an ellipsis.
<http://tones.wolfram.com/tsfaqs/windows/images/QuickTimePrefs.jpg>
Naturally the Apple software is biased towards Mac style, but remember that the standard Windows wording, "Options...", also has an ellipsis. But the (probably) next most common example doesn't come from Apple: RealOne Player, also with ellipsis. <http://wwwnew.towson.edu/videos/images/RealOnePref.gif>
I don't remember *any* Windows apps using "Preferences" without ellipsis.

The Print analogy isn't good for two reasons: 1. It would make no sense to Print and then Cancel. It makes sense with Preferences since you might just want to view your preferences 2. Removing the ellipsis from Print would be wrong since that would imply that the print would be immediate. 

That Preferences appears on the Edit menu is of historical origin (per the HIG) and is perhaps unfortunate. I have often found that it would make more sense to put Preferences in the File menu.

And again, it's not about whether it makes sense to do nothing in the dialog, it's about what is the primary goal. That goal is changing the preferences, which is why Windows and OS X both use ellipsis, even though neither of them put the item in the Edit menu.

I think you put too much importance on primary goal, something that HIG itself does not in this case. And I think primary goal doesn't count, because:

* "Preferences" is the name of a window (or a resource) and not an action per se, so it doesn't get a "primary goal", the menu item is just calling this resource;

* As stated in the HIG, invoking the Preferences window doesn't require further input (further input to call a Preferences Window?), and since you already know you are getting a window when you select the "Preferences" menu item, it is redundant to use ellipsis, if not misleading.

* And ellipsis would add unnecessary noise to screen readers, but give back no useful information at all (and since programs may have more than one kind of "settings" window, you could potentially have a majority of menu items with ellipsis in a menu -- including the menu items that originally had ellipsis. Then the screen reader's speech becomes cluttered with pontuation marks).

If Preferences really "doesn't get a primary goal", it shouldn't exist at all. And if ellipses really "add unnecessary noise to screen readers", either we shouldn't use them anywhere, or the screenreaders should be fixed.

You are taking it too literally, A preferences window has a purpose, it just doesn't have the same semantics that an action (verb) in a menu item, it is just a name for a group of settings.

And I think that ellipsis is useful, just not in this case, as it increases the number of options with ellipsis and add no useful information in this specific case, because it is redundant. The user knows that a preferences menu item gives him a new window.

Use the word "purpose" instead of "goal" if you like, the error is the same. The primary purpose is not to display the preferences, but to let them be changed. Consistency in style is more important than staying within some quota for "the number of options with ellipsis". And that any "item gives him a new window" is irrelevant to whether it has an ellipsis.

On the contrary, a menu item with an action (verb) conveys the user into a single and well defined goal -- a "primary goal", as you said it yourself.

A preferences window doesn't have that same meaning or logic, it is just the name for a bunch of options logically grouped. That doesn't mean it has no purpose, it just doesn't have this well defined goal (that "primary goal" that you said before).

Do you see the difference between "primary goal" and "purpose" in this case?

Well, I find it consistent the way it is. :)

The argument of the "number of options with ellipsis" is not because I think it should stay within some quota, but it is because -- considering I think it is already consistent -- we don't need to add ellipsis for a menu item that has nothing to gain from them (it is not an action and it is not irreversible and it doesn't require further input before showing the preferences window, and because of those it doesn't follow the HIG).

(In reply to comment #2)
> Editing your Preferences *does* require further input,
> otherwise you're not editing them.

I don't really have a strong opinion here, but it seems to me that the Preferences is one of those awkward dialogs that can have a purpose like editing or can just be viewed.  While just being viewed isn't much of a purpose itself, the dialog action buttons probably speak to what's going on more.  

Printing, bookmarking, and find / replace all require further input to complete and use cancel buttons to describe not completing the action.  Esentially the "..." indicates that a dialog will open which you cancel and nothing will happen (alternatively you could continue and something happens).  While the preferences window uses just a close button because you can't actually cancel the action. I don't think we want to add a cancel button to preference dialogs such that you could feel like it's possible to cancel the action since this isn't how our preference interactions are designed.  So I'm wondering if you are looking to also change the preferences dialog from a close button to use action style buttons?  To me the argument necessitates this continuation of the thought process.

That's an interesting argument, and undoing/redoing changes in instant-apply windows generally is an unsolved problem. But an ellipsis is not dependent on the existence of a Cancel button. Nautilus's "Rename..." and Firefox's "Open Location..." are correct examples where no dialog is involved at all. And in Mac OS, "Preferences..." has an ellipsis, despite the window usually being instant-apply and therefore not having *any* buttons along its bottom.

Pedro, the brevity of menu items often requires the verb to be implied. See for example "Page Setup..." in many apps ("set up" would be a verb, but "setup" is a noun), "Permissions..." in Evolution, "Canvas Size..." and "Print Size..." in Gimp, etc. Each of those is "a bunch of options", with no explicit verb, but they all have ellipsis: "Preferences" is the odd one out.

(Actually Evolution's "Edit" menu is a bit of a mess, perhaps *because* of this bug. It starts off right with "Synchronization Options...", but other items that should have ellipsis don't, apparently because they're following the mistaken example of "Preferences".)

(In reply to comment #23)
> That's an interesting argument, and undoing/redoing changes in instant-apply
> windows generally is an unsolved problem. But an ellipsis is not dependent on
> the existence of a Cancel button. Nautilus's "Rename..." and Firefox's "Open
> Location..." are correct examples where no dialog is involved at all. And in
> Mac OS, "Preferences..." has an ellipsis, despite the window usually being
> instant-apply and therefore not having *any* buttons along its bottom.

They don't need a Cancel button, but they are surely reversible (press escape while renaming or change focus in the location bar).

And the Mac OS example is beside the point. We don't know if it follows the same interface guidelines windows use.

> Pedro, the brevity of menu items often requires the verb to be implied. See for
> example "Page Setup..." in many apps ("set up" would be a verb, but "setup" is
> a noun), "Permissions..." in Evolution, "Canvas Size..." and "Print Size..." in
> Gimp, etc. Each of those is "a bunch of options", with no explicit verb, but
> they all have ellipsis: "Preferences" is the odd one out.

"Page Setup..." has options concerning page configuration only, it's not just a bunch of unrelated options, like "Preferences". This also applies to Canvas size and Print size.

Besides, all of these dialogs have Cancel and Apply buttons and the action finishes only after you press one of them. Preferences windows are different: you change their options directly and behaviour changes as soon as you mark a check box or select an option.

> (Actually Evolution's "Edit" menu is a bit of a mess, perhaps *because* of this
> bug. It starts off right with "Synchronization Options...", but other items
> that should have ellipsis don't, apparently because they're following the
> mistaken example of "Preferences".)

Yes, they probably are. But they are still different from "Preferences".

Whether something is reversible isn't relevant (otherwise implementing Undo would suddenly cause lots of ellipses to appear, and it doesn't). That Preferences contain "a bunch of unrelated options" isn't relevant (otherwise the guideline should vary depending on whether all the preferences are related, which would be silly). And whether the window is instant-apply isn't relevant (which I demonstrated with the Mac OS example, and yes we do know exactly where their guidelines agree and differ with those of Windows and Gnome, because they're all on the Web).

I think the cause of the disagreement here is that software developers are *vastly* overestimating how often people go into Preferences just to look at them. That may be common behavior for developers (I know I do it, after installing a new program!), but not for most people, for whom a Preferences window exists primarily for fixing undesirable behavior. So developers think that merely viewing preferences is a primary goal, when it really isn't.

(In reply to comment #25)
> Whether something is reversible isn't relevant (otherwise implementing Undo
> would suddenly cause lots of ellipses to appear, and it doesn't).

Only if, on top of that, the commands require user input (as stated in the definition) and if the command describes a complete, and only one, use case.

> That
> Preferences contain "a bunch of unrelated options" isn't relevant (otherwise
> the guideline should vary depending on whether all the preferences are related,
> which would be silly).

But that is exactly what the HIG does when it tells the programmer the difference between a "preferences window" and a "utility window" ("preferences window" ends up grouping everything else that the programmer didn't bother to create a command to describe a complete use case).

> And whether the window is instant-apply isn't relevant
> (which I demonstrated with the Mac OS example, and yes we do know exactly where
> their guidelines agree and differ with those of Windows and Gnome, because
> they're all on the Web).

But then there's nothing else to say if Microsoft guidelines explicitly state that "preferences" should not have ellipsis since GNOME follows that. Apple and Microsoft guidelines are just different.

I'm sorry, I have no idea what you're trying to say. The HIG currently says nothing about ellipsis with relation to Undo, and it says nothing about "commands to describe a complete use case". Apparently you think it should. What specific wording do you propose?

(In reply to comment #27)
> I'm sorry, I have no idea what you're trying to say. The HIG currently says
> nothing about ellipsis with relation to Undo,

It kind of does, indirectly. See below.

> and it says nothing about
> "commands to describe a complete use case". Apparently you think it should.
> What specific wording do you propose?

Again, it kind of does. Look at this explanation about dialogs in the HIG:

"A dialog provides an exchange of information, or dialog, between the user and the application. Use a dialog to obtain additional information from the user that is needed to carry out a particular command or task."

A dialog is by far the most common method of asking for information from the user, specially if you need to carry "a particular command or task." And "a particular command or task" is exactly what a use case describes.

Now look at this:

"Label the menu item with a trailing ellipsis ("...") only if the command requires further input from the user before it can be performed. Do not add an ellipsis to items that only present a confirmation dialog (such as Delete), or that do not require further input (such as Properties, Preferences or About)."

So a "menu item with a trailing ellipsis" is used to request "further input from the user before it can be performed". Doesn't it match exactly with the assertion above "use a dialog to obtain additional information from the user"?

So, a "particular command or task" (a use case) "with trailing ellipsis" will most likely open a dialog. A dialog can, by definition, be canceled, so it is not an instant-apply window.

But, a preferences window *is* an instant-apply window, it doesn't describe a single and complete use case ("a particular command or task") and it does not behave like a dialog.

I think it's pretty clear.

Pedro, why are you still talking about instant-apply windows? Calum already pointed out that the Gnome "Preferences" guideline is copied from Windows. And in Windows, Options dialogs are not instant-apply. Therefore, again, the Gnome guideline has nothing to do with Preferences being instant-apply.

Meanwhile, since I wrote comment 13, Microsoft have changed "Internet Options..." to "Internet Options" in IE7 to bring it in line with their guidelines. But they've retained "Folder Options..." in Windows Vista Explorer, and have items like "Field settings..." and "More options..." in Office 12. So the contradiction in their guidelines has led to inconsistency throughout Microsoft software, just as the contradiction in the HIG has led to inconsistency in Evolution and other Gnome software.

We don't recommend that the Edit menu includes "Preferences" any more - it should go in the application menu. Doesn't seem like this bug is relevant any more.