In this article, I’ll redefine response compatibility and explain how it contributes to the central goal of an intuitive interface, don’t make users think!
Response compatibility defined[pullquote_right]”The major requirement of response compatibility is that the spatial relationship between the positioning of the controls and the system or objects upon which they operate should be as direct as possible, with the controls either on the objects themselves or arranged to have an analogical relationships to them.”—Donald Norman, The Design of Everyday Things, p. 199] [/pullquote_right]A textbook definition of response compatibility (right) gets us rolling, but doesn’t paint the whole picture. After all, user experience occurs not only in space, but in time. Furthermore, experiences have a general meaning, or gist. An interface with strong response compatibility therefore supports at least three dimensions of the user’s attention: space, time, and meaning. So here’s our improved definition of response compatibility:
Response compatibility is the degree to which a control communicates its function in space, time, and meaning
This leads to 3 design principles for intuitive interfaces[note_box] [arrow_list]
- Place controls in close proximity to their effects
- Support the temporal sequence of the user’s cognitive thread. This has two implications: the system should be responsive, causes and effects should obey visual flow. A system is considered responsive if it responds in 200 ms or less [Ware]. Visual flow is the order in which the eyes encounter parts of the interface. Generally, visual flow follows reading order. The implication, at least for left-to-right cultures, is that controls should appear above or to the left of the items that they affect.
- Support semantic coherence between a control and its effects. This includes grouping similar controls and using visual design to suggest function (e.g. a Save button with a disk icon on it). Search this thesis paper for more under “data relation” and “natural mapping”.
This is a bit abstract, I realize. Let’s illustrate these principles with a popular product, iPod+iTunes.
What sucks about the iPod click-wheel—and why the Zune pad is better (gasp)
Have you ever struggled to scroll down by just one item on an iPod? Ever been confused as to whether you needed to move your thumb clockwise or counter-clockwise to scroll down? Enter response compatibility. A control which produces a vertical response should itself be vertical. The Zune control succeeds in this regard. Move your finger up, the list scrolls up. Move your finger down, the list scrolls down. iPod users are faced with a more complex mapping: move your finger clockwise, the list scrolls down, move your finger counter-clockwise, the list scrolls up. Another strength of the Zune pad is per-item scrolling. Click the pad down once, and you scroll down by one item. It’s not nearly as easy to scroll by exactly one item with an Apple click-wheel.
To Apple’s credit, the hands-on scrolling of the iPhone and iPod touch are even more response compatible than the Zune’s scroll pad.
iTunes, meet response compatiblity
In this section we’ll apply our design principles to iTunes. For very little effort, we’ll find improved usability.
Global versus local scope
The iTunes controls are located along the top and bottom of the iTunes application window, as shown above. Some of these controls affect the entire application, irrespective of the active page in the blue panel at the left. We’ll call these controls “global.” Other controls are specific to the active page or playlist. We’ll call these “local” controls. In the diagram below, A (play, volume), F (status), C (search), D1 (add playlist), D4 (picture preview), E1 (burn CD), and E3 (eject) are all global controls. Everything else is local.
The first thing to notice is that global and local controls are interspersed without rhyme or reason. As a result, iTunes taxes the user to determine whether or not a given control affects his entire iTunes experience, or just the page she’s looking at.
To see how confusing this can be, go to a playlist, we’ll call it “Play1.” Type something in the search box, and turn shuffle on (lower left). Now switch to another playlist. Notice how your search text disappeared and how the shuffle control turned off*? That’s because the search and shuffle controls are local. Now go back to Play1. Wham—the search text and shuffle button return to the states you left them in for Play1.
The fact that the search and shuffle controls change according to the active page is not the crux of the problem. The real problem is that the placement and layering of the search and shuffle controls do not suggest that these controls are local, and only affect the active page. In other words, the search and shuffle controls have weak response compatibility. We’ll solve this response compatibility problem, and a few others, in the next section.
Before we get there, there’s one more wrinkle to iron: iTunes scatters functionally related controls across the interface. For example, the main play controls are at the upper left of the interface, yet the related shuffle and loop controls are many pixels away, in the bottom left corner. Similarly, three of the view controls are side-by-side in group B, but the “eye” button, for three-column browsing, is tucked away in the lower-right corner of the window.
Messy, isn’t it?
Response compatibility to the rescue
The first step to cleaning up the iTunes interface is to segregate global and local controls. They belong in distinct layers that convey their respective effects. The second step is to place all functionally-related controls in the same layer. (For explanations and illustrations of visual layering, see Envisioning Information.)
Since global controls elicit global responses, they should live in a layer above the active page. The gray bars along the top and bottom of the window, visually distinct from the central content area, are an ideal layer for global controls–and only global controls.
So, after cleaning up the iTunes titlebar, we get the following.
The header is now exclusively devoted to global controls. All of the play controls are in the same place. You may have noticed that two formerly local controls, shuffle and repeat, are now in global header layer. I argue that shuffle and repeat should be global. Do users really want to set shuffle and repeat on a per-playlist basis? To be fair, it would require a field study to answer this question. In the absence of any data, I contend that global shuffle and repeat are easier to understand than local, page-specific shuffle and repeat, which can bounce around as users navigate across playlists.
Applying the same principles to the lower left footer, we get the following layout.
The “Add Playlist” button is now where it belongs, in the playlist layer, where its response occurs. The global “Show Album Art” button continues to live in the footer, just beneath the response it produces. In the lower right (not shown), we remove the browser control (the eye), leaving the two global CD controls, burn and eject, side-by-side in the lower right corner.
All that remains is to find a home for the search and view controls. These are local, page-specific controls. They belong in the same visual layer as the page that they affect.
That’s iTunes, reloaded for response compatibility.
iPod+iTunes+ResponseCompatibility = more intuitive. It was simple all along ;)