Thursday, November 18, 2010

What's Wrong With Disclosure Triangles?

iTunes 10 changed the way users were presented with a way to hide or show categories in the iTunes sidebar. Instead of using a standard Macintosh disclosure triangle—a user interface control that can be used to hide or reveal content in a document window—to hide and show your list of devices, playlists and so forth, Apple thought that a normally hidden, mouse-over-sensitive word be used instead to act as a replacement for the disclosure triangle. This control is presented as the word "Hide" or "Show" to the right of a category title, and you'll only see it if your mouse makes its way to a particular region that approximates the location of the category title—moving the mouse away hides the control again.

I see many things wrong with this new control, but the main ones are:

  • the control is always hidden by default. You wouldn't know the control even exists unless your mouse accidentally roamed around a particular area on your display and the control shows itself... or, you have been told of its existence beforehand, and
  • the control requires users to search for it with the mouse before it can be used. Because the control is hidden, the user has to do one extra thing before the control is used—make an effort to expose the control for use first. This makes using the control more cumbersome than it needs to be.
  • the control needs to be localised. The words "Hide" and "Show" are not applicable to all human languages where the control may appear in a user interface. To fix this, more resources (code and memory space) need to be thrown into the problem of adapting the control for use in languages other than English.

Disclosure triangles don't have any of these problems—they are always visible, and they are always usable with only one cognitive step instead of two.

When is Apple ever going to stop ignoring the work that they spend eons of time improving? Designing reliable, sensible human interfaces for people is a painstaking task to get right, and to just have some unforgiving application designers break the Guidelines time and time again makes mockery of the whole design effort. iTunes 10 now has controls that only English-speaking people can understand at first glance, and even then as people become familiar with the controls, the unavoidable two-step find-then-use process that the new controls introduce has just made the application require that much more effort to use with any degree of certainty.

That's another step backwards in my books.

iTunes 10 actually does use disclosure triangles, for playlist groups and for devices in the Devices list, in the sidebar. However, they are not used for category titles.


Labels: ,

Thursday, November 11, 2010

They're Called "Folders".

iOS 4 introduced a concept whereby, on the Home screen (called SpringBoard), you can group icons together and give the collection of icons a name, thereby saving valuable real estate on the iPhone or iPod touch display. This feature on iOS 4 is called "folders".

But shortly after Apple introduced Mac OS X 10.7 Lion as a sneak preview, I wondered about the usual attention to detail that they give their work, because I get the feeling that the folks at Apple may have missed it somewhere. The new feature on Mac OS X 10.7, called LaunchPad, is synonymous with SpringBoard on iOS, where applications can have their icons shown in an uncluttered, full-screen view as an overlaying desktop space. However, LaunchPad, too, has the ability to group icons together as a collection, and this feature is also called "folders".

Problem is, there already exists a feature called "folders" in the Macintosh Finder, ever since the original Macintosh System Software! I dare say all Mac users already know what a folder is—folders of various names are already made visible within a user's account the first time they log in!

So, why do we have two visually and functionally different concepts both being called the same thing?! The Finder allows users to create folders, which represent directories that can contain other files and folders on a filesystem. And these folders, particularly the Applications folder on the startup volume or a user account's Home folder, can also contain the applications themselves, since they're where the Macintosh conventionally keeps user-launchable goodies.

So now there are going to be three places where you can see both folders and applications on the Mac: in the Finder, in the Dock, and now in LaunchPad. Isn't this going to become a bit too confusing?!

Hopefully not, but I think Apple is relying on context to separate all three subtleties. In the Finder:

  • folders have a one-to-one correlation to directories on a mounted filesystem, and
  • applications are a one-to-one correlation to a hierarchy of directories and files in what's called a "bundle" on the filesystem, so that the Mac shows only one icon for every bundle (while hiding the contents of a bundle from view—unless the Show Package Contents command is applied to a bundle).

In the Dock, the rules are a little different:

  • folder icons are aliases to folder icons in the Finder, whereby the Dock makes special arrangements to also show the contents of such folders at the user's request,
  • other icons are aliases to either application or document icons in the Finder, which are opened when activated. One special icon in the Dock is the Trash, which opens in a Finder window and has special properties of its own while not being related to any one filesystem object.

Note that the Dock operates exclusively on aliases—every icon except for the Trash is an alias, and dragging a Finder icon to the Dock makes an alias in the Dock without changing how the icon appears or what the icon represents.

But for LaunchPad, the user interface conventions are going to change yet again! Here's my guess as to how LaunchPad will behave on the Mac:

  • only application icons that appear in the Applications folder of the startup volume or a user's account will appear in LaunchBar, and
  • LaunchBar will have to keep its own internal database of how a user has arranged the application icons, including these iOS-like notion of folders... much like how the Dock keeps its own internal representation of the arrangement of icons as a set of user preferences.

While the relationship between LaunchPad icons and application icons in a Macintosh environment does make sense, LaunchPad's presentation of folders does not; for the first time on a Mac, folders are going to look and behave differently between LaunchPad and the rest of the system:

  • assuming LaunchPad follows the same design traits as iOS's SpringBoard, folders cannot be nested (that is, folders cannot contain folders),
  • folders in LaunchPad appear and behave differently, and do not represent anything relating to directories on a Mac filesystem, or folders in the Finder, and not even as aliases.

Those last two points ought to be enough to say, "Hey, maybe we shouldn't be calling them folders! They're too different! Perhaps they should be called containers instead!"

Should we care enough to use the phrase "container" in place of "folder", where containers are unrelated to the concept of Finder folders in the Apple User Interface Guidelines?! It'll help make the two separate concepts of "arbitrary container" and "filesystem object" distinct until such time if ever the Finder, and the rest of Macintosh, does away with the latter definition entirely from the user interface, as the new inventions of iOS carry Macintosh forth into a new world of auto-managed storage.

I for one am really tempted to simply call those iOS folders "icontainers" instead.


Labels: , , , , ,