We just launched customizable colors for Taurus. Our users can now change the way their tooltips appear to their visitors.
One of the challenges we faced in testing was having too many attributes to define. If you’re going to have a customizable product, let your users go crazy, but for the love of God, let’s keep the interface sane.
We had assembled an uncomfortably long list of colors that should be customizable. Note that “should be” is not the same as “user wants,” several of these options existed to avoid a situation where dark text might show up on a dark background. A button alone could potentially have the following attributes:
- Background color
- Text color
- Hover background color
- Hover text color
Yucky.
So while we wanted to allow the user to go all Burger King on the tooltips, we didn’t want to discourage them with some monstrosity of a control panel. We needed to find a way to consolidate these options.
We figured that several of these could be defined programmatically. For example, if a user defines a dark background for a button, the text color should not be dark. This was nothing a few if-statements couldn’t solve, but how do we determine whether a color is light or dark?
It turns out that simply averaging the color’s RGB values isn’t enough, in fact, there is a specific formula to determine a color’s luminance. Blues are actually perceived by humans to be darker than reds or greens. So if a color is heavy in blue, it actually ends up looking much darker.
If a user defines a dark red for a button in Taurus, we now automatically define the following attributes using the luminance calculation:
- Set the text and hover-state text to white.
- If the tooltip background is dark, the button’s hover-state background will be pink, and vice versa.
This drastically reduces the number of things a user has to think about, behaves as expected, and will appropriately go unnoticed for the most part (except for the few people who will have read this).
