jan. 2015

Design atomique et design de styleguides

UX designer de formation, j’interviens depuis quelques temps sur de plus en plus de projets dans un rôle plus en aval d’intégration front-end. En plus de perfectionner une certaine approche technique du design, cela me permet de cerner plus précisément certaines difficultés actuelles du processus “classique”, s’il en est, de fabrication d’un projet web, de sa conception à son développement. L’importance qu’accorde Escale à l’optimisation constante de ce processus me permet de porter un regard réflexif sur mon propre travail, et de proposer ici une manière de le faciliter intelligemment. Faute de temps et d’espace pour détailler l’ensemble d’un protocole de travail précis, je me contenterai de libérer ici quelques idées que j’ai en tête, en proposant des liens que j’ai pu parcourir.

Le problème

Le problème vient sans doute d’un manque de vocabulaire et de rationalisation communs entre le design et le développement, quand bien même leurs processus respectifs pourraient ne pas être si différents que ça.

D’un point de vue design, le processus classique consiste généralement à produire une maquette avec une dimension fixe, qui sera transmise ensuite au développeur qui l’intégrera. Le soucis ici est souligné par Brad Frost : le site web est encore aujourd’hui pensé sur le modèle du livre dans lequel prédomine le concept de page. Or, dans un monde numérique aussi protéiforme et aux formats d’écrans aussi variés, ce modèle ne tient tout simplement plus. Il faut donc réfléchir à un processus de design plus flexible que le processus fondé sur le modèle de la page et sur le concept de pixel perfect.

Un monde protéiforme. Un monde protéiforme. Source de l’image : http://www.smashingmagazine.com/

D’un point de vue développement, l’intégrateur reçoit généralement la maquette du designer représentant une page, il en décrit sa logique et sa structure en HTML puis ajoute page par page son code CSS jusqu’à ce que la page ressemble à la maquette. Une des conséquences de processus est que plus le projet grossit, plus le CSS devient complexe à lire et à comprendre, et plus il devient donc difficilement maintenable.

Le problème est ainsi de trouver un vocabulaire commun entre designer et développeur afin de concevoir systématiquement des systèmes complexes flexibles en format (Responsive Web Design) et en profondeur (correspondant à la taille du site).

Atomic Design

Partant du premier constat, Brad Frost s’est posé la question de savoir, finalement, de quoi une interface était faite. Reprenant la métaphore de la chimie, il observa que si le monde, dans sa complexité, n’était finalement fait que de multiples atomes réunis en molécules et organismes, peu importe sa forme (liquide, solide, gazeux), les interfaces elles-aussi avaient leurs éléments de base, leurs propres atomes et molécules.

Le web est lui-aussi intrinsèquement chimique. Josh Duck a d’ailleurs proposé un tableau périodique des éléments HTML :

Le tableau périodique des éléments Le tableau périodique des éléments : les gazs nobles sont des éléments de table, les alcalins des métadonnées, etc.

Brad Frost propose donc une approche des interfaces en les décomposant. Ou plutôt l’inverse, en les composant à partir de leurs plus simples composants. Et il nomme cette approche le “design atomique”.

Les éléments du design atomique Les éléments du design atomique

Alors que son approche distingue 5 niveaux de composants, je préfère pour simplifier encore le processus de conception me limiter à seulement 3 niveaux.

L’atome est l’élément le plus basique d’un système. Comme nous le montre la table des éléments, il s’agit principalement des tag html. Par exemple ci-dessous : label, input et button. On pourrait également considérer l’icône elle-même comme un atome. Ca peut-être aussi une couleur, une police ou même un type d’animation spécifique par exemple.

Des atomes du web Des atomes du web

La molécule va ensuite correspondre à l’assemblage de plusieurs atomes, ou même de plusieurs molécules entre elles. Bien souvent le regroupement d’atomes permet d’apporter du sens : dans l’exemple ci-dessous, une barre de recherche.

Une molécule de recherche Une molécule de recherche

L’organisme enfin est l’assemblage de plusieurs molécules entre elles. On pourra donc trouver des organismes plus ou moins complexes.

Un organisme vivant sur Internet Un organisme vivant sur Internet

Chaque site web peut ainsi être décomposé en ses divers organismes, en ses molécules, et plus profondément encore en ses divers atomes, de telle sorte que nous pouvons nous rendre compte que nous designons d’ores-et-déjà des composants que nous assemblons au fur et à mesure que nous les créons.

Le design atomique donne donc à voir un processus de conception qui n’est pas radicalement différent du processus de conception traditionnel, mais qui diffère au moins dans sa manière d’assembler les composants et de penser les interfaces. Ayant ouvert les yeux sur ces atomes, molécules et organismes de nos projets web, désormais nous pouvons considérer que, pour reprendre les mots de Stephen Hay (cf lien de Brad Frost), nous ne designons plus des pages webs, mais des systèmes de composants. Ce qui change finalement à peu près tout.

Des liens :

Le styleguide au coeur du processus de conception d’un système complexe

Nous concevons donc désormais des systèmes complexes de composants, et l’élément central du design atomique n’est plus la page elle-même, mais le composant. Pour revenir à notre problème, d’un point de vue design, l’interface devient une liste de composants qui n’ont plus des positions fixées au préalable au pixel près ; d’un point de vue développement, l’ajout d’une nouvelle page n’est que la réutilisation de composants déjà créés ou la création d’un composant manquant.

Le concept de composant devient ainsi le coeur d’un vocabulaire que peuvent partager designers et développeurs. Le styleguide, lieu qui réunit tous les composants d’un projet, devient lui la grammaire même du système. Il devient le point de référence du développeur et du designer, mais également du client et du chef de projet en ce qu’il est aussi un vocabulaire donnant du sens et un visuel à l’identité du projet. En ce sens, en concevant ce vocabulaire, l’agence web participe véritablement à la stratégie de communication d’un client sur le web, et le site reprend sa place de “simple” outil.

Chaque membre de l’équipe peut recomposer sa place en fonction de cette approche en styleguide :

  • L’architecte de l’information travaille l’arborescence du site et des contenus et sur les différents process et parcours utilisateur, en déduit une liste de composants nécessaires aux différentes interactions et à la présentation de l’information, puis compose ses zonings et wireframes. La liste de composants sera la base du styleguide.
  • Le designer UI reprend cette liste de composants afin de les “habiller” et de leur donner l’identité graphique du projet, puis compose différentes vues à l’aide de ces composants. Ces derniers lui permettent par ailleurs d’assurer une certaine cohérence entre les vues (les mêmes composants sont utilisés) mais aussi entre les composants eux-mêmes (tous visibles ensemble sur le styleguide). L’utilisation de composants pour l’UI designer est d’autant plus intéressant pour lui que 1) cela correspond à la logique des objets dynamiques sous Photoshop, ces composants uniques réutilisables sur différents fichiers et que 2) par ailleurs il ne peut jamais maquetter toutes les vues, surtout sur les sites complexes, mais il peut en revanche maquetter tous les composants du styleguide qui composeront le système.
  • Le chef de projet pourra quant à lui s’appuyer sur ce styleguide “habillé” pour faire une proposition de vocabulaire au client et recevoir ses feedbacks.
  • Le développeur enfin verra son workflow rationalisé puisque, d’une part en intégrant dans un même lieu tous les composants du système, il peut identifier plus rapidement des problèmes éventuels ou même tester tout aussi rapidement ses composants ; et puisque d’autre part, une fois les composants du styleguide intégrés un par un, il n’aura plus qu’à les importer dans les vues respectives, comme des Legos.

Le styleguide au coeur du processus Le styleguide au coeur du processus

Tous les membres de l’équipe travaillent donc sur la même base, sur le même vocabulaire, et à partir du même document de référence qu’ils font chacun évoluer selon leur spécialisation. N’importe quel nouvel entrant dans le projet verra son insertion facilitée par ce document central de référence qui permettra par ailleurs au projet de gagner en test (on l’a souligné, les composants sont rapidement intégrés au même endroit, ce qui optimise l’identification de problème) et en scalabilité (il s’agira d’ajouter un nouveau composant dans le styleguide).

Des liens :

Les web components

L’approche atomique que propose Brad Frost et que nous avons développée avec les styleguides ici semble par ailleurs s’inscrire dans la logique de l’évolution du web, et en particulier des web components.

Les web components sont des éléments HTML embarquant leurs propres CSS et Javascript afin d’avoir nativement un rendu et un comportement uniformes lors de leurs utilisations dans une page ou une application web. C’est-à-dire que ce sont des éléments autonomes qui embarquent leur propre logique, leur propre style et leur propre comportement.

Un web component est assez similaire à la logique des atomes, molécules et organismes, et peut aller d’un simple bouton à un widget complet en passant par un élément non-visuel (comme une connexion AJAX).

Il est intéressant ici de s’attarder sur la conception des web components pour mieux comprendre leur logique et leur intérêt dans l’approche par styleguide.

Avec le projet Polymer de Google, un web component se structure ainsi :

<polymer-element name="" attributes="">
  <template>
  <!-- style -->
  <!-- structre html -->
  </template>
  <script>
  //behavior
  </script>
</polymer-element>

On voit ainsi que le style, la structure et le comportement se trouvent tous les trois définis dans le même document, et sont encapsulés dans un seul et même “polymer element”.

Si l’on prend l’exemple d’un bouton créé avec Polymer et récupéré sur github (https://github.com/Urucas/button-spring), on obtient ceci :

<link rel="import" href="../bower_components/polymer/polymer.html">
<script src="../bower_components/jquery/dist/jquery.min.js"></script>
<script src="../bower_components/impulse/impulse.min.js"></script>

<polymer-element name="button-spring" attributes="id class onclick value scale tension damping">
  <template>
    <style>
    .button-spring {
      color:#529690;
      background: #7bc6bf;
      border:none;
      padding: 12px 35px;
      cursor:pointer;
    }
    </style>
    <button id="{{id}}" class="button-spring {{class}}" onclick="{{onclick}}">{{value}}</button>
  </template>
  <script>
    Polymer('button-spring', {
      scale: 0.8,
      tension: 100,
      damping: 10,
      ready: function() {
        var obj = this.$;
        var el = obj[this.id];
        var ball = Impulse(el).style('scale', function(scale) { return scale });
        var scale = this.scale;
        var tension = this.tension;
        var damping = this.damping;
        el.addEventListener('click', function(){
          ball.spring({ tension: tension, damping: damping }).from(scale, scale).to(1, 1).start();
        }, false);
      }
    });
  </script>
</polymer-element>

Sans entrer dans le détail, on voit que le HTML, le CSS et le Javascript sont définis de la même manière. On notera notamment le nom défini dans l’attribut “name”, les librairies qui sont chargées en dehors de l’élément (donc un élément utilisant jQuery n’a pas forcément besoin de l’embarquer, donc jQuery n’est pas chargé plusieurs fois si plusieurs composants l’utilisent), ainsi que les différents attributs dans l’élément qui permettent de créer des variations entre des mêmes composants (comportements différents au click, classes différentes, labels différents, etc.).

Une fois le web component créé, il ne reste plus qu’à l’utiliser :

<!DOCTYPE html>
<html>
  <head>
    <script src="/bower_components/platform/platform.js"></script>
    <link rel="import" href="/elements/button-spring.html">
  </head>
  <body>
    <button-spring
      class="myButton"
      value="Aceptar"
      onclick="console.log('button-spring pressed')">
    </button-spring>
  </body>
<html>

On déclare la bibliothèque permettant d’utiliser les web components, puis on importe notre composant afin qu’il soit parsé. On déclare enfin ce dernier par son nom directement dans le html, en renseignant les attributs nécessaires. Et voilà notre élément créé :

Notre bouton en web component Notre bouton en web component

Ici l’exemple est sans doute simple, et à la limite stupide : il n’y a pas forcément besoin de créer un web component pour un simple bouton, ce qui montre d’ailleurs une des limites actuelles de leur utilisation. Mais l’exemple permet néanmoins d’illustrer combien la réflexion derrière les web components est proche de l’approche du design atomique et des styleguides : il s’agit d’abord de définir nos composants indépendemment les uns des autres, puis de les importer et de les utiliser dans nos différentes vues. Celles-ci deviennent alors plus lisibles, par exemple pour une page d’accueil du site d’une agence web, on pourrait obtenir ceci, qui est sans doute un cas extrême :

<!DOCTYPE html>
<body>
  <agency-header></agency-header>
  <agency-cover></agency-cover>
  <agency-skills></agency-skills>
  <agency-methodology></agency-methodology>
  <agency-client></agency-client>
  <agency-footer></agency-footer>
</body>

Les web components ont ainsi de nombreux avantages, notamment leur modularité, leur simplicité d’utilisation, leur simplicité de lecture, leur personnalisation. Mais ils posent encore des problèmes de performance (pas de support pour les anciens navigateurs), d’accessibilité ou ne sont pas encore utilisés de manière optimale (on trouve ainsi sur github des exemples de composants trop simples comme des boutons, ou à l’inverse trop compliqués comme une application entière).

Des liens :

L’approche en styleguide permet ainsi une rationalisation du processus qui bénéficie à la fois aux designers et aux développeurs, et pas seulement. Elle permet de sortir du modèle de la page pour se concentrer sur la construction de systèmes complexes de composants. Elle propose, avant de créer ce système, de designer et concevoir son propre vocabulaire, c’est-à-dire finalement de concevoir le framework permettant de construire rationnellement un projet, comme s’il s’agissait de concevoir un petit bootstrap pour chaque projet. En cela, la conception gagne en simplicité, en modularité, en optimisation du travail d’équipe, et s’inscrit dans l’évolution du web et des web components.

Dans une conférence qu’il a tenu récemment à Nantes, Federico Hodalgo, un des UX designer de Mail chimp, s’appuyait pour son approche sur des référence aux processus de design des voitures, des bateaux et des bâtiments (mais également sur une lecture de “Refabricating Architecture” de Stephen Kieran et James Timberlake). Le maître mot de ces processus était la modularité : les composants sont faits dans des lieux différents et spécialisés puis assemblés, ce qui accélère la productivité de chacun. Federico Hodalgo expliquait ainsi que pour le redesign de Mail Chimp, un styleguide simple avait été défini (typographie, espacement, couleur). Ayant ce vocabulaire de base commun, l’équipe avait pu se diviser pour concevoir chacun de leur côté, en parallèle, les différents composants du site, qui avait ainsi pu être terminé dans un temps exceptionnellement court. Sa présentation est disponible en ligne. Il y a sans doute encore beaucoup de leçon à retenir du design industriel. Nous n’en sommes pas encore là, mais ce type d’approche pourrait être une direction pour le desig atomique et le design de styleguides.

Dans le prolongement de ce billet, vous pourrez trouver sur mon github un “styleguide starter kit” permettant de commencer n’importe quel projet avec des outils déjà installés (Bootstrap, Less, Respond.js et html5shiv) ainsi qu’un styleguide avec des composants déjà intégrés. Vous trouverez par ailleurs sur codepen l’expérimentation d’une triangulation animée effectuée en Polymer à partir d’une triangulation effectuée avec des fichiers séparés.