From d9dacb8b6a5ff5cca2c10c8b49bf5a5c241fd400 Mon Sep 17 00:00:00 2001 From: Damien Cuny Date: Tue, 13 Aug 2024 09:42:11 +0200 Subject: [PATCH] Fix comments --- ...-02-how-to-manage-hundreds-of-templates.md | 40 +++++++------------ 1 file changed, 14 insertions(+), 26 deletions(-) diff --git a/_posts/2024-08-02-how-to-manage-hundreds-of-templates.md b/_posts/2024-08-02-how-to-manage-hundreds-of-templates.md index a9fcc423d..31830a4ca 100644 --- a/_posts/2024-08-02-how-to-manage-hundreds-of-templates.md +++ b/_posts/2024-08-02-how-to-manage-hundreds-of-templates.md @@ -29,8 +29,8 @@ At their disposal, they have a design system : a set of visual asset they can us Sample screens composed of design system components -![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/home-m6plus.png) | ![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/home-videoland.png) | ![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/home-rtlhu.png) -:-:|:-:|:-: +![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/home-m6plus.png) | ![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/home-videoland.png) | ![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/home-rtlhu.png) +:-:|:-:|:-: This results in, approximately, one hundred design elements per client. However, not all components are always specific, and an inheritance system is in place to allow clients to reuse default atoms, molecules, or organisms while applying the tokens corresponding to their brand. The objectives and expectations vary greatly among clients, resulting in numerous graphical element evolutions. Managing the creation and progression of these elements through different processes is a major challenge in tracking designs across each platform. These demands sometimes lead to different integrations. Whether or not the default design is inherited is crucial information to avoid manually comparing the app designs with documentation, which can lead to misunderstandings and wasted time during validation and approval processes. @@ -43,19 +43,15 @@ Therefore, implementing a versioning system became essential to continue enrichi - Be directly accessible with each build to stay in touch with the application it represents. On mobile, many builds are generated daily, making it difficult to track the arrival of new features. - Stay up-to-date with the constant evolutions of the design system to maintain the source of truth. -
- -![Release note of the Design system](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/design-release-note.png) - -
+![Release note of the Design system](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/design-release-note.png) -Initially, the design team began by versioning its releases and all available components, which are accessible to technical teams in our online design documentation (hosted on ZeroHeight). This versioning is common to all platforms and all clients if there are no specificities for the component in question. Ultimately, versioning helps product and technical teams track the delivery progress of new designs. The version number follows these rules: -Code status | Stage | Rule | Example -:-:|:-:|:-:|:-: -First release | New collection | 1.0.0 | 1.0.0 -Documentation update without impact on the anatomy of design element | Documentation update | Increment the third digit | 1.0.1 -New backward-compatible feature | Minor release | Increment the 2nd digit and reset the third | 1.1.0 -Change on element that break backward compatibility | Major release | Increment the first digit and reset the second and the third | 2.0.0 +Initially, the design team began by versioning its releases and all available components, which are accessible to technical teams in our online design documentation (hosted on [ZeroHeight](https://zeroheight.com/)). This versioning is common to all platforms and all clients if there are no specificities for the component in question. Ultimately, versioning helps product and technical teams track the delivery progress of new designs. The version number follows these rules: +Code status | Stage | Rule | Example +:-:|:-:|:-:|:-: +First release | New collection | 1.0.0 | 1.0.0 +Documentation update without impact on the anatomy of design element | Documentation update | Increment the third digit | 1.0.1 +New backward-compatible feature | Minor release | Increment the 2nd digit and reset the third | 1.1.0 +Change on element that break backward compatibility | Major release | Increment the first digit and reset the second and the third | 2.0.0 Each frontend team was then responsible for implementing an equivalent versioning system representing the state of their platform. This was done through a feature team including all frontends, design system managers, and the product team. This organization brought numerous benefits: @@ -71,21 +67,13 @@ Each client has their versioning file containing all the components available on - The component is inherited and thus has no specificities and no version in the client's versioning file, using the generic Bedrock customer version. - It has its own element implementation and its associated version. -
- -Default Versioning file | Customer Versioning file -:-------------------------:|:-------------------------: -![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/versioning-file-default.png) | ![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/versioning-file-customer.png) - -
+Default Versioning file | Customer Versioning file +:-------------------------:|:-------------------------: +![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/versioning-file-default.png) | ![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/versioning-file-customer.png) From these versioning files, we have been able to generate reports for each platform containing only the available graphical elements and their version, whether inherited or not. To track their growing number, we opted for automatic generation of these reports with each build in our continuous integration system using a KGP (Kotlin Gradle Plugin) script integrated on our continuous deployment and integration (CI/CD) : Bitrise. -
- -![Template versioning report for a customer](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/template-versioning-report.png) - -
+![Template versioning report for a customer](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/template-versioning-report.png) ## Conclusion