Faire le pont entre les
développeurs et les
designers au Guardian
@kaelig
À qui s’adresse cette
conférence ?
@kaelig
À qui s’adresse cette
conférence ?
Ceux qui écrivent du code
@kaelig
À qui s’adresse cette
conférence ?
Ceux qui écrivent du code
Ceux qui n’en écrivent pas
@kaelig
À 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épr...
À 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épr...
Mars Climate Orbiter
23 septembre 1999
@kaelig
theguardian.com
http://next.theguardian.com
@kaelig
github.com/guardian/frontend
@kaelig
57 contributeurs
github.com/guardian/frontend
@kaelig
57 contributeurs
github.com/guardian/frontend
~25 ingénieurs touchent à
HTML/CSS
@kaelig
57 contributeurs
github.com/guardian/frontend
~25 ingénieurs touchent à
HTML/CSS
~16 000 lignes de CSS
@kaelig
57 contributeurs
github.com/guardian/frontend
~25 ingénieurs touchent à
HTML/CSS
~16 000 lignes de CSS
100 millions de vis...
57 contributeurs
github.com/guardian/frontend
~25 ingénieurs touchent à
HTML/CSS
~16 000 lignes de CSS
100 millions de vis...
@kaelig
Idée
@kaelig
Idée
@kaelig
Prototype
Idée
@kaelig
Prototype
Idée
@kaelig
Prototype
Idée
Test
@kaelig
Prototype
Idée Test
@kaelig
Mesure en temps réel
@kaelig
A/B tests
@kaelig
Outils de
développement
Scala
Play!
Grunt
Sass
RequireJS
Bower
AWS
Node.js
Selenium
Webdriver
Ruby
TeamCity
GitHub
Phantom...
Outils de
développement
Scala
Play!
Grunt Sass
RequireJS
Bower
AWS
Node.js
Selenium
Webdriver
Ruby
TeamCity
GitHub
Phantom...
sass-lang.com
@kaelig
La couleur du titre de l’article est “gris clair”.
@kaelig
@kaelig
$beccaPurple: #663399;
@kaelig
http://guardian.github.io/guss-colours/ @kaelig
Ce que tu as appris
@kaelig
Ce que tu as appris
• Le code est un outil de
communication (ici : via les variables)
@kaelig
Ce que tu as appris
• Le code est un outil de
communication (ici : via les variables)
• Un pré-processeur aide à éviter le...
Les breakpoints
@kaelig
sass-mq
• Abstraction des @media queries
réutilisable
• Un breakpoint est appelé par son nom
au lieu d’une mesure
github.i...
CSS
.header {!
! background: blue;!
}!
@media all and (min-width: 37.5em) {!
! .header {!
! ! background: transparent;!
! ...
sass-mq : exemple
Sass
CSS
.header {!
! background: blue;!
!
! @include mq($from: tablet) {!
! ! background: transparent;!...
Nommer ses breakpoints
$mq-breakpoints: (!
mobile: 320px,!
tablet: 740px,!
desktop: 980px,!
wide: 1300px!
);!
@kaelig
Nommer ses breakpoints
mobile vs S
tablet vs M
desktop vs L
wide vs XL
@kaelig
Ce que tu as appris
@kaelig
Ce que tu as appris
• Les choses complexes techniquement
peuvent être rendues simples dans le
code
@kaelig
Ce que tu as appris
• Les choses complexes techniquement
peuvent être rendues simples dans le
code
• Coder des petits outi...
La grille
@kaelig
4 à 16 colonnes de 60px
Gouttière : 20px
Marges externes :
< 480px: 10px
> 480px: 20px
Une colonne, une gouttière…
Ça fait combien en pixels ?
@kaelig
https://github.com/guardian/guss-grid-system @kaelig
Baser ses breakpoints sur la grille
@kaelig
// Article breakpoints!
$a-rightCol-width: gs-span(4);!
$a-rightCol-trigger: gs-span(11) + $gs-gutter*2; // 900px!
$a-left...
Ce que tu as appris
@kaelig
Ce que tu as appris
• Le code peut (doit) faire des maths à
ta place
@kaelig
Ce que tu as appris
• Le code peut (doit) faire des maths à
ta place
• Tu peux mixer différents composants
du système de de...
14px/18px normal
14px/18px normal
14px/18px normal
14px/18px normal
14px/18px normal
14px/18px normal 14px/18px normal
20p...
?
?
?
@kaelig
CSS
.element {!
font-size: 16px;!
font-size: 1.6rem;!
line-height: 20px;!
line-height: 2rem;!
font-family: "EgyptianHeadli...
CSS
.element {!
font-size: 16px;!
font-size: 1.6rem;!
line-height: 20px;!
line-height: 2rem;!
font-family: "EgyptianHeadli...
14px/18px normal
14px/18px normal
14px/18px normal
14px/18px normal
14px/18px normal
14px/18px normal 14px/18px normal
20p...
Headline 4
Headline 4
Headline 1
Headline 1
Headline 2 Headline 2
Headline 1 Headline 1
Data 1 Data 1
Data 1
Data 1
Headli...
Ce que tu as appris
@kaelig
Ce que tu as appris
• Lorsqu’aucune convention de
nommage est en place, on peut en
inventer une tous ensemble
@kaelig
Ce que tu as appris
• Lorsqu’aucune convention de
nommage est en place, on peut en
inventer une tous ensemble
• Mettre en ...
3 colonnes par défaut
et 7 colonnes sur
écrans d’ordinateurs
.element {
width: 220px;
}
@media (min-width: 56.25em) {
.ele...
3 colonnes par défaut
et 7 colonnes sur
écrans d’ordinateurs
.element {
width: 220px;
}
@media (min-width: 56.25em) {
.ele...
Prototype
Idée Test
@kaelig
Prototype
Idée Test
Système

de design
@kaelig
@kaelig
Bénéfices :
@kaelig
Bénéfices :
Code + communicatif
@kaelig
Bénéfices :
Code + communicatif
Abstraire le code compliqué
@kaelig
Faites le pont entre les
designers et les
développeurs
Crédits:
Mars Climate Orbiter 2 — By NASA/JPL/Corby Waste [Public d...
Faire le pont entre designers et développeurs avec Sass au Guardian
Faire le pont entre designers et développeurs avec Sass au Guardian
Faire le pont entre designers et développeurs avec Sass au Guardian
Faire le pont entre designers et développeurs avec Sass au Guardian
Upcoming SlideShare
Loading in …5
×

Faire le pont entre designers et développeurs avec Sass au Guardian

4,054
-1

Published on

**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.

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,054
On Slideshare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
21
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • 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.
  • Faire le pont entre designers et développeurs avec Sass au Guardian

    1. 1. Faire le pont entre les développeurs et les designers au Guardian @kaelig
    2. 2. À qui s’adresse cette conférence ? @kaelig
    3. 3. À qui s’adresse cette conférence ? Ceux qui écrivent du code @kaelig
    4. 4. À qui s’adresse cette conférence ? Ceux qui écrivent du code Ceux qui n’en écrivent pas @kaelig
    5. 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. 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. 7. Mars Climate Orbiter 23 septembre 1999 @kaelig
    8. 8. theguardian.com http://next.theguardian.com @kaelig
    9. 9. github.com/guardian/frontend @kaelig
    10. 10. 57 contributeurs github.com/guardian/frontend @kaelig
    11. 11. 57 contributeurs github.com/guardian/frontend ~25 ingénieurs touchent à HTML/CSS @kaelig
    12. 12. 57 contributeurs github.com/guardian/frontend ~25 ingénieurs touchent à HTML/CSS ~16 000 lignes de CSS @kaelig
    13. 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. 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. 15. @kaelig
    16. 16. Idée @kaelig
    17. 17. Idée @kaelig
    18. 18. Prototype Idée @kaelig
    19. 19. Prototype Idée @kaelig
    20. 20. Prototype Idée Test @kaelig
    21. 21. Prototype Idée Test @kaelig
    22. 22. Mesure en temps réel @kaelig
    23. 23. A/B tests @kaelig
    24. 24. Outils de développement Scala Play! Grunt Sass RequireJS Bower AWS Node.js Selenium Webdriver Ruby TeamCity GitHub PhantomJS @kaelig
    25. 25. Outils de développement Scala Play! Grunt Sass RequireJS Bower AWS Node.js Selenium Webdriver Ruby TeamCity GitHub PhantomJS @kaelig
    26. 26. sass-lang.com @kaelig
    27. 27. La couleur du titre de l’article est “gris clair”. @kaelig
    28. 28. @kaelig
    29. 29. $beccaPurple: #663399; @kaelig
    30. 30. http://guardian.github.io/guss-colours/ @kaelig
    31. 31. Ce que tu as appris @kaelig
    32. 32. Ce que tu as appris • Le code est un outil de communication (ici : via les variables) @kaelig
    33. 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
    34. 34. Les breakpoints @kaelig
    35. 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. 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. 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. 38. Nommer ses breakpoints $mq-breakpoints: (! mobile: 320px,! tablet: 740px,! desktop: 980px,! wide: 1300px! );! @kaelig
    39. 39. Nommer ses breakpoints mobile vs S tablet vs M desktop vs L wide vs XL @kaelig
    40. 40. Ce que tu as appris @kaelig
    41. 41. Ce que tu as appris • Les choses complexes techniquement peuvent être rendues simples dans le code @kaelig
    42. 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
    43. 43. La grille @kaelig
    44. 44. 4 à 16 colonnes de 60px Gouttière : 20px Marges externes : < 480px: 10px > 480px: 20px
    45. 45. Une colonne, une gouttière… Ça fait combien en pixels ? @kaelig
    46. 46. https://github.com/guardian/guss-grid-system @kaelig
    47. 47. Baser ses breakpoints sur la grille @kaelig
    48. 48. // 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
    49. 49. Ce que tu as appris @kaelig
    50. 50. Ce que tu as appris • Le code peut (doit) faire des maths à ta place @kaelig
    51. 51. 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
    52. 52. 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
    53. 53. ? ? ? @kaelig
    54. 54. 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);! }
    55. 55. 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);! }
    56. 56. 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
    57. 57. 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
    58. 58. Ce que tu as appris @kaelig
    59. 59. Ce que tu as appris • Lorsqu’aucune convention de nommage est en place, on peut en inventer une tous ensemble @kaelig
    60. 60. 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
    61. 61. 3 colonnes par défaut et 7 colonnes sur écrans d’ordinateurs .element { width: 220px; } @media (min-width: 56.25em) { .element { width: 540px; } }
    62. 62. 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); } }
    63. 63. Prototype Idée Test @kaelig
    64. 64. Prototype Idée Test Système
 de design @kaelig
    65. 65. @kaelig
    66. 66. Bénéfices : @kaelig
    67. 67. Bénéfices : Code + communicatif @kaelig
    68. 68. Bénéfices : Code + communicatif Abstraire le code compliqué @kaelig
    69. 69. 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
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×