When I get a list from my designers about the color definitions for my mobile views, it looks similar like this:
Primary button – #005691 – dark blue
Primary button text – #000000 – white
Primary button icon = #005691 – dark blue
Great, I immediately start writing my colors.xml. Of course, I name my colors accordingly to the design color definition to speak the same language as the designers do.
When the project gets bigger and requires more colors, it is getting really confusing and less traceable how to use the same colors in different contexts for different views. But how to name similar colors? Dark, dark grey, darker than dark grey? What if dark_grey_50 color is no longer required?
Well, adapting all layout.xml or style definitions due to changing design requirements is for sure a lot of fun, yihaah!
When I want to reuse colors in views, I keep in mind the following rules:
I am not naming colors by its name (e.g. dark_grey, light_green or red)
I never call them by a specific context (e.g. signup_button)
Instead, I think it is a good practice to name colors
by its UI function (e.g. button_signup)
from general function to more specific function (e.g. button_primary_enabled, button_primary_text)
Naming by its function
When setting the color for a view element, e.g. for a button, it is pretty hard to keep in mind “What color was defined for my primary button? Dark_grey_25, dark_grey_50 or dark_grey_75? Phew…, I have to take a look in my colors.xml and the designer guidelines“.
A more convenient way is to name colors by its function. When I am styling a button, I start typing with “button” as color name. Secondly, I think about the design use case “What type of button do I want to implement? A primary, a secondary or a ghost button? I want a primary button right here, so I need the ‘button_primary’ color!“.
After the first refactoring step, the colors.xml looks as follows:
The weakness of this approach is that several colors are defined multiple times. Although it is more convenient to apply colors in views, it is still error-prone. In case that two resources should use the same color value, changing one of them does not ensure that the second value is refactored as well.
To avoid this, it is recommendable to define color palettes.
Applying the metaphor of several color palettes is the second and final step for a good color naming. The developer becomes the artist taking the right color from the right palette for the perfect occasion 😎
Compared to the first refactoring step, the colors.xml were extended by color palettes.
Palette colors should be limited for internal use only in colors.xml like Java private fields. For instance, the white_solid color can be refactored in one place for several function definitions.
It is recommendable to give palettes a prefix. If a palette consists of one entry, like my general palettes do, I think the prefix is expendable.
There are several possibilities how to name the internal colors. E.g. these color codes can be named by tools like http://chir.ag/projects/name-that-color/. So I do not have to construct color names on my own.
It is also legit to name colors after brand’s, for instance by your customer’s unique characteristic color (or those of other companies https://brandcolors.net/). Instead of naming the red color code #e52d27 as alizarin crimson, I named it you_tube_red.
The crucial point is to keep your color names readable and maintainable. It would have been also possible to name the colors like my designers did. So even they could read and adapt the colors.xml although they have no clue of Android development.
Thanks to Matthew Dolan, we can sum up the recommendations as follows: