Closeness of Actions and Objects in GUI Design (Jakob Nielsen’s Alertbox).
Closeness of Actions and Objects in GUI Design
Summary:
Users overlook features if the GUI elements — such as buttons and checkboxes — are too far away from the objects they act on.
One of the oldest principles of human-computer interaction is that things that are close together on the screen are seen as related. (Similarly, users view as related those things that are the same color or shape, that move or change together, or that reside within an enclosure, such as a box.)
I wrote about how to apply the closeness gestalt principle to GUI design in my 1993 book Usability Engineering, but it was well documented long before that.
Even though it’s an ancient insight and is covered in countless books and courses, we frequently see users overlook features because layouts violate the closeness rule. When buttons, drop-downs, checkboxes, or other actionable GUI elements are too far away from the objects they act on, people don’t see them. Often, users don’t realize what they’re missing and simply assume the features aren’t available.
In e-commerce studies, for example, users often overlook the availability of products in additional colors or sizes.
iTunes’ Violation of the Proximity Guideline
A striking example here comes from the screen in Apple’s iTunes software for upgrading iPhone applications to newer releases. Several months after getting an iPhone, I still thought users had to manually check each application icon one at a time.
This is how it looks:
At the top of the screen are a bunch of application icons. At the very bottom of the screen is a button labeled 1 Update Available. When clicked, this button updates whatever app needs the update, sidestepping the need for users to click each icon.
But, for several months, I didn’t notice this button because the action is simply too far removed from the objects it applies to.
Furthermore, the button lives in a separate colored stripe, so it appears to be outside the space that the icons inhabit, violating a key visual interface design principle.
(As an aside, why is the iTunes window so large in my screenshot, when it contains only a few icons? Because the same application manages both the phone’s apps and its music collection. When you work with several hundred sound tracks, you need a big space. It’s not always good to try to support highly distinct tasks within a single GUI.)
Close vs. Far Buttons
Interestingly, iTunes presents an example of correct button placement in another part of the same workflow:
In this screenshot, the Get Update button is right next to the icon it acts on. No risk of overlooking this feature. And no questions about what you can do. (Sadly, the dialog area’s Done button might as well be in Siberia. In fact, one problem is that this screen uses dialog areas for the role of dialog boxes in an interaction.)
That mainstream corporate websites make blatant usability mistakes is understandable because most members of their teams aren’t grounded in graduate degrees in human-computer interaction. (That’s why I have recently added foundational courses, such as The Human Mind, to my usability conference.) But how could Apple, of all companies, make such an elementary GUI design mistake? Apple has been pretty good at graphical user interfaces since it brought them to the mass market in 1984.
First, this is simply one more example proving that the big boys make mistakes and that you shouldn’t copy everything you see in best-selling software or popular websites. (This was brought home clearly in recent studies for our “Big and Famous Sites” seminar where apple.com was one of the sites we tested. But that’s a story for another day.)
Second, the usability problem might not have seemed so bad in Apple’s own testing:
If the tests used a smaller window, the button would have been closer to the icons and less likely to be overlooked by test users. (A smaller window might have resulted from using a normal-sized monitor or from testing the features in isolation so users wouldn’t be interacting with the large workspace needed to accommodate an entire music collection.)
If they tested a configuration with more app icons, the icons would have filled up the space and thus the button would have been closer to the last icon.
This case exemplifies the continued importance of an old and tried GUI guideline: insights that were discovered decades ago will still bite you if you forget them. The misplaced iTunes button also shows the importance of including a range of realistic configurations and sample data, both during user testing and in design reviews.