Great UI: Clarity and Color on the Presentation Layer

Color consists of:

  • Hue Hue
  • Saturation Saturation
  • Lightness Lightness

Consider the images below:

     
On the left gaze attracts toward the deeply saturated hues, and the mind grapples with the hue variance and attempts to discern meaning (of which there is none).   On the right, with all shapes represented in the same hue, gaze attracts toward interesting details and the mind attempts to discern meaning from shape, of which there is a great deal.

From this, an important lesson:

Hue variance should justify itself.

Two screen shots from the iTunes installer: one real; one altered.

 
On the left you have an interesting variety of hues, with saturation and lightness apparently disconnected from information relevance.    On the right the same data is represented with only a single hue. Saturation and lightness levels are consistent with the information presented.

Which image would you rather see during an install?

So hue variance must be justified. Following this guideline over time, we eventually realize a second, important guideline:

Fewer hues is better.

Now let's move to an example that pretty much disregards that guideline. Here's a screen shot from an Excel spreadsheet we use to track refactorings shipped in Refactor! Pro (click to see the full-size image):

In this spreadsheet, each language supported has a dedicated color (e.g., C# is red, VB is green, C++ is orange, etc.). Also, at the far right of the spreadsheet we track the version where each refactoring was introduced, and also we also note whether that refactoring ships in CodeRush Xpress or Refactor! for Visual Basic. Here too color carries meaning, and is useful. If you're interested in refactorings that only support XAML, for example, you can scan your eyes down and look for a blue circle in the XAML column.

The column headers serve as a legend of sorts, connecting color to the data it represents:

We even follow this convention in descriptive text inside the spreadsheet, for example in this description for the Rename refactoring:

Speaking of Excel, the Excel application itself uses color in an interesting way. When editing formulas, Excel uses color to connect the cell reference in the formula to the cell on-screen. In the screen shot below, the cell reference "R[-4]C" is rendered in blue, and there is a corresponding blue box surrounding that cell:

On to a practical example. Let's say we have an application that presents sales data to managers, like this:

Managers using this application want to quickly see the best and worst members of the sales team.

So let's use red to indicate the lowest values, and green to indicate the highest values.

That's not too bad. Now at a glance we can see the best and worst performers for any quarter. And we've reached a third guideline:

We can enhance clarity with color.

Sometimes I hear developers say:

"You shouldn't use color at all to convey meaning, because a significant percentage of the population is color blind."

Is this a reasonable guideline to follow?

Let's find out.

First, a bit of background: Color blindness affects 8.6% of males and about 0.4% of females (or 4.5% of the entire population). Our eyes detect low-light variances with rod cells, and full spectrum bright-light variances with cone cells, of which there are three types: L-cones, M-cones, and S-cones. When there is a defect or absence in one of these groups of cones, color blindness occurs. Many of the color vision genes fall on the X chromosome, which is why color blindness occurs more frequently in men.

Here's the color vision breakdown for humans on this planet:

In addition to the percentages listed at the top, each color vision category in the figure above includes a list of six named colors, rendered as a person in that category would view them. Note that for the two most prevalent forms of color blindness (M-cone defect and L-cone defect), differentiating between red and green, as well as between blue and magenta, is challenging if not impossible.

Notice however that for all categories listed, differentiating between red and blue is relatively easy.

How does this impact our widget sales application? For someone with an M-cone defect, the data looks like this:

And we lose our at-a-glance ability to see the highs and lows. But what if we take the information learned above, and instead of using red and green, we differentiate with red and blue? Then to someone with normal vision, that change looks like this:

And to someone with an M-cone defect, the same data would look like this:

And so we are able to keep with the intent of using color to convey meaning, and do so in a way that works even with people who are color blind.

And we have a new, important lesson:

When conveying meaning with color, use reds and blues to differentiate, rather than reds and greens.

Speaking of conveying meaning with color, you might be wondering what Excel's cell-reference color-highlighting looks like to someone with an M-cone defect. It looks something like this:

As you can see, we get into trouble with Excel's choice of color for the first and third cells referenced in the formula. The blue and magenta both appear blue, and are nearly impossible to distinguish. Here are sections of the two views, enlarged:

Should Microsoft address this? Well, let's look at the impact. Editing formulas is something most Excel users do at some point with the product. So it's a highly visible feature of the product. Excel has over 450 million users, and that means over 20 million color blind Excel customers are impacted by this choice. Seems like the answer is a resounding Yes.

So how can the Excel team fix this? One option would be to slightly increase the lightness of the third color, magenta, so it appears as a lighter blue to someone with an M-cone defect, making it easier to distinguish from the first color. That simple change would look like this:

All this leads us to a final lesson about color:

When conveying meaning with color, differentiate by varying lightness in addition to hue.

So here are the guidelines for color, once again:

  • Justify hue variance.
  • Fewer hues is better.
  • We can enhance clarity with color.
  • Use reds and blues to convey meaning, rather than reds and greens.
  • Convey meaning by varying lightness in addition to hue.

Coming soon, we'll discuss clarity and noise. After that we'll dive into the second essential component of Great UI: efficiency.

Free DevExpress Products - Get Your Copy Today

The following free DevExpress product offers remain available. Should you have any questions about the free offers below, please submit a ticket via the DevExpress Support Center at your convenience. We'll be happy to follow-up.
No Comments

Please login or register to post comments.