The “Make Plain Text” command doesn’t take an ellipsis because TextEdit does not technically need more information from the user about the change before making the change. It just needs a confirmation that the user is sure that this is what needs to be done, because it cannot be undone. Again, this is arguably an exception to the rule in that normally commands without an ellipsis are immediately effective, but can be undone. (See my other comment above.) This particular one cannot be undone, hence the warning.

I don’t think selections with multiple tracks are really an issue. The user would have a choice between bringing up a separate window for each track (with content similar to the track information window for single tracks) or a single inspector window (with content similar to the track information window for multiple tracks) or even the third option available in the Finder (with command-control-I), i.e. a “Summary Info” window).

The only difference between the Finder and iTunes, I think, would be that the inspector or summary window should probably be the default and the individual windows the optional behaviour, because people often select very many tracks and opening a separate window for each and every track could have catastrophic consequences. On the other hand, the Finder itself already switches automatically to the summary information window when the number of selected files is above a certain limit (not sure what the limit is), so we could have the same behaviour here too.

But these are minor hurdles. I agree with Arden that it would be an interesting UI challenge, but certainly not one that’s beyond the capabilities of Apple’s UI experts.

I don’t remember any other situation where you get a modal dialogue. But that may be because Apple worked hard to get rid of modal dialogues.

I fully agree with your assessment that the modal info dialogue in iTunes is somewhat outdated. (On the other hand at least for the case of multiple selections I am not convinced it’d be too practical to turn in into a non-modal window because you’d have to handle the situations where someone selects some songs opens an info window, changes the data but doesn’t save it and then changes the selection. I imagine it’d be hard to come up with a UI that is non-modal yet lets you have a clear relationship between the info window and the songs it will affect.)

The problem is that the concept of “associated operation” does not really apply here, but that the action of selecting the command still requires additional input from the user to return to the previous state (i.e. to get out of the dialog that opens). My view is that commands that have an immediate effect without further intervention from the user and can only be reversed through an “undo” type of command are the ones that don’t take an ellipsis, and that on the other hand a command that brings up a modal dialog box always requires an ellipsis.

Is there another example of a menu command in Mac OS X that brings up a modal dialog box and does not take an ellipsis? There are commands without an ellipsis that bring up other windows, but these other windows are never modal.

Essentially it’s the fact that the dialog is modal that bothers me the most. The absence of the ellipsis is just a manifestation of that core issue.

The crucial words are at the beginning of the section that isn’t in your quote: “An ellipsis character (…) indicates to the user that additional information is required before the associated operation can be performed.”

In the case of the Get Info command the operation to be performed is opening a window. And that happens right away.

The ellipsis is not meant to say there will be a window opening. It is meant to indicate that some question will get in your way before the actual action is performed. If you’d be happy to adopt that point of view, I guess you will feel much more comfortable with the lack of ellipsis for the Get Info item – and even request such ellipses to be removed if you spot some.