The Faults of Flexibility

One of my favorite things about Mac OS X is how it molds to its users’ personalities. While it gives a default feel that is very user-friendly, it is possible to pare things down when you know what you’re doing and avoid the frustrations of the UI being “in the way”, taking up more screen real estate than is necessary for a given skill level. One instance of this flexibility comes in the ability to customize how applications display items in the toolbar – a UI convention present in nearly every OS X application in some form or another.

Default OS X Toolbar Style

This is the default toolbar style when you first open any OS X app. It includes both the icon and the title text for each tool or menu. This works very well for initial discoverability, as the purpose of many of the icons is not immediately apparent.

Text-only OS X Toolbar Style

This is the text-only toolbar style that one can choose to use from the “Customize Toolbar” dialog available in every application that uses a toolbar. This works well if you have difficulty recalling the purpose of icons and often know what function you are looking for but don’t think of the end result.

Icon-only OS X Toolbar Style

This is the icon-only toolbar style that can be chosen when you think more in terms of what end result you want rather than the name of the function that will take you there. This is my preferred style, particularly in document-based interfaces, but also in others after associating the icon titles with their icons.

Small Icon-only Toolbar Style

There is even the choice, as shown above, to display icons in a smaller size, and this can also be configured for use in conjunction with the text-display option.

Of course, this flexibility is slightly flawed. There is no central preference for the toolbar style one prefers, or even a way to set a default for newly-installed applications. This may be a conscious decision to ensure developers have text-based discoverability for their toolbar items, or a simplification of the system, but it would seem that this kind of user preference on something as vital to the application’s usefulness as the toolbar would be one worth documenting. It is worth noting that even though the title text for each icon is hidden in the Icon-only views, one can still find the action associated with the icon, phrased in terms of the question, “What can I do with this button?,” through mouse-over tooltips. This form of description is particularly relevant to users who associate results with an icon rather than associating the name of an action with an icon.

Additionally, one can never be too sure just where to find the “Customize Toolbar” menu item. In general, it is found in the View menu, but in other apps it can be found in the Window or Edit menu.

Clearly, I’m glad I have the choice to display the Toolbar in the way that makes the most sense to me, or even to not display the Toolbar at all. But these consistency issues, I think, keep this important UI element from achieving complete convenience.

blog reincarnation exists – again