Faire le pont entre designers et développeurs avec Sass au Guardian
•
7 j'aime•6,398 vues
**31 Octobre 2014** : Présentation mise à jour pour la conférence Blend Web Mix disponibles sur http://www.slideshare.net/kaelig/faire-le-pont-entre-designers-et-developpeurs-au-guardian Les pré-processeurs CSS sont d’excellents outils pour les développeurs. Au Guardian nous sommes allés plus loin, procurant un réel bénéfice au niveau de la communication en utilisant les variables et mixins Sass comme socle pour un vocabulaire et des concepts communs partagés entre développeurs et designers. Présentation donnée en tant qu'invité d'honneur à la KiwiParty (http://kiwiparty.fr/) le vendredi 13 juin 2014.
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à Faire le pont entre designers et développeurs avec Sass au Guardian
Similaire à Faire le pont entre designers et développeurs avec Sass au Guardian (20)
Plus de Kaelig Deloumeau-Prigent
Plus de Kaelig Deloumeau-Prigent (11)
Faire le pont entre designers et développeurs avec Sass au Guardian
- 1. Faire le pont entre les développeurs et les designers au Guardian @kaelig
- 2. À qui s’adresse cette conférence ? @kaelig
- 3. À qui s’adresse cette conférence ? Ceux qui écrivent du code @kaelig
- 4. À qui s’adresse cette conférence ? Ceux qui écrivent du code Ceux qui n’en écrivent pas @kaelig
- 5. À qui s’adresse cette conférence ? Ceux qui écrivent du code Ceux qui n’en écrivent pas Ceux qui savent ce qu’est un préprocesseur CSS @kaelig
- 6. À qui s’adresse cette conférence ? Ceux qui écrivent du code Ceux qui n’en écrivent pas Ceux qui savent ce qu’est un préprocesseur CSS Ceux qui n’en ont jamais entendu parler @kaelig
- 7. Mars Climate Orbiter 23 septembre 1999 @kaelig
- 11. 57 contributeurs github.com/guardian/frontend ~25 ingénieurs touchent à HTML/CSS @kaelig
- 12. 57 contributeurs github.com/guardian/frontend ~25 ingénieurs touchent à HTML/CSS ~16 000 lignes de CSS @kaelig
- 13. 57 contributeurs github.com/guardian/frontend ~25 ingénieurs touchent à HTML/CSS ~16 000 lignes de CSS 100 millions de visiteurs uniques par mois @kaelig
- 14. 57 contributeurs github.com/guardian/frontend ~25 ingénieurs touchent à HTML/CSS ~16 000 lignes de CSS 100 millions de visiteurs uniques par mois cycle de déploiement : ~4 fois par jour @kaelig
- 15. @kaelig
- 16. Idée @kaelig
- 17. Idée @kaelig
- 22. Mesure en temps réel @kaelig
- 27. La couleur du titre de l’article est “gris clair”. @kaelig
- 28. @kaelig
- 31. Ce que tu as appris @kaelig
- 32. Ce que tu as appris • Le code est un outil de communication (ici : via les variables) @kaelig
- 33. Ce que tu as appris • Le code est un outil de communication (ici : via les variables) • Un pré-processeur aide à éviter les copier-coller @kaelig
- 35. sass-mq • Abstraction des @media queries réutilisable • Un breakpoint est appelé par son nom au lieu d’une mesure github.io/sass-mq @kaelig
- 36. CSS .header {! ! background: blue;! }! @media all and (min-width: 37.5em) {! ! .header {! ! ! background: transparent;! ! }! } sass-mq : exemple Sass .header {! ! background: blue;! ! ! @include mq($from: tablet) {! ! ! background: transparent;! ! }! }
- 37. sass-mq : exemple Sass CSS .header {! ! background: blue;! ! ! @include mq($from: tablet) {! ! ! background: transparent;! ! }! } .header {! ! background: blue;! }! @media all and (min-width: 37.5em) {! ! .header {! ! ! background: transparent;! ! }! }
- 38. Nommer ses breakpoints $mq-breakpoints: (! mobile: 320px,! tablet: 740px,! desktop: 980px,! wide: 1300px! );! @kaelig
- 39. Nommer ses breakpoints mobile vs S tablet vs M desktop vs L wide vs XL @kaelig
- 40. Ce que tu as appris @kaelig
- 41. Ce que tu as appris • Les choses complexes techniquement peuvent être rendues simples dans le code @kaelig
- 42. Ce que tu as appris • Les choses complexes techniquement peuvent être rendues simples dans le code • Coder des petits outils fait gagner en temps de conception, de maintenabilité, et en clarté @kaelig
- 46. 4 à 16 colonnes de 60px Gouttière : 20px Marges externes : < 480px: 10px > 480px: 20px
- 47. Une colonne, une gouttière… Ça fait combien en pixels ? @kaelig
- 49. Baser ses breakpoints sur la grille @kaelig
- 50. // Article breakpoints! $a-rightCol-width: gs-span(4);! $a-rightCol-trigger: gs-span(11) + $gs-gutter*2; // 900px! $a-leftCol-width: gs-span(2); // Grows to 3 columns on wide viewports! $a-leftCol-trigger: gs-span(13) + $gs-gutter*2; // 1060px! $a-leftColWide-width: gs-span(3);! ! // Facia breakpoints! $facia-leftCol-trigger: gs-span(14) + $gs-gutter*2; // 1140px! ! $mq-breakpoints: (! mobile: gs-span(4) + $gs-gutter, // 320px! tablet: gs-span(9) + $gs-gutter*2, // 740px! desktop: gs-span(12) + $gs-gutter*2, // 980px! wide: gs-span(16) + $gs-gutter*2, // 1300px! ! // Tweakpoints! mobileLandscape: gs-span(6) + $gs-gutter, // 480px! desktopAd: 810px,! ! // Article layout! rightCol: $a-rightCol-trigger,! leftCol: $a-leftCol-trigger,! ! // Facia layout! faciaLeftCol: $facia-leftCol-trigger! );! @kaelig
- 51. Ce que tu as appris @kaelig
- 52. Ce que tu as appris • Le code peut (doit) faire des maths à ta place @kaelig
- 53. Ce que tu as appris • Le code peut (doit) faire des maths à ta place • Tu peux mixer différents composants du système de design (ici la grille et les breakpoints) @kaelig
- 55. 14px/18px normal 14px/18px normal 14px/18px normal 14px/18px normal 14px/18px normal 14px/18px normal 14px/18px normal 20px/24px normal20px/24px normal 32px/36px normal 32px/36px normal text sans 12px/16px text sans 12px/16px text sans 12px/16pxtext sans 12px/16px 20px/24px normal 20px/28px bolder
- 56. ? ? ? @kaelig
- 58. CSS .element {! font-size: 16px;! font-size: 1.6rem;! line-height: 20px;! line-height: 2rem;! font-family: "EgyptianHeadline", georgia, serif;! font-weight: 900;! } échelle typographique : exemple Sass .element {! @include fs-header(1);! }
- 59. CSS .element {! font-size: 16px;! font-size: 1.6rem;! line-height: 20px;! line-height: 2rem;! font-family: "EgyptianHeadline", georgia, serif;! font-weight: 900;! } échelle typographique : exemple Sass .element {! @include fs-header(1);! }
- 60. 14px/18px normal 14px/18px normal 14px/18px normal 14px/18px normal 14px/18px normal 14px/18px normal 14px/18px normal 20px/24px normal20px/24px normal 32px/36px normal 32px/36px normal text sans 12px/16px text sans 12px/16px text sans 12px/16pxtext sans 12px/16px 20px/24px normal 20px/28px bolder
- 61. Headline 4 Headline 4 Headline 1 Headline 1 Headline 2 Headline 2 Headline 1 Headline 1 Data 1 Data 1 Data 1 Data 1 Headline 1 Headline 1 Page Header 3 Headline 1 Headline 2
- 62. Ce que tu as appris @kaelig
- 63. Ce que tu as appris • Lorsqu’aucune convention de nommage est en place, on peut en inventer une tous ensemble @kaelig
- 64. Ce que tu as appris • Lorsqu’aucune convention de nommage est en place, on peut en inventer une tous ensemble • Mettre en place des valeurs par défaut dans le code peut améliorer la cohérence du design @kaelig
- 65. 3 colonnes par défaut et 7 colonnes sur écrans d’ordinateurs .element { width: 220px; } @media (min-width: 56.25em) { .element { width: 540px; } }
- 66. 3 colonnes par défaut et 7 colonnes sur écrans d’ordinateurs .element { width: 220px; } @media (min-width: 56.25em) { .element { width: 540px; } } .element { width: gs-span(3); ! @include mq(desktop) { width: gs-span(7); } }
- 69. @kaelig
- 71. Bénéfices : Code + communicatif @kaelig
- 72. Bénéfices : Code + communicatif Abstraire le code compliqué @kaelig
- 73. Faites le pont entre les designers et les développeurs Crédits: Mars Climate Orbiter 2 — By NASA/JPL/Corby Waste [Public domain], via Wikimedia Commons — http://commons.wikimedia.org/wiki/ File%3AMars_Climate_Orbiter_2.jpg Hipster — Cámara espía — https://flic.kr/p/cXMuEd Mug — slavik_V — https://flic.kr/p/9WgM9D swiss style grid sample — Filipe Varela — https://flic.kr/p/4xLDb1 Gene Wilburn — A Splash of Colour — https://flic.kr/p/5VK8kv Glasses designed by Okan Benn from the Noun Project Document designed by Jamison Wieser from the Noun Project @kaelig
Notes de l'éditeur
- Le 23 septembre 1999, la sonde Mars Climate Orbiter est détruite lors de son entrée dans l’atmosphère martienne. Lors du calcul de la descente de la sonde dans l’atmosphere, ils ont fait un mix entre les pouces et les centimètres sans s’en rendre compte, avec les résultats que vous savez. Dans l’histoire, on ne peut pas vraiment parler d’erreur de calcul, puisque tous les ingénieurs avaient raison… à leur manière. Ce que cette histoire montre en revanche, c’est que de travailler sur un meme projet avec différents référentiels peut avoir des conséquences *plutôt* désastreuses.
- Je suis développeur sur le nouveau site du Guardian, un journal anglais dont vous avez peut-être entendu parler rapport aux histoires sur la vie privée et la NSA, sur lequel je travaille avec des designers, des journalistes, et de nombreux autres rôles qui vont parler des langages différents, un peu comme nos scientifiques de la NASA parlaient en pouces et en centimetres. Aujourd’hui si vous le voulez bien, j’aimerais qu’on voie comment on a réussi à adopter un langage commun entre les développeurs et les designers.
- Pour commencer, un aperçu du projet L’entièreté du site est disponible sur GitHub en open-source. On y compte 57 contributeurs. Environ la moitié des contributeurs est amenée à toucher à HTML et CSS, avec des niveaux d’expertise très variables. Notre base de code CSS est relativement grosse. On y compte environ 16000 lignes de code et cela grandit au fur et à mesure que nous ajoutons des fonctionnalités. Et nous déployons une nouvelle version du site à peu près 4 fois par jour
- Quand je dis qu’on déploie environ 4 fois par jour ou plus, en fait on déploie surtout des micro changements tout au long de la journée. Voilà comment ça se passe : on part d’une idée ou d’une hypothèse, comme par exemple en ce moment, “si on change la navigation comme ci ou comme ça, on pense que les utilisateurs vont découvrir davantage de news dans les sous-sections du site” et on va produire un ou plusieurs prototypes de cette idée. Ensuite pour tester si cette idée fonctionne ou pas, on teste le prototype auprès de nos utilisateurs, et on mesure leur réaction.
- Et on va recommencer ce process encore et encore en continuant à améliorer l’idée, ou bien on va la garder, ou bien finalement il arrive qu’on la jette à la poubelle parce qu’elle n’aura pas su prouver sa valeur lors de nos tests.
- Pour vérifier comment nos utilisateurs répondent au changement, on a pas mal d’outils accessibles à n’importe qui qui travaille au Guardian. Là par exemple on a une courbe qui mesure l’impact de nos changements sur la performance de chargement, et sur le nombre de pages vues.
- On va aussi faire beaucoup de tests avec plusieurs variantes. On a mis au point des outils faits maison pour mesurer des choses comme l’engagement, le nombre de pages vues, le nombre de clicks, les articles lus, etc. On a aussi des sondages en ligne, un labo pour tester l’utilisabilité de nos concepts, et des spécialistes des statistiques qui vont faire des analyses bien plus poussées dans certains cas. Donc vous imaginez bien que pour mettre en ligne nos idées le plus rapidement possible, on va devoir communiquer ultra efficacement entre designers, chefs de produit… et bien sûr développeurs vu que le livrable final, c’est du code en production.
- En parlant de développeurs, ils vont se servir d’un tas d’outils et de méthodes pour coder, tester, mettre en ligne, etc. Alors vous inquiétez pas, aujourd’hui je ne vous embêterai pas avec tous ces frameworks et langages !
- Je vais juste te parler un peu de Sass. T’inquiéte pas ca sera vraiment pas très technique. Si tu veux parler de la technique hésite surtout pas à venir me voir à l’after.
- Sass est un pré-processeur CSS, donc un programme qui ajoute des fonctionnalités à CSS comme les conditions if/else, les variables, les sélecteurs imbriqués les fonctions, de la manipulation de nombres, comme des additions, soustractions, multiplications, divisions… et plein d’autres trucs super cool. Aujourd’hui j’aimerai vous montrer à quoi peut nous servir d’avoir un langage plus élaboré que le langage CSS de base.
- Parlons de couleurs. Lorsqu’un designer communique une couleur, quel est son référentiel ? Sur quel système se base-t-il ? Dans le code, les couleurs sont généralement représentées sous forme de code hexadécimal ou RVB. On ne peut pas dire que c’est la manière la plus naturelle de communiquer une couleur. On a souvent eu le cas où un designer disait “faut que ce texte soit noir” quand en fait on n’a pas de noir pur dans notre charte. Si un développeur pouvait revenir vers le designer et lui dire “ah attends la couleur que tu m’as donnée n’existe pas dans la palette, est-ce que tu es sûr que c’est bien ça ?” Du coup on pourrait corriger et éviter la prolifération de couleurs.
- On a utilisé Sass pour représenter notre palette sous forme de variables directement au coeur du code source. On a nommé nos variables comme dans le langage couramment utilisé par les designers, donc ca colle à la “charte” de couleurs du Guardian et quand un designer me dit “couleur sport dark” c’est facile pour moi de l’écrire dans le code puisque j’ai justement une variable Sass qui s’appelle sport dark. Transformer des couleurs en variables, c’est l’étape la plus naturelle et la plus simple d’utilisation d’un pré-processeur et bientôt des custom properties en CSS. Je te conseille de le faire parce que ça aussi va t’éviter un max de copier-coller !
- Et alors du coup j’ai crée un dépot GitHub accessible à tout le monde qui contient toutes les couleurs qu’on utilise sur nos produits numériques. D’autres équipes peuvent s’y référer, et le résultat c’est que l’on va pouvoir utiliser les mêmes couleurs dans les applications et les différents sites. Pour les utilisateurs c’est top parce qu’ils ont une expérience plus cohérente en passant du papier au site mobile ou à l’application mobile. Encore une fois c’est complètement open source, vous pourrez trouver cette palette et le code à l’url affichée en bas de l’écran.
- Comme c’est un projet responsive, on fait appel aux @media queries pour adapter notre contenu à des périphériques de toutes tailles. Comme nous en a parlé Julien ce matin, on va justement pouvoir utiliser un préprocesseur CSS pour gérer nos media queries.
- J’ai créé un mixin Sass, c’est à dire une abstraction qui va prendre des instructions Sass en entrée et les transformer en media queries CSS en sortie. Ça s’appelle sass-mq et c’est disponible sur GitHub. On l’utilise au Guardian sur plusieurs projets et d’autres gens en dehors s’en servent aussi, donc n’hésitez pas à le télécharger pour faire la même chose que ce que je vais vous montrer.
- Alors ici on dit à notre header d’avoir un fond bleu. Puis avec une syntaxe propre au mixin sass-mq, on lui dit ensuite d’avoir un fond transparent pour les périphériques au moins aussi larges qu’une tablette.
- Sass va déchiffrer ces instructions et les compiler en CSS. On a donc codé quelque chose qui ressemble pas mal au langage que l’on parle entre designers et développeurs, sauf que c’est Sass qui s’occupe de faire la conversion vers un langage machine. http://sassmeister.com/gist/11261517
- Alors dans l’exemple précédent je parlais du breakpoint “tablet”. Dans cette slide vous pouvez voir la configuration qu’on renseigne pour dire à sass-mq quels breakpoints on va utiliser, et oh magie : tu y retrouves le breakpoint pour tablettes. Ça ressemble à une configuration JSON clé-valeur, sauf que c’est du Sass. À gauche on a les noms des points de rupture et à droite la largeur en pixels correspondante. C’est super explicite et facile à changer. Si demain tu décides que ton breakpoint mobile devrait être de 240 pixels, tu as juste à le changer dans cette configuration et toutes les media queries du site seront mises à jour lors de la compilation de Sass vers CSS.
- C’est pas facile de nommer ses breakpoints car d’un point de vue philosophique tu veux être le plus agnostique possible. Par exemple tu pourrais appeler les breakpoints principaux S, M, L, XL, XXL etc. Mais d’un point de vue pratique tu vas sans doute galérer dans la vraie vie car personne d’autre que toi utilisera des tailles de T-Shirt pour parler de breakpoints. En gros le challenge c’est de trouver quelque chose qui marche pour toi et aussi pour ton équipe. Pour nous c’était plus simple de nommer nos points de rupture avec des noms qui nous sont venus naturellement. Donc mobile, tablet, desktop et wide.
- Parlons de la grille de mise en page ! Une grille de mise en page est un canevas sur lequel vont se fixer les éléments du design. C’est une série de guides sur les axes horizontaux et verticaux, qui va permettre une distribution visuelle cohérente entre les éléments. On hérite ces principes du monde de l’édition papier, où les grilles de mise en page ont une importance capitale pour la lisibilité et la compréhension des contenus.
- Malheureusement, notre code à la base, il sait pas ce qu’on entend par “colonne” ni “gouttière”.
- Ce que j’ai fait, c’est une simple documentation de ces mesures que j’ai assigné à des variables Sass. N’importe qui peut comprendre de quoi il s’agit et au final on n’a plus besoin de se poser la question du nombre de pixels que doit faire un objet : c’est le nombre de colonnes qui compte. Enfin pour les marges on va utiliser la baseline et la gouttière comme unités.
- Je t’ai pas vraiment raconté toute l’histoire… en fait on a basé nos breakpoints sur la grille directement; laisse moi te montrer.
- Ici tu vois le contenu notre fichier de configuration de sass-mq de nos points de rupture majeurs et mineurs se base sur notre système de grille. Par exemple, notre breakpoint mobile est équivalent à 4 colonnes, et notre breakpoint pour tablettes équivaut à 9 colonnes. Ce qui est top c’est qu’on ne se base donc plus sur des largeur standard dans l’industrie, mais directement sur notre contenu et notre système de design.
- Parlons de typographie. Voici la maquette de la page d’accueil, on y trouve de nombreuses tailles, graisses, polices. Ça devient compliqué de s’y retrouver surtout que les designers ont des noms pour les polices dans photoshop, et les développeurs d’autres noms dans les CSS…
- On va charger de nombreuses webfonts mais celles-ci ont un nom dans notre CSS complètement différent des aux noms des typos installées sur les postes des graphistes. Et les fichiers webfonts eux-mêmes ont des noms un peu bizarres qui ont pas grand chose à voir avec le reste.
- Donc vu qu’il était assez compliqué de changer les conventions sur toute la chaine de fabrication du côté des designers comme des développeurs, on a mis au point une matrice qui référence tous ces noms en différents langages. En haut de la matrice, tu le nom qu’on va utiliser lorsqu’on parle ensemble. Et en dessous, le nom de la police dans CSS, son nom dans Sass et son nom dans les logiciels de graphisme. On a aussi une échelle typographique qui définit des tailles de polices. Que je sois développeur ou designer, je peux m’y référer pour savoir à quoi le langage commun correspond dans le code ou dans Photoshop. Au final on parle tous le même langage.
- Par exemple ici un designer me dit que mon element devrait être un header 1.
- Sass va déchiffrer ces instructions et les compiler en CSS, avec le bon nom de typo, la taille qui convient, la graisse qui va bien et en bonus, des bonnes pratiques de rétro-compatibilité sont automatiquement appliquées pour avoir un fallback en pixels si le navigateur ne comprend pas les valeurs en rem.
- La page que vous avez vu tout à l’heure, mais en y appliquant la matrice, devient un document que l’on peut décrire et dont on peut discuter bien plus facilement. Et surtout : d’un composant d’interface à l’autre, on est sûr que le rendu, la taille du texte et la typographie sont strictement les mêmes. Ça uniformise le code comme le design. http://sassmeister.com/gist/40e5e899a40ca0406803
- Je suis designer, je veux indiquer au développeur que la largeur d’un élément est de 3 colonnes par défaut et 7 colonnes sur écrans d’ordinateurs en se basant sur la grille de mise en page. Maintenant, je suis le développeur. Je vais devoir connaître la grille de mise en page, calculer le nombre de pixels que représentent 3 et 7 colonnes, puis les imbriquer dans les @media queries correspondantes, le tout en unités relatives et non en pixels. Et à chaque fois qu’on fera une modification, je devrai retourner me plonger dans le système pour y chopper la largeur d’une colonne, les noms de couleurs, la taille des breakpoints, etc. Avec un pré-processeur CSS, nous avons retranscrit notre schéma de pensée en code, et nos neurones peuvent être utilisées à des choses bien plus créatives que de faire des calculs mentaux.
- Revenons à notre de base
- Ca nous permettre d’être plus communicatif dans notre code, et d’abstraire des opérations complexes en des choses bien plus simples. Le but étant d’écrire quelque chose une fois, et de le rendre facile à réutiliser avec un maximum de bonnes pratiques et de cohérence déjà là par défaut.
- Grâce à cette utilisation de la technologie, plus de soucis d’erreurs de calculs à cause d’un mix entre les pouces et les centimètres. Donc en quelque sorte, faire le pont entre les designers et les développeurs, c’est les mettre au même niveau pour délivrer ensemble un message. Et bien délivrer ce message, que vous soyez à la NASA ou pas, c’est ce qui va faire la différence pour mettre votre projet en orbite.