Review + Thumbnail

_posts/2024-08-02-how-to-manage-hundreds-of-templates.md

@@ -1,14 +1,14 @@
 ---
 layout: post
-title: "How to manage hundreds of view templates?"
-description: ""
+title: How to manage hundreds of view templates?
+description: Let's dive into the deep of template versionning at large scale in production for a white label streaming application together
 author: [d_cuny, m_oudji]
-category: 
 tags: [android, versioning, design, atomic design, design system]
 color: rgb(251,87,66)
 language: en
-comments: true
+thumbnail: "/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/thumbnail.png"
 ---
+Let's dive into the deep of template versionning at large scale in production for a white label streaming application together
 
 ## The context
 
@@ -28,7 +28,7 @@ At their disposal, they have a **design system**: a set of visual assets they ca
 - 62 **molecules**: group of atoms that forms a visual unity (ex: Card, Poster, HorizontalCard, Button, CTA, Portrait, Totem...)
 - 12 **organisms**: complex visual item or part of the interface (ex: Jumbotron, Hero, Solo, Banner...)
 
-_Sample screens composed of design system components_
+Following some sample screens composed of design system components for different customers: 
 
 :-:|:-:|:-:  
 ![](/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)  
@@ -63,7 +63,7 @@ Each frontend team was then responsible for implementing an equivalent versionin
 - **Limiting** versioning differences between frontends
 - Sharing **industrialization** ideas
 
-## A concrete sample: Android
+## Case study : Android versioning challenges
 
 On Android side, we sometimes have different component implementations between mobile and TV, evolving at different paces. This required **two separate versionings** to represent them. Moreover, we currently use comments to track the migration to Google's new view system (Compose), which is happening alongside graphical evolutions.  
 Each client has their **versioning file** containing all the components available on the targeted platform. Regarding component inheritance from the default design system, there are two possibilities:
@@ -86,4 +86,4 @@ However, improvements are always possible:
 - The reports are currently generated in **XML format**, which does not facilitate their use; using the PDF format would be preferable.
 - **Access through Bitrise** is not ideal. We currently centralize all generated builds (using CI as well) in [Airtable](https://www.airtable.com/). A link would be preferable and more visible.  
 
-Versioning allows us to know the state of all components on a platform at a given time and simplifies the QA teams validation work. It is an essential tool for tracking design progress across all supported platforms.
+Design system versioning allows us to know the state of all components on a platform at a given time and simplifies the QA teams validation work. It is an essential tool for tracking design progress across all supported platforms.