flow|state

Your most recent feature probably should NOT be the most prominent element of your UI

A colleague once showed me the main toolbar for an app they worked on, and offered an archeological exposition of when and why each button had been added. The first three buttons represented the app’s core functionality, and had been on the toolbar since the app’s first release. All the other toolbar buttons had been added in successive releases. Each time one of those features were added, it had been deemed vitally important to give the feature prominent placement on the toolbar. There those buttons had remained to the present day. But when the team monitored click-through across all toolbar buttons, the first three buttons accounted for nearly all user clicks. Those other buttons were permanent meaningless clutter, doomed to forever confuse and distract users from the first three, meaningful buttons.

When adding a new feature to an app, there’s an almost irresistible tendency to put that new feature front and center in the UI. After all:

• Your customers may have been begging for it for months, or years.
• You and the entire product team have been actively thinking about, and working on, that big new feature non-stop for many months.
• You are all proud of the new feature.
• Your team may be convinced this feature represents the difference between business success and failure.
• You don’t want existing users to overlook this much-requested feature when it’s finally available.

But, wait—is this new feature really so important that it should now be the dominant element in your UI?

• It’s unlikely that in the user’s mind your new feature is more important than the app’s core function. You most likely established that core function of your app very early on, probably in the very first release. It’s unlikely that you want to decrease the chance that users successfully find and use that function.
• Once users learn how to find your new feature now, they’ll still expect to be able to find it that way a year from now—when you’re trying to release the next new big feature. What are the odds that, at that time, the feature that’s new today will still be so vitally important?
• It’s incredibly hard to muster the will to strip out a UI element.

It’s appropriate to make a new feature visible; just make sure that, from a user perspective, the prominence of the entry point for the feature corresponds to its priority in the updated app’s overall functionality.

Negative space in a user interface is priceless — so it inevitably gets filled up

A lot of my time as a design executive is spent defending the value of the unquantifiable. Business pressures argue for design compromises with some quantifiable and significant ROI (Return on Investment). But as Adaptive Path put it in their report on Leveraging Business Value: How ROI Changes User Experience, “It’s impossible to measure ROI for user experience with a simple equation that can be applied across a wide swath of companies and projects.” And, in my experience, perhaps the hardest thing to quantify is the value of negative space: the space between your user interface elements.

Typically brand new apps have lots of space, because UI elements represent features, which require code, which requires time and money. With time and money, however, the app evolves, and the empty space is quickly filled in with new features. The availability of room, in fact, can contribute greatly to the decision to place a button in what was previously empty space. “Users are asking for this feature, and it looks like there’s room for us to squeeze in another button on the toolbar, so let’s do the feature and make it a toolbar button.”

I rarely hear discussion about setting aside room in a user interface for the absence of user interface elements. Speaking both aesthetically and from a usability perspective, negative space can be highly valuable in an interface. Used effectively, it can create a sense of calm, balance, manageability, and competence. It can help guide the user’s eyes across the page towards what’s important. The presence of space can separate things that are different; the absence of space can join things that are similar.

Cozi’s current web page template leaves some significant negative space in the lower left (above the clock), as well as a bit in the upper right. Both those spaces vary in size depending on the window dimensions. (The calendar view itself also has considerable space, but that’s highly dependent on which view is selected and how much data is on the calendar.)

The challenge is that negative space doesn’t look like it’s doing anything. It can appear inefficient—like a lost opportunity. In a business driven by display advertising, there is pressure to make pixels generate revenue. It’s nearly impossible to count the value that effective negative space contributes to a user experience, but it’s very easy to estimate the rent those same pixels might generate if they were converted to display advertising inventory. The thing is, those empty pixels are doing something. The user experience would be different—worse—if the space were filled.

(The Leaderboard ad in the image above is actually a different problem. That ad isn’t filling space that was previously empty; it’s consuming space that would otherwise be used to show user data. See my earlier post on why it’s easier for users to image hiding an ad than completely redesigning a UI.)

Negative space is hard concept to love, but it turns out that most people demonstrate an intuitive grasp of negative space in the context of their own homes. In home after home, you can observe that the occupants have very carefully hung pictures or paintings on the wall so as to give each piece space to breathe. You will rarely see a bunch of paintings crammed together on a wall. Most people effectively use negative space with no training beyond the casual observations of positive examples in other homes, museums, offices, or anywhere art is displayed. At some subconscious level, people must be so sensitive to the value of negative space that they are willing to do work to preserve negative space in their own surroundings.

The defense of the negative space in a user experience, however, is a never-ending battle. New proposals to “fill that space in” with a new feature, ad, or other element arise on a monthly, sometimes weekly, basis. Defense of the open space is wearisome but necessary. Once that’s space is gone, it’s usually gone forever.

If your user got the result they wanted, what do you care if they didn’t do it the most efficient way?

Probably the most painful experience I have on a regular basis in my professional life is watching usability studies. Last year I became a big fan of UserTesting.com for conducting remote, unmoderated usability studies. In my experience, it’s been ridiculously fast, highly informative, and very inexpensive. Years ago I could only experience the agony of watching a floundering user by sitting behind a one-way mirror in a very expensive usability research lab. Now I can recapture that agony for only $39.

The most painful aspect of watching a usability study is seeing a well-intentioned UI — one you were sure would be a success — actually cause a user emotional distress. But the second most painful aspect of watching a usability study is seeing a user successfully accomplish a task in 10 steps which they could have accomplished in two. For example:

1. A user wants to copy and paste a word. They carefully mouse down at the beginning of the word, slowly drag across the word, then let go. They move their mouse waaaay up to the Edit menu, click, then slowly read down the list of menu items until they come to “Copy”. They select Copy. Whew, they’re halfway there. They reorient themselves, and then click where they want to paste the word. They move their mouse waaaay back up to the Edit menu, click, then slowly read down the list of menu items until they come to “Paste”. Click. Voilà!
   
   
   
   
2. A user wants to move a window. They drag the upper-left corner of the window to a new location. They then drag the lower-right corner of the window to a new location, taking care to make sure the window is now roughly the same size it was before.
3. A user wants to browse to a URL. They click their browser’s Home button to return to a page that has a Google search box. They type the URL into the Google search box, then click Search. Google displays a long page of results (with ads!). The user finds a link to the desired URL at the top and clicks it.

It’s impossible to watch these events and not want to rush in and tell the user about how to use keyboard shortcuts, drag a window’s title bar, type in the address bar. Hey, user, you could be so much more efficient! This instinct, while natural, and somewhat altruistic, also has at its core some compulsive behavior. Software developers obsess a bit about Whitespace, The Silent Killer. Software designers obsess a bit about user inefficiency.

To be clear, being on the lookout for such inefficiencies is an absolutely critical design skill, as is being able to iterate towards a design that’s more likely to encourage efficient behavior. It’s worth asking, however: if the user got what they wanted, and is satisfied with the time and energy they spent, why should the fact that they ignored a more efficient route have to be troubling?

Changing a design—even for the better—has its own costs: the designer’s, the engineer’s, the tester’s, the support staff’s, not to mention the existing users’ time to learn something new. And sometimes a blunt attempt to force-train the user a more efficient path is worse than the original problem. (Remember all those “Tip of the day” dialogs that used to pop up on application startup to tell you all about a keyboard shortcut the app’s designers thought you really should know?)

Sometimes, however, it’s best to leave well enough alone. It can be enough to rely on the user’s ability to follow the information scent down a path that’s circuitous, long — and successful. If a feature’s design is generally letting users accomplish their goals, you probably have more urgent design priorities to address.

I’m always interested in hearing cases like this, where a user followed a circuitous but ultimately successful path. What’s the most extreme case of this you’ve seen?

Where should the hit target boundaries for UI elements go?

Have you ever clicked on a portion of a screen you thought was interactive, but it had no effect? Or tapped on something expecting one action, but got another? Sometimes the issue is that the actual hit target for a UI element differs from what can be assumed from the element’s visual appearance. There are some subtleties in picking the hit target boundaries for a UI element, but I haven’t seen much analysis of the topic, so thought I’d share some observations.

Time was, if you wanted a UI element to be clickable, you put a thick 3D border around it:

The 3D border lets the user they can activate the UI element by “pressing” it with a pointing device. The hit target here could not be missed: it was the entire area defined by the rectangular border. This is clear, but those 3D borders add a considerable degree of clutter. The borders of the button above, from Windows 95, are actually quite refined from an earlier age of thicker, heavier, and uglier borders. (In the early 90s, I was asked to sit on a Microsoft task force in which representatives of different teams spent months arguing about what the standard button border treatment should be. The group fought over the correct width for a 3D border, over the placement of the apparent light source, and over the precise shadow treatment for corner pixels. See how the white line on the top dives into the black line on the right, so that the upper-right corner pixel is black? You have no idea how much blood was spilled over that corner pixel.)

As time passed, it became apparent there were other ways to suggest interactivity. For example, it turns out that an element’s mere existence can suggest interactivity: if you put a little icon in the corner of a window, and there’s no other obvious reason for why that icon would be there, a user can reasonably conclude the icon is an interactive element. Similarly, giving an otherwise flat piece of text a distinctive appearance (say, blue and underlined) can be enough to let a user know the text constitutes a clickable link. So borders began to drop away.

But once borders are removed, a question arises: exactly which pixels should constitute the element’s hit target? There seem to be several basic strategies:

 

1. Explicitly define the hit target with a boundary line. This is the strategy behind the 3D border shown above, although many other boundary treatments are possible. The boundary itself can be a line with an inner and outer edge, or it can simply be a change in background color. The boundary’s shape is nearly always rectangular, even if the corners sometimes appear to be rounded.

 

2. Implicitly define the hit target as being relatively close to the visible pixels for an irregular object, such as text or an icon.

The little heart icon in the upper right of this control group is interactive — but exactly which pixels are clickable? If only the gray pixels were clickable, that would be a disaster; a user could click through in the middle of the heart and miss the target. (I seem to recall an OS long ago—Windows?—in which it was indeed possible to double-click through holes in desktop icons and not actually open the corresponding application.) [UPDATE: David Buxton reports that the OS in question was actually the original Mac OS.] To avoid this problem, hit targets almost always surround the element’s visible pixels.

Since today’s UI tools still make it much easier to define rectangular UI elements than ones with irregular shapes, the most common hit target for an irregular element is a bounding box: the smallest rectangle that completely encloses the visual pixels in the icon or text. The bounding box for a very small element may have additional padding to make it easier to click or tap. Picking the degree of padding requires judgment; if the hit target extends too far away, a casual click or tap might inadvertently activate the element. This problem is especially acute with circular icons, where the corners of the rectangular bounding box can actually extend far past the visible pixels.

 

3. Create a row whose intervals define hit targets. By placing elements at regular rhythm in a visual grid, even irregular shapes end up implying a bounding box.

In this image from Twitter for iPad, the regularity of the inter-button spacing in the upper-right suggests horizontal cells that constitute bounding boxes for the icons they contain. In such a row, a button’s hit target typically extends halfway to its neighbors. That amount of padding is much larger than would be expected if one of these buttons were standing on its own. This approach was what allowed toolbar buttons to be some of the first buttons to lose their thick, 3D borders. It’s particularly useful on touch device, where large hit targets are beneficial.

 

Regardless of which hit target strategy you pursue, on a device with a mouse, you can employ mouse hover effects to clarify the hit target. The hover effect might reveal the actual hit target: e.g., showing the rectangular hit target boundary being applied to an irregular object. Or, in a case like that of a change in link color on hover (which still leaves an irregular shape), the appearance of the hover effect at least indicates when the mouse has crossed the hit target boundary.

This toolbar ribbon from Microsoft Word 2010 uses all three of the above strategies:

The combo boxes use visible boundary lines (the first strategy above). The toolbar buttons appear in rows with regular spacing (the third strategy). The visual rhythm isn’t perfectly regular; it’s somewhat altered by narrow group separators, as well as dropdown arrows that make some buttons effectively wider, but the inter-button spacing is consistent. Finally, the tiny icon in the lower right corner, which is not part of any row, defines its hit target with a bounding box tightly drawn around the icon’s visible pixels (the second strategy). In all cases, hover effects are used to good effect to clarify the hit target.

 

As the opening questions of this post suggest, there are cases where hit targets may not be apparent, and may confuse users. In these palette tabs from Adobe Photoshop CS5, consider the small dropdown icon in the upper-right corner:

The dropdown icon is an irregular shape, which suggests a tight-fitting bounding box — but it’s also inside a rectangular boundary (the leftover space not used by the tabs), which suggests the whole rectangle is targetable. The former is actually the strategy which Adobe employed here, but a user might easily be led to click in the empty space to the left of the icon. This is clarified somewhat by a hover effect on the icon, but there’s still opportunity for confusion.

Confusion can also arise when hit targets overlap, or appear to overlap. Apple makes occasional use of (apparently) overlapping hit targets in iOS table views:

The blue disclosure arrow button at the right is a independently targetable UI element sitting on top of another, larger targetable table row. Tapping the disclosure button has a different effect than tapping the overall row. To me, at least, this is endlessly confusing. Sometimes I tap the blue button when I mean to tap the row; sometimes I want the effect of tapping the button, but tap the row instead, forgetting that action has a different effect. This confusion is compounded by the fact that slightly different disclosure arrows used elsewhere in other iOS table views to indicate that tapping anywhere in the row including on the arrow will bring up more detail. The table view UI above looks clean, but in my opinion, that comes at too great a cost. Perhaps the UI would be clearer if, for example, this table view displayed a vertical line, just to the left of the arrow, to carve out a square box on the right end of the row for the disclosure arrow (i.e., used the first strategy above instead of the second).

Hit target boundaries are rarely this confusing, however. In most cases, following one of the strategies above will lead to a UI people can readily pick up and use effectively.