Le retour d’expérience de Mark Dalgleish et son équipe sur la mise en place d’un outillage qui facilite la collaboration des développeurs et des designers sur un style guide, géré d’un côté en React et de l’autre avec Sketch. C’est déjà un énorme progrès mais les outils utilisés par les designers ne permettent toujours pas de travailler directement sur le medium cible.

Demandez à n’importe quelle équipe qui travaille avec un design system et vous comprendrez que les bénéfices sont nombreux — les designers et les développeurs sont plus productifs, les produits sont plus consistants, la communication est plus claire entre les disciplines.

Toutefois, la majorité des design system souffrent toujours d’un gros problème. Les designers et les développeurs continuent de travailler sur des médiums totalement différents. Du coup sans effort permanent de synchronisation manuelle, notre code et nos éléments de design diffèrent de plus en plus les uns des autres.

Pour les boîtes qui bossent avec des design systems, il semblerait que notre industrie soit condamnée à travailler avec des outils de conception qui ne soient pas pensés pour le bon medium — incapables d’incorporer notre travail de développement dans la prochaine itération de design.

Fort heureusement, tout cela est sur le point de changer.

Page d’accueil de la charte de Seek

L’odyssée de notre design system

Chez SEEK, nous travaillons sur notre living style guide depuis plus d’un an maintenant, avec de plus en plus de composants React. Vous imaginez bien que cela nous a amené à revoir totalement notre manière de penser le design visuel.

Nous avions tout d’un coup une seule source de référence, dans le code, facile à installer, qui définit la manière dont notre marque est affichée sur des douzaines de projets différents.

Bien entendu, notre travail sur le design system n’a pas commencé dans le navigateur. Nous avons passé beaucoup de temps en amont pour tenter de formaliser nos règles de conception dans un format plus statique — bien avant que notre living style guide existe.

Ce qui a commencé sous la forme d’un fichier PDF statique, a ensuite évolué en un kit de démarrage Sketch. On pouvait facilement se baser sur les symboles standardisés, les couleurs et les styles typographiques pour démarrer tout nouveau travail de conception.

Notre premier fichier de démarrage Sketch

Nous avons par la suite testé Craft, un ensemble de plugins Sketch d’InVision, le plus notable d’entre eux étant le plugin de bibliothèque.

Cela nous a permis de partager les symboles Sketch à la fois entre les documents et les différentes équipes, mais aussi de bâtir une bibliothèque de symboles partagée avec l’ensemble de l’entreprise.

Plugin de bibliothèque Craft

Nous nous sommes rapidement aperçu de la quantité de travail absurde demandée pour maintenir cette bibliothèque à jour, surtout quand les éléments existants et les nouveaux n’arrêtent pas d’évoluer dans l’ensemble de nos produits.

Les développeurs, souvent en binôme avec les designers, procédaient à des changements dans le code qui pouvaient avoir un impact spectaculaire sur le design visuel, mais notre bibliothèque statique elle restait intacte — sauf si quelqu’un se rappelait de la mettre à jour manuellement, ce qui était rarement le cas.

Et pendant ce temps les mêmes problèmes de consistance se posaient de l’autre côté de la barrière, avec des développeurs à qui une source unique de référence sur le design manquait pour leur code.

De React à react-sketchapp

C’est à ce moment que nous avons commencé à travailler sur notre premier projet React — avec du rendu côté serveur, assemblé avec webpack et des modules CSS que nous avons aidés à co-créer en cours de route — pour finalement aboutir à la création de notre living style guide.

Le fait que React se focalise essentiellement sur les composants a rendu cette transition inévitable. Ce n’est pas étonnant si depuis sa publication, nous avons vu que c’était la même histoire pour d’innombrables entreprises un peu partout dans le monde.

Une fois que nous avons eu développé une collection assez importante de composants, les autres équipes qui travaillaient sur de nouveaux projets ont pu rapidement bénéficier de notre travail — mais comme notre style guide était constitué de composants React et de fichiers Less, il n’était que peu d’utilité pour nos designers. Toutefois, ce problème ne nous a pas sauté immédiatement aux yeux. Cette déconnexion technique entre les designers et les développeurs ne date pas d’hier — comme elle a toujours existé dans notre secteur d’activité, nous nous sommes habitués à ne pas en tenir compte.

Ça c’était bien entendu avant qu’on découvre react-sketchapp.

React-sketchapp

« Dans Sketch, nous utilisons des symboles et des surcharges, dans React des composants et des propriétés. Ces concepts sont si semblables qu’il serait bête de ne pas les unifier.

Jon Gold, Airbnb

C’était trop beau pour être vrai. Du vrai code React, rendu directement dans Sketch. On dirait bien que les développeurs et les designers allaient enfin pouvoir s’appuyer sur un design system comme unique source de référence.

En centralisant nos règles de conception dans le code, non seulement nous pouvions les diffuser sur nos applications en production, mais nous étions également capables de répercuter notre travail dans les outils que nos designers utilisaient déjà. Au fur et à mesure que nos conventions de conception continuaient d’évoluer, nous étions capables de rester synchrone avec nos designers, sans avoir à intervenir manuellement dans Sketch.

Bien sûr, après avoir creusé un peu, nous avons découvert que react-sketchapp imposait quelques contraintes :

  1. Les composants doivent (évidemment) être développés avec React. Heureusement pour nous nous utilisions déjà React, ce n’était donc pas un problème.
  2. Les styles doivent être définis en JavaScript. Dans notre cas, vu que notre design system était développé avec des modules CSS, c’était déjà un premier obstacle. Même si nous sommes de grands fans de CSS-in-JS nous n’allions pas corriger l’ensemble des styles de notre écosystème — du moins pas dans l’urgence.
  3. Les composants doivent utiliser des primitives génériques (View, Text, StyleSheet) plutôt que les primitives du navigateur, à l’aide par exemple de react-primitives. En gros, react-sketchapp était plus proche de React Native que de pur React. Encore une fois, c’est une migration que nous aurions pu envisager, mais qui aurait demandé beaucoup de travail et quelques arrangements au passage.

Donc bien que react-sketchapp soit un projet extraordinaire, que nous vous recommandons chaudement, ses pré-requis techniques faisaient que nous n’aurions pas pu l’utiliser à court ou moyen terme.

Même si vous avions décidé de migrer notre bibliothèque de composants, nous aurions eu besoin d’une autre solution entre temps.

Versionner les fichiers de conception

Comme vous le savez peut-être déjà, il existe des outils qui vous permettent de versionner vos fichiers dans vos outils de conception —— mais c’est le monde à l’envers.

Nous avons besoin que nos outils de conception soient compatibles avec le contrôle de version, et non l’inverse. Nous avons besoin que les fichiers produits par les designers figurent aux côtés de ceux produits par l’ensemble de l’équipe — et non dans un silo réservé aux designers, hébergé dans un jardin privé.

Nous avons donc essayé de faire autrement.

Nous avons expérimenté l’enregistrement de fichiers Sketch dans le dépôt de notre style guide à l’aide de Kactus et de quelques scripts Node maison.

Kactus, montrant les différences d’un fichier Sketch enregistré avec Git

Même si nous avons pu réaliser cette prouesse technique, nous étions déçus de nous apercevoir que le flux de travail ne fonctionnait pas comme nous le souhaitions — en tout cas, pour ce qui nous concerne. Le fait de devoir synchroniser deux formats de fichiers radicalement différents s’est avéré fastidieux, sujet à des erreurs, et difficile à passer en revue.

Garder le code et les fichiers Sketch dans un même emplacement a pu aider à clarifier le problème, mais ça n’aidait pas vraiment à le résoudre. Pire, cela a provoqué de nouvelles frictions pour les contributeurs au style guide, pour un gain minime. Les fichiers Sketch ont rapidement été laissés de côté. Cette expérience fut pour nous un échec.

Mais au moment où nous commencions à perdre espoir de faire travailler ensemble les développeurs et les designers sur un même projet html-sketchapp a débarqué et a changé toute la donne.

L’émergence d’html-sketchapp

En définitive, nous n’étions pas les seuls à avoir des difficultés à intégrer react-sketchapp dans notre stack technique existante.

« Nous étions incapables de simplement passer outre ces limitations, nous avons donc créé html-sketchapp »

Konrad Dzwinel, Brainly

Ils ont pris une approche radicalement différente avec html-sketchapp.

Comme son nom l’indique, html-sketchapp permet de générer des fichiers Sketch à partir de fichiers HTML normaux, mais contrairement à react-sketchapp, vous restez libre des choix techniques pour votre application.

Vous pourriez développer votre application avec Preact, Vue, Angular, Backbone, jQuery — ou même Ruby ou PHP.

Vous pouvez bien entendu utiliser React et cette fois vous pouvez gérer les styles comme bon vous semble, et utiliser les primitives qui font sens pour votre projet.

Le contrat était incroyablement limpide — du moment que vous pouvez générer du HTML, vous pouvez l’importer dans Sketch.

Génération des fichiers Sketch

À première vue, c’était trop beau pour être vrai, mais après avoir jeté un œil sous le capot, nous nous sommes rendu compte que ce n’était pas si compliqué.

Pour comprendre le fonctionnement de html-sketchapp, il faut connaître le format de fichier de Sketch. Étonnamment, les fichiers Sketch sont juste des fichiers zippés.

Une fois dézippés, on s’aperçoit que les fichiers Sketch sont principalement constitués de fichiers JSON qui peuvent être ouverts dans n’importe quel éditeur de texte.

Si vous regardez attentivement le contenu de ces fichiers, vous verrez que c’est un format relativement simple, constitué en grande partie d’une petite poignée de classes imbriquées.

À bas-niveau, html-sketchapp permet de générer à l’aide d’un programme des instances de ces classes et de les convertir en JSON — mais ça ne s’arrête pas là.

La fonctionnalité la plus puissante dans html-sketchapp c’est nodeToSketchLayers, qui vous donne la possibilité de convertir un élément unique du navigateur en un tableau de calques Sketch. C’est là où toute la magie opère, puisque la fonction possède toute la logique pour extraire les styles du navigateur et les convertir en leurs équivalents dans Sketch.

C’est la classe SymbolMaster qui lie vraiment le tout, elle permet de générer dynamiquement des symboles Sketch. Puisque les symboles sont la base de toute bibliothèque Sketch, cela nous a permis d’exposer un ensemble de composants à nos designers, à partir du code sous-jacent.

Malheureusement, certaines limitations dans le format actuel de Sketch liées à l’encodage des styles de texte font que les fichiers générés se sont pas vraiment des fichiers Sketch valides — html-sketchapp les désigne comme des fichiers à peu près Sketch ou asketch pour faire court. Du coup il faut les importer manuellement avec le plugin html-sketchapp pour Sketch. Ça va, c’est pas trop compliqué.

Assembler le tout peut paraître un peu perturbant au début, heureusement un exemple de projet sur GitHub montre comment convertir un style guide existant en document Sketch.

Dès que nous avons vu ça, nous nous sommes rapidement mis à le tester et il ne nous a pas fallu beaucoup de temps avant de pouvoir constater des résultats vraiment surprenants.

Test de html-sketchapp

Pour avoir un premier aperçu des possibilités, nous avons commencé par le faire pointer sur la page d’accueil de notre style guide.

Nous avons ensuite généré nos premiers symboles à partir de notre composant Button et de ses différentes variantes de rendu.

Pour parvenir à cela, nous avons décidé d’ajouter un fichier JavaScript à l’intérieur de chaque dossier de composant (par exemple Button.sketch.js), qui indique les symboles que nous souhaitons exporter.

Chaque fichier exporte un objet qui définit les noms des symboles et les éléments React correspondants.

import React from "react";
import Button from "./Button";

export const symbols = {
  "Button/Pink": <Button color="pink">Button</Button>,
  "Button/Blue": <Button color="blue">Button</Button>,
  "Button/Transparent": <Button color="transparent">Button</Button>
};

Nous avons ensuite créé une route masquée spécifique pour le site de notre style guide qui importe tous les fichiers de type .sketch.js et qui effectue le rendu des éléments React fournis à l’écran. De cette manière, nous avons pu simplifier le processus de conversion et exposer tous les contenus pour Sketch sur une seule et même page.

Chaque instance de symbole est encapsulée dans un élément div et son nom est défini dans un attribut data, ce qui nous permet de sélectionner et de nommer facilement tous les symboles présents sur la page.

<div data-sketch-symbol="Button/Pink">
  ...
</div>

Ce patron s’est montré tellement efficace, que nous l’avons ensuite appliqué de sorte à inclure aussi les styles typographiques et les couleurs du document.

Comme notre charte est responsive, nous avons ensuite dû automatiser le redimensionnement du navigateur pour capturer les symboles dans différentes tailles d’écran.

Nous pouvions désormais ajouter, supprimer et renommer différentes tailles de viewport depuis un seul endroit, et chaque symbole était ensuite régénéré pour prendre en compte ces nouvelles valeurs. Tout d’un coup, on aurait dit que nous venions de résoudre une des problématiques les plus fastidieuses liées à la maintenance d’une bibliothèque responsive Sketch.

Si tout se passait étonnamment pour le mieux, nous avons quand même dû faire quelques adaptations spécifiques pour le support de Sketch — de la même manière que vous devez parfois supporter quelques implémentations erronées d’un navigateur — que nous avons pu rassembler dans un seul fichier.

Du test à la production

Ce qui avait démarré comme une expérimentation à petite échelle s’est rapidement transformé quelque chose qui ressemblait à un mini-framework. À ce niveau, il ne restait plus grand-chose à faire pour l’intégrer proprement à notre style guide, pour l’inclure dans notre processus standard de déploiement.

Cependant si vous regardez bien la pull request, vous verrez qu’il nous a fallu ajouter pas mal de code et de dépendances pour relier le tout, même si nous tentions d’effectuer une seule et unique tâche, conceptuellement considérée comme simple à un plus haut niveau.

Pour générer notre bibliothèque Sketch, il nous fallait en passer par les étapes suivantes :

  • Compiler un script pour le navigateur avec webpack, qui contient html-sketchapp et la logique idoine pour pouvoir sélectionner et convertir les éléments.
  • Démarrer un serveur web statique sur un port disponible.
  • Lancer Puppeteer (une version headless de Chromium).
  • Naviguer jusqu’à la bonne URL.
  • Injecter le script compilé dans l’instance Puppeteer en train de tourner.
  • Redimensionner la fenêtre du navigateur plusieurs fois, et prendre des captures pour chaque taille d’écran voulue en appelant les fonctions définies dans notre script compilé.
  • Enregistrer les fichiers JSON générés sur le disque.
  • Éteindre le serveur web statique.
  • Éteindre le navigateur headless.

Il nous paraissait évident que tout cela pourrait être abstrait dans une seule commande — qui nous permette de simplement pointer une URL et de commencer à capturer les composants.

C’est donc ce que nous avons fait.

Voici donc html-sketchapp-cli

Moins d’un mois après avoir commencé à intégrer html-sketchapp dans notre style guide, nous avons ouvert le code source de html-sketchapp-cli, un petit utilitaire en ligne de commande qui vous évite d’avoir à coder tout ça.

Maintenant, nous pouvons parvenir au même résultat en déclarant une seule dépendance dans notre fichier de configuration :

module.exports = {
  serve: "docs/dist",
  url: "/sketch-exports",
  outDir: "dist/asketch",
  viewports: {
    Desktop: "1024x768",
    "Mobile Plus": "414x736",
    Mobile: "320x568"
  }
};

La bonne surprise c’est qu’en utilisant html-sketchapp-cli dans notre style guide, nous avons pu supprimer beaucoup de code.

Un processus de design continu

Tout cet outillage fait désormais partie de notre de recette standard de déploiement continu, et nous permet d’étendre la portée de notre code — au-delà de la seule communauté des développeurs, il aide les designers dans leur travail quotidien.

À chaque génération réussie de notre style guide — non seulement nous déployons automatiquement notre site sur GitHub Pages (à l’aide de gh-pages) et nous publions la bibliothèque de composants sur npm (à l’aide du paquet semantic-release) — mais nous générons automatiquement les fichiers asketch, prêts à être importés et à être convertis dans notre bibliothèque Sketch officielle.

Cette librairie Sketch est ensuite distribuée via un disque partagé de notre équipe de designers, ce qui veut dire que nos designers ont en permanence une copie à jour de la bibliothèque, qui se synchronise en temps réel, même quand Sketch est ouvert.

Grâce au support natif des bibliothèques dans Sketch, les designers peuvent ouvrir le menu « Bibliothèque de Style Guide de SEEK » et commencer à sélectionner les composants, en sachant que les conventions de nommage et les styles visuels respectent les attentes des développeurs dans leurs équipes.

Depuis cette adoption, nous avons commencé à voir des changements continus dans notre code se propager dans Sketch — même si parfois les personnes qui font ces changements n’ont même pas Sketch d’installé sur leur machine. Puisque notre style guide est connecté à nos applications en production, il est constamment amélioré par tout un tas de personnes dans nos équipes, et nous pouvons maintenant être sûrs que tous ces changements mettent bien à jour notre bibliothèque Sketch.

Même si nous continuons de travailler sur différents formats et médias, nous mettons tout en œuvre pour créer l’illusion de tous parler une même langue.

Et maintenant ?

Aussi génial puisse être ce développement pour nous, nous le considérons toujours comme une solution temporaire. Effectuer le rendu de contenus web dans Sketch s’avère incroyablement puissant, et c’est une nouvelle étape obligatoire de notre quête, mais notre industrie doit encore aller plus loin.

Les frontières entre nos différents médias sont peut-être un peu plus floues, mais les outils de design futurs devront supprimer cette frontière pour de bon. Pour que nous puissions vraiment libérer son potentiel, nous avons besoin d’outils de conception qui ne se contentent pas d’imiter le médium ciblé, nous avons besoin qu’ils soient bâtis avec.

Heureusement, il y a beaucoup de gens qui travaillent sur ce problème actuellement. Des outils comme Compositor, Interplay, Alva, Haiku, Webflow et UXPin cherchent à faire tomber les murs techniques entre les outils de design et le code final, et d’autres outils du même genre continuent d’arriver.

Qui sait, nous pourrions même commencer à voir des outils de conception plus traditionnels adopter cette approche pour rester à la page, particulièrement quand les design systems font partie de la palette standard d’outils de conception moderne.

En attendant de nouveaux outils de conception qui embrassent véritablement l’époque actuelle des principes qui régissent les design systems, des projets comme react-sketchapp and html-sketchapp font un travail incroyable pour nous préparer à cette façon de penser dès à présent.

Honnêtement, il n’y a jamais eu un meilleur moment pour s’y mettre.