Ubuntu’s Semantic Indicator Color Palette

It wasn’t until Mark Shuttleworth’s announcement of “windicators” that I learned of the rationale behind the palette of notification colors in the indicator applet. To quote:

[Windicators] would follow the same styling as Ayatana indicators: Semantically colored: with red for critical problems, orange for alerts, green for positive status changes and blue for informative states that are not the default or usual state.

This came as a real surprise given that I had (and still have) never seen a blue or orange indicator icon.

The obvious and primary objection is that four colors in a palette to convey meaning is far too many. Shuttleworth even said as late as April 1 — just four weeks before Lucid’s release — “Personally, my expectation is that green vs orange/red is as far as we want to go.” Two colors is an absolute maximum here — one for negative messages about something being broken, the other merely to notify you of something — although even one should suffice: “Something has changed; requesting your attention.”

If “orange is for alerts” and “green is for positive status changes,” then why do new IM messages turn the messaging icon green? Isn’t that an alert? What is “positive” about getting a new message? What if it’s your boss firing you? Your boyfriend breaking up with you? A spambot?

If red is “for critical problems,” why does your sound indicator icon turn red when something’s trying to play while it’s muted? Is that really “critical”? Doesn’t that deserve something more accurately described as “an alert” (orange)?

Furthermore, if it’s up to the application developers to specify the “severity” of an alert — which is not even an accurate description of the purpose of these colors, as they’re not a spectrum of severity, but rather a whole handful of messages — will this not result in a great deal of inconsistency? If one application feels that its behavior is more important than that of other applications, it can choose to make its indicator icon red rather than green (or orange or blue) on an event. And, more fundamentally, you’re placing a burden on developers who wish to use indicator icons for alerts to choose from among four different states, rather than just coding for “Alter the color of my [w]indicator icon to whatever the user’s desktop theme calls for.”

It even appears as though this “spec” isn’t complete; Rhythmbox’s indicator icon is black when playing, gray when not playing (under the Radiance theme). What does gray mean? Before I started writing this blog post, in fact, I’d have guessed it meant that Rhythmbox was minimized, as I frequently see a gray icon when Rhythmbox is hidden. Turns out I was wrong, and that’s after using Lucid and Rhythmbox daily for three months.

The intent behind the specification is flawed for those and probably other reasons, and the execution is flawed as well. If you inspect the colors of the green and red indicator icon colors — I couldn’t manage to turn any of them blue or orange, so if you have, please leave a comment — you’ll see that green is #4dcb00 and red is #dc0000. I imagine we’ll never know why these colors were chosen, but something is revealed in the choice of that green in particular.

“Ubuntu Aubergine” has a hue (in RGB colorspace) of 328. Just opposite that on the color wheel — the most basic color complement pair you can find — is a color with a hue value of 81: a particular shade of green. And not the shade being used by indicator icons.

That’s right: even though the indicator icon color spec called for a shade of green, and even though there is a shade of green directly opposite Ubuntu Aubergine on the color wheel, Canonical’s designers chose an utterly arbitrary shade of green with a hue of 95.

Astonishingly, the original proposal for a green coloring of a new indicator message was closer to the Ubuntu Aubergine complement than the final implementation (with a hue of 72, just 9 degrees from the “correct” hue). It’s worth noting, of course, that Ubuntu Aubergine had not been formalized and documented at this point (nor had it been as of April 28.)

It’s also worth mentioning that a green hue of 104 is triadically complementary to the pair of colors of Ubuntu Orange and Ubuntu Aubergine. So either of these two greens — 81 and 104 — could work in theory. But neither was used.

Finding red and blue complements is a bit more difficult, making stronger the case for a single notification color. Although “blue” is a complement of “orange,” Ubuntu Orange isn’t quite “orange” enough to have a 180° blue complement. The best I could manage is a hue of 191, which is a triadic complement of Ubuntu Orange with a 42° differential (the same as that between Ubuntu Aubergine and Ubuntu Orange). The “proper” red would be just between Ubuntu Aubergine and Ubuntu Orange, or a hue of 351. The current red has a hue of 0 — i.e., pure red — which should come as no surprise. Red = red, right Canonical?

Still, I contend that one color should suffice, and in that case, Ubuntu Orange is probably the way to go, if the plan is to continue with an Ubuntu Aubergine desktop wallpaper and Ubuntu Orange highlights in the GTK theme.

The important point to take away from this is that the current colors are symptomatic of a lack of concern for fundamental design practices within the Canonical design community. The hues of green I’ve mentioned, for instance, may be indistinguishable to most users in practice (even to designers, given the size of the icons), but that I’ve so easily shown them not to be “correct” is alarming.

4 Responses to “Ubuntu’s Semantic Indicator Color Palette”

  1. Frederik says:

    Funny enough, on a technical side, libappindicator specifies exactly three statuses: Passive (means hidden), active (means visible in normal state) and attention (means visible requesting the users attention), see http://people.canonical.com/~ted/libappindicator/current/AppIndicator.html#AppIndicatorStatus

    And it is technically possible to specify icons for the two visible states, active and attention. So on the API side, your idea of just having one attention color in addition to the monochrome normal state is implemented. And in order to use more colors, one has to work around the API and set different icons for active/attention status.

  2. Jay says:

    Thanks for the info, Frederik. As you can tell, I’m not a programmer, and as such, there’s only so much I can glean from mailing lists, blogs, and wikis about Canonical’s design specifications. Glad to know things are as simple as that. Does this mean that the sound indicator is working around the API when it paints the muted speaker red? Or is green the exception?

    Here’s hoping the spec doesn’t grow to include blue and orange.

  3. Frederik says:

    I’m not really an expert on the programming side, but I think sometimes a look into the code reveals some of the basic concepts used in the application design. (On the other side, I find your insights into design principles really enlightening.)

    I think the sound indicator doesn’t use the AppIndicator API, which is rather an abstraction layer for easier integration into applications. But e.g. the rhythmbox indicator does use set_icon() a lot, while the original idea seems to be to just use set_icon() and set_attention_icon() once and then use set_status() to show one of them. So it is of course possible to use as many icons as you want (and rhythmbox needs it to show playing state etc.), but the API clearly defines only one single attention status.

  4. Snader says:

    One thing to keep in mind is that perceived colour can be very different from the absolute colour code. The design team may have aimed at the complementary colour, but found that it didn’t look right on the panel’s background.

    But, nice article, keep up the good work and make sure the design team notices.

Leave a Reply