March 21st, 2007 • 6:13 pm
This is something that has been bothering me for a long time. (I am weird like that.) In iTunes, the menu command that brings up the track information dialog is called “…” character):” and, in the menus in which it appears (the “ ” menu in the menu bar and the contextual menu when you right-click on an track), it appears without an ellipsis (the “
Now, I am fully aware that the “” command in Mac OS X’s Finder does not have an ellipsis either.
And I am also fully aware that Apple’s own guidelines on using the ellipsis character say this:
Don’t use an ellipsis in the name of a button or menu item when the associated action:
- is completed by the opening of a utility window.
A user opens a utility window to view information about an item or to keep essential, task-oriented controls available at all times (for more information about utility windows, see “Utility Windows”). A command to open a utility window, therefore, is completed by the display of the window and should not have an ellipsis in its name. Examples of such commands are Get Info, About This Application, and Show Inspector.
The problem, however, is that Apple’s own definition of “utility windows” is as follows:
Utility windows are either application-specific or systemwide. Application-specific utility windows disappear when the application is deactivated.
Systemwide utility windows, such as the Colors window and the Fonts window, float on top of all open windows.
You can create a modeless utility window, such as a tools palette, to present controls or settings that affect the active document window. Utility windows are useful for keeping extremely important controls or information accessible at all times in the context of a user task. Because utility windows take up screen space, however, don’t use them when you can meet the need by using a modeless dialog (the user changes settings and then closes the dialog) or by adding a few appropriate controls to a window frame.
A user can open several utility windows at a time; they float on top of document windows. When a user makes a document active, all of the application’s utility windows should be brought to the front, regardless of which document was active when the user opened the utility window. When your application is inactive, its utility windows should be hidden. Utility windows should not be listed in the Window menu as documents, but you may put commands to show or hide all utility windows in the Window menu.
Let’s review the track information in iTunes and compare it to this definition of a “utility window”:
iTunes’ track information window is application-specific, but does not disappear when the application is deactivated. If it’s visible when you switch from iTunes to another application, it stays visible, in the background.
iTunes’s track information window is definitely not “modeless.” It’s a modal dialog box. It’s not an “inspector window,” but it’s not an “info window” either. (The Finder offers both. command-I shows an info window for the current selection, while command-option-I shows an inspector window that changes depending on what is selected.)
The only non-modal aspect of the track information is the ability to go from track to track through the “Previous” and “Next” buttons, which saves you the trouble of having to (1) close the track information window, (2) select the next/previous track, and (3) open the track information window again.
But the usefulness of these two buttons is limited. If the tracks you want to edit are not right next to each other, using the “Next” and “Previous” buttons repeatedly can be tedious and error-prone too. In addition, editing the tags of a track can cause it to change its own position in the track list. And the fact that iTunes fails to change the highlighting in the track list to show you which track you are selecting by using the “Next” and “Previous” buttons makes the feature rather confusing when this happens. (The original track stays highlighted in the track list in the background, even though you have now switched to another track, so you have effectively no idea where you are in the list now.)
And finally, you definitely cannot have more than one track information window open at the same time in iTunes.
All this means that, unlike the File Info and Inspector windows in the Finder, the track information window in iTunes fails to qualify as a “utility window” from a UI point of view. From a UI point of view, it is actually a dialog box, and a (mostly) modal one at that.
And because of this, I cannot help but feel that the “” command that brings up that modal dialog box should have an ellipsis, thus warning the user that he’s going to be required to provide additional input. At the very least he’ll have to close the window in order to be able to continue using iTunes.
Of course, I realize that it’s a bit of a difficult situation. After all, conceptually at least, the track information window in iTunes is a sort of “utility window,” in that it shows the “attributes” of the selected item (the selected track). And the command to bring it up is called “.”
But ultimately, this difficult situation is the consequence of Apple’s own choices. They are the one who decided to made the track information window a modal dialog box. They didn’t have to. Or they could change that, and make iTunes behave like the Finder and support multiple individual track information windows or a track information inspector window (or window drawer, as in iCal).
This is something that I have been hoping for for a long time. I am constantly frustrated by the fact that iTunes’ track information window is a modal dialog. I’d like to have the flexibility of accessing track information through other, non-modal approaches.
I do realize that it would be a challenge, due to the sheer amount of information that is included in that track information window. But the file information windows in the Finder also contain a pretty large amount of information, with collapsible sections making it more manageable. Apple could use a similar approach (or panes) for the various sections of the track information window.
They could keep the current dialog box for those who are attached to it, and use another command to invoke it, such as “Edit Tags…,” with an ellipsis clearly indicating the modal nature of the command.
And then they could use “Get Info” and “Show Inspector” (without the ellipsis!) for commands to bring up more Finder-like track information windows in iTunes. It would be up to the user to decide whether he prefers the modal approach or more visual clutter but more flexibility with various information windows or an inspector/drawer.
Give the user some choice, I say. And make iTunes more consistent with your own guidelines!