Usability problem of the day (duplicating in iPhoto)

In the courses I teach about human-computer interaction, I typically open each class with an example of a usability problem. I'm putting these online, in case others find them useful.

I'm a casual user of iPhoto. The application is up to version 9, and it's been around since 2002, so you'd expect it to be bulletproof with respect to usability. It's not quite that.

Suppose I'm using iPhoto to organize my collection of photos. Below is a picture I took one evening from the balcony of a restaurant in Raleigh. I decide to edit this photo but keep the original around, so I need to make a copy. I select the photo and find the command I want in the Photos menu: "Duplicate".

When I choose this command, however, nothing happens. At least as far as I can tell. That's odd. Maybe something happened behind the scenes... But Apple's Human Interface Guidelines tell us,

Provide direct, simple feedback that people can understand.

With no direct feedback, it's reasonable to assume that the command has had no effect. Is a non-functional command itself a problem? Apple tells us that it is:

[T]he current state of the command (dimmed or enabled) indicates whether that action is valid in the current context.

So what's going on? It seems the problem is that even though the photo is visible and selected, I'm not looking at it in quite the right way. Photos are stored in albums, and albums are organized in folders. I have to open the "Pretty pictures" folder in the sidebar and select the album containing the photo, "Raleigh pictures".

Now I choose "Duplicate" from the menu... And I've made a mistake. I've duplicated not the photo but the "Raleigh pictures" album.

iPhoto unselected my photo when I clicked on the "Pretty pictures" folder and then the "Raleigh pictures" album in the sidebar. This may be the simplest way for the application to behave, but it's not the most convenient in this situation. "Duplicate" does the same thing it always does: Duplicate whatever is selected. Still, this may not always be obvious to the user. I might have guessed that the different context would change the behavior of "Duplicate" because below it is another menu command with a changing name. It's "Remove from Album" when a photo is selected, "Delete Album" when an album is selected, and "Delete Folder" when a folder is selected. Should I have to look at other commands to infer what "Duplicate" will do? I'd rather not. I'd instead hope that iPhoto would follow another Apple guideline more consistently:

The name of the menu command clearly indicates what the action is...

Finally, though, I'm in the right context and can duplicate my photo.

I can use this example in class (it goes more quickly than you might expect) for a few different purposes.

The importance of finicky little details. Naming menu commands when designing an application seems like such an easy thing--you just say what it does. But assumptions and contextual dependencies are built into names, and these may not be obvious. (The opening scene in Kingsley Amis's novel Lucky Jim plays on just such a dependency for comic effect.) It's surprisingly hard work to figure out how users will interpret a design; the concepts of articulatory and semantic distance (Ed Hutchins, Jim Hollan, and Don Norman, in "Direct Manipulation Interfaces") give a useful way to think about it.

Subtleties in adapting a design to a new purpose. The hierarchy of folders-to-albums-to-photos is very similar to the organization of folders and files in the Macintosh Finder, the interface through which users manage the file system. But there are differences. You can't store photos directly in iPhoto folders, for example; if you try, the application will automatically create a new untitled album in the folder to hold the photos. You can also see all the photos in a given folder at once, no matter how deeply they may be nested within that folder's hierarchy of other folders and albums. The selection/deselection policy in iPhoto is the same in the Finder, but the presentation and visual cues are different. If I select a file deep in a hierarchy in the Finder, I see a thumbnail preview; if I then select one of the ancestor folders containing that file, the thumbnail goes away. In iPhoto, in a comparable sequence of actions, the photo remains visible, and the feedback for "You have now selected something else" is much weaker.

Using similar designs across different applications has a number benefits for users; consistency makes it easier to learn and use new applications. In Task-Centered User Interface Design, Clayton Lewis and John Rieman offer some memorable advice: Plagiarize. You should do it legally and honestly, of course, but also you also need do it carefully.

The difficulty of interaction design, even for experts. A lot of the examples I give in class are based on widely used systems developed by Apple, Microsoft, Amazon, Facebook, Google, and other big players in the software world. Some of the best people in the world work at these companies, and they still get things wrong.