After some interesting introductions to Atomic Design and design system, we decided to jump in and launch our own design system implementation starting with our Android app. The purpose of this article is to share the very first steps, from an Android developer’s perspective.
Why introduce a design system?
Users are more and more sensitive to design, and following Google and Apple becomes hard as their guidelines are continually evolving. In addition, the iterative process building screen from an old one, shows its limits when we want to stay on track with an always up-to-date product. The main issue is the loss of consistency. Each iteration brings its own batch of variants; the most common example being buttons. Old screens are often overlooked and not updated as they are totally separate from each other.
“We’re not designing pages, we’re designing systems of components”, Stephen Hay
Our goal is to have only one source of truth, no matter when the screen has been designed; a week or a year ago. For this to work we need good communication and clear component naming. A design system allows the style guide of an application to evolve easily with minimum additional effort from designers and developers.
The Dailymotion Android app is:
→ 10 modules (3 for apps, then others for tracking, design and helpers)
→ 90% Kotlin code
→ Coroutines started on October 2018
→ Android App bundle
We first created a design module which hosts everything related to design elements, styles and themes. It contains the color map, most of the drawable resources, textview styles and design classes.
To keep the module consistent, we apply some basic rules:
→ Logic and data must be completely separate from the design part. If the job is already done in most cases, some classes could require a lot of effort, but it’s for the best.
→ All design elements should remain in the design module.
We prefixed our classes with “DM” to help developers figure out what’s currently integrated or not. With design classes, we drain color resources, drawables and dimensions. We aggregate elements while working on features or refactoring, leaving the main module even more understandable.
→ The purpose here is to ensure that the design module is the single source of truth. When we follow this rule, views hosted in layouts should never specify directly design attributes. TextView uses styles referenced in the design module. Other views with design configuration must use custom classes and custom attributes if needed.
This way, layouts become simpler, easier to read with only one job: organize and place design elements.
XML vs Kotlin
In atomic design terminology, an atom is the smallest design element (a text element for example), then a molecule is an atoms organization.
Can an atom be simply a style, or do we need something consistent across all design module, and choose Kotlin classes for every design elements?
The main issue with styles is that everything could be styled. There is neither a naming convention, nor a specific place to reference them.
At some point that we haven’t reached yet, we could think about how to deal with all these elements, to keep things clear and easily evolvable. We decided to allow the use of direct styles reference for TextView, hosted in a dedicated textview_styles.xml. The future will tell us if it’s enough.
Attributes vs Classes
When we wanted to move app buttons in our design system, another question arose. Should we use a batch of classes linked to button variants or play with custom attributes and a single class? There is no simple answer. It will depend on the complexity of the variant and the amount of common code. In this specific case, we used enum attributes to cover our needs (buttonSizeMode, buttonStyleMode).
Design Show: the demo app
Why a demo app?
Having a demo app seems pretty natural when you start a design system.
But let’s see the reasons why we need it:
→ First and foremost, this module helps us to keep an eye on all design elements we currently support, then we can use them for any new features or refactor.
→ Module is lightweight as well, the only dependencies are design libraries. Then the compilation is very fast, and during the design phase we can build our view very quickly without following complex user path to see in a very short space of time that the result is not perfect yet.
→ As design module is not dependent on other modules, developing our elements in the demo app allows us to ensure it is completely separate from Logic or Data.
Even more modules
Technically, the demo app adds two other modules
(developers love modules):
This is the only one which hosts our demo logic and exposes all design elements. New views are developed through this module. As all teams have access to the main app, we decided to include the demo app in it, ensuring that everyone, especially designers, are able to discover all our supported elements.
This module is just a manifest declaration hosting the design_show_lib, which we are able to launch it independently from the main app.
Dark mode is trendy but relatively new and it takes time for it to be prioritized on a product roadmap. This doesn’t mean we should forget about it completely. The demo app is a powerful tool to help us prepare dark mode support as we added a toggle allowing us to switch themes. Thus, the behavior of all the design elements in the app can be seen live with the new theme
Legacy code challenges
Upgrading legacy code without a robust and well-experimented design system is costly and time consuming (if not a waste of developer time). It requires developers to name and specify certain atomic elements — which they will eventually need to readjust, rename, merge or split — when the design team is fully ready to handover.
In addition, legacy code set up some years ago is of limited interest in a design system if not upgrade to reflect the current style guide.
Worse, it can pollute it with a lot of new useless styles and classes. The goal is having something evolvable, not to have it all.
This doesn’t mean we should wait for a fully functional design system.
At Dailymotion, we believe change is easier to apply in small steps. With this in mind, our solution allows developers to start using the design system for a new screen at the same time as the discussion for uniformizing older screens is going on. The demo app is an efficient tool to discuss about legacy code and upgrades with the designers.
With patience, step by step, we can prepare the app to be fully functional for a more wider team collaboration and plug it to a design vision. We are at the very early stage, and only the future will tell us if we are right. However, what we can already say is that is better involves developers in design quality and generates a stronger cohesion between teams. Working with a design system points out the design quality and allows us to focus on users expectations.