When I was visiting the droidcon UK last year, I was inspired by Matthew Dolan’s talk “Design and development: Best practices by example” how to organise my colors understandable, reusable and maintainable.
This can be achieved by two steps.
The Bad Way
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
- etc.
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.
<resources>
<color name="black">#000000</color>
<color name="dark_grey">#525F6B</color>
<color name="dark_grey_25">#d4d7da</color>
<color name="dark_grey_50">#a8afb5</color>
<color name="dark_grey_75">#7d8790</color>
<color name="dark_blue">#005691</color>
<color name="dark_blue_link">#00639a</color>
<color name="light_green">#78BE20</color>
<color name="light_grey">#BFC0C2</color>
<color name="light_grey_25">#EFEFF0</color>
<color name="light_blue">#008ECF</color>
<color name="red">#E20015</color>
<color name="turquoise">#00A8B0</color>
<color name="white">#ffffff</color>
</resources>
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:
<resources>
<color name="button_primary">#005691</color>
<color name="button_primary_shadow">#008ECF</color>
<color name="button_primary_text">#ffffff</color>
<color name="button_ghost_frame">#000000</color>
<color name="button_ghost_text">#000000</color>
<color name="button_ghost_background">#ffffff</color>
<color name="text_link">#00639a</color>
<color name="text_task_open">#7d8790</color>
<color name="text_task_in_progress">#BFC0C2</color>
<color name="text_task_finished">#78BE20</color>
<color name="text_normal">#EFEFF0</color>
<color name="text_marked">#d4d7da</color>
<color name="text_heading_1">#525F6B</color>
<color name="text_heading_2">#a8afb5</color>
<color name="text_hint">#7d8790</color>
<color name="text_task_open">#008ECF</color>
<color name="text_error">#E20015</color>
<color name="navigation_drawer">#00A8B0</color>
<color name="layout_primary_background">#ffffff</color>
</resources>
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.
Creating 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.
<resources>
<!-- Colors to apply in views -->
<color name="button_primary">@color/bahama_blue_general</color>
<color name="button_primary_text">@color/white_solid</color>
<color name="button_primary_shadow">@color/lochmara</color>
<color name="button_ghost_frame">@color/black_solid</color>
<color name="button_ghost_text">@color/black_solid</color>
<color name="button_ghost_background">@color/white_solid</color>
<color name="text_link">@color/bahama_blue_link</color>
<color name="text_task_open">@color/bahama_blue_general</color>
<color name="text_task_in_progress">@color/silver_sand</color>
<color name="text_task_finished">@color/lima</color>
<color name="text_normal">@color/gray_athens</color>
<color name="text_marked">@color/gray_iron</color>
<color name="text_heading_1">@color/gray_shuttle</color>
<color name="text_heading_2">@color/gray_chateau</color>
<color name="text_hint">@color/gray_oslo</color>
<color name="text_task_error">@color/monza</color>
<color name="image_brand_logo_tint">@color/you_tube_red</color>
<color name="navigation_drawer">@color/bondi_blue</color>
<color name="layout_primary_background">@color/white_solid</color>
<!-- Palette colors -->
<!-- Colors for "internal use" only -->
<!-- General palettes -->
<color name="black_solid">#000000</color>
<color name="lochmara">#008ECF</color>
<color name="lima">#78BE20</color>
<color name="monza">#E20015</color>
<color name="you_tube_red">#A20015</color>
<color name="bondi_blue">#00A8B0</color>
<color name="white_solid">#ffffff</color>
<!-- Palette Bahama blue -->
<color name="bahama_blue_general">#005691</color>
<color name="bahama_blue_link">#00639a</color>
<!-- Palette gray -->
<color name="gray_athens">#EFEFF0</color>
<color name="gray_chateau">#a8afb5</color>
<color name="gray_iron">#d4d7da</color>
<color name="gray_oslo">#7d8790</color>
<color name="gray_shuttle">#525F6B</color>
<color name="gray_silver_sand">#BFC0C2</color>
</resources>
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.
Naming palettes
There are several possibilities how to name the internal colors. E.g. these color codes can be named by tools. 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.
Conclusion
Thanks to Matthew Dolan, we can sum up the recommendations as follows:
Rules for colors in your views
- Avoid naming by colors
- Function over context
- Generic to specific
Rules for palettes
- Define palettes
- Name palettes by color
- Prefix your palettes
