Tagfront-end

[Webpack Encore] Intégration d’UIkit v3 dans un projet Symfony pour un bundle à la carte

Méthode préférée de création d’un bundle des composants du framework front-end UIkit v3 avec Webpack

Testé fonctionnel UIkit v3.6.19!
Voir aussi: la méthode la plus simple, mais extrêmement limitée en terme de choix des composants qu’on souhaite importer (embarque tous les composants JS du core, embarque les styles d’absolument tous les composants).

Suite à différents tests de génération d’un bundle entièrement à la carte des composants d’UIkit v3 que j’ai effectué et à quelques soucis rencontrés avec l’affichage des icônes, je me suis rendu à l’évidence que le framework open-source développé par YOOTheme n’allait pas pouvoir être intégré à mon projet Symfony dans les règles de l’art.

Pour pouvoir sélectionner à la carte les composants et les icônes qui doivent figurer dans notre bundle (et surtout: retirer tous ceux qui ne vont pas servir!!!) tout en consignant les informations sur notre sélection directement dans le Git de notre projet, nous allons notamment devoir:

  • Créer un dossier mirroir des sources d’UIkit (dossier ./node_modules/uikit/*) dans le dossier qui contient le code spécifique à notre projet (dossier ./assets/uikit/* dans mon cas).
  • Commenter tous les composants dont nous n’aurons pas besoin pour notre build custom dans les fichiers assets/uikit/src/scss/theme/_import.scss et assets/uikit/src/scss/components/_import.scss (mirroirs de ceux du dossier source ./node_modules/uikit/src/scss/*).
  • Commenter tous les composants dont nous n’aurons pas besoin pour notre build custom dans les fichiers assets/uikit/src/js/core/index.js et assets/uikit/src/js/components/index.js (mirroirs de ceux du dossier source ./node_modules/uikit/src/js/*).
  • Consigner notre sélection d’icônes dans des dossiers mirroirs de ceux du dossier source ./node_modules/uikit/src/images/*
  • Exécuter un script bash qui va s’occuper de:
    • Remplacer les fichiers source de ./node_modules/uikit/* par leurs versions mirroirs consignées dans ./assets/uikit/* (et ajouter les nouveaux fichiers si il y en a).
    • Lancer, depuis ./node_modules/uikit, les commandes de build fournies dans les sources d’UIkit pour notre sélection de composants et d’icônes.
    • Lancer, depuis la racine du projet Symfony, la commande Webpack de build des sources SCSS, JS et icônes de notre projet (yarn encore dev).

Cette technique s’inspire du concept de fork, à la différence qu’ici nous n’aurons pas à maintenir un fork à chaque montée de version d’UIkit (un nouveau tag tous les 15 jours au moment où j’écris ces lignes).
Ici, les modifications relatives aux sources d’UIkit sont également versionnées directement dans les sources de notre projet custom alors qu’avec un fork doit avoir par définition son propre dépôt (donc un seul repository à gérer au lieu de deux).

Il s’agit de générer de nouvelles sources « dist » d’UIkit, taillées sur-mesure sur la base de notre propre sélection de composants et d’icônes.

C’est la source présente dans le dossier ./node_modules/uikit/dist qui est importée par défaut par Webpack lorsque nous déclarons la ligne import UIkit from 'uikit'; dans le fichier assets/app.js.

Note: en procédant ainsi il devrait (je n’ai pas encore testé) être possible d’ajouter également vos propres composants, développés sur les bases d’UIkit, au build custom.

La configuration de Webpack

Fichier webpack.config.js

Dans la configuration de Webpack, ajouter l’alias pour le chemin vers les sources SCSS d’UIkit dans le dossier ./node_modules:

Le bundle à la carte des styles (format SCSS)

Note: le build standard des styles d’UIkit (format de sortie/dist CSS) a ceci de particulier qu’il est réalisé à partir des sources LESS. Le framework est bien fourni avec une version SCSS des styles, mais il s’agit juste d’une conversion faite à partir des sources LESS et générée via un script.

En d’autres termes, si nous souhaitons travailler à partir du format SCSS, le build pour cette partie devra être réalisé côté Webpack.

Fichier assets/styles/app.scss

Note: selon votre propre organisation de vos fichiers SCSS, l’import de _uikit-explicit-pieces.scss devrait intervenir très tôt (en tout premier?) dans votre chaîne d’imports.

Fichier assets/styles/_uikit-explicit-pieces.scss

Créer un fichier _uikit-explicit-pieces.scss qui suit à la lettre les directives de mise en place des styles relatifs au framework front-end UIkit.

L’alias @uk-scss déclaré plus haut dans le fichier webpack.config.js est utilisé ici comme racine du chemin vers les fichiers sources.

Edit: l’utilisation de PurgeCSS avec Webpack rend le reste de la partie SCSS de cet article totalement OBSOLèTE!

Attention: les styles propres à la grille d’UIkit comportent des déclarations de type .uk-child-width-1-4@m. L’arobase n’étant pas présent dans la regex du defaultExtractor de PurgeCSS, il faudra faire comme moi dans le code ci-dessous et le rajouter si vous voulez éviter que les styles de la grille soient considérés comme non-utilisés et dégagés du bundle.

En effet, plus besoin d’éditer les fichiers _import.scss des sources d’UIkit pour commenter les composants dont nous n’avons pas besoin! PurgeCSS se charge de faire le boulot à notre place en scannant les chemins et fichiers que nous allons pointer dans sa configuration pour repérer les IDs et classes que nous utilisons et purement et simplement supprimer toutes les autres de notre bundle!

Voici un exemple à rajouter à la toute fin de votre fichier webpack.config.js:

Cette technique reste une suggestion, mais reconnaissez que c’est tout-de-même bien pratique!

Fichier assets/uikit/src/scss/theme/_import.scss

Ce fichier est, à la base, une copie conforme du fichier source https://github.com/uikit/uikit/blob/v3.6.19/src/scss/theme/_import.scss.

Commenter tous les composants dont vous n’aurez pas besoin pour votre build custom (où commenter carrément l’import de ce fichier dans assets/styles/_uikit-explicit-pieces.scss si vous pensez que rien ne va vous servir):

Fichier assets/uikit/src/scss/components/_import.scss

Ce fichier est, à la base, une copie conforme du fichier source https://github.com/uikit/uikit/blob/v3.6.19/scss/components/_import.scss.

Commenter tous les composants dont vous n’aurez pas besoin pour votre build custom:

Les fichiers JS

Fichier assets/app.js

  • On importe le fichier SCSS « racine/maître » app.scss. C’est celui qui va concentrer l’ensemble des @import des différents composants.
  • On importe le bundle* de notre sélection de composants JS via la directive import UIkit from 'uikit';.
  • On importe le bundle* de notre sélection d’icônes via les directives import Icons from 'uikit/dist/js/uikit-icons'; UIkit.use(Icons);
  • On initialise un composant Notification (test)

*: j’explique ça juste en-dessous.

Fichier assets/uikit/src/js/core/index.js

Ce fichier est, à la base, une copie conforme du fichier source https://github.com/uikit/uikit/blob/v3.6.19/src/js/core/index.js.

Commenter tous les composants dont vous n’aurez pas besoin pour votre build custom:

Fichier assets/uikit/src/js/components/index.js

Ce fichier est, à la base, une copie conforme du fichier source https://github.com/uikit/uikit/blob/v3.6.19/src/js/components/index.js.

Commenter tous les composants dont vous n’aurez pas besoin pour votre build custom:

Les icônes

Structure des dossiers (à respecter)

Attention: la documentation d’UIkit vous explique comment remplacer des icônes existantes ou ajouter de nouvelles icônes à votre projet.
Cependant, cette dernière fait mention d’un dossier custom/ dans lequel placer les nouvelles icônes à ajouter à votre projet (avant d’effectuer votre build)… sans préciser à quel endroit de l’arborescence des fichiers du framework celui-ci devrait se trouver (edit: dans src/custom/icons/)!

La manipulation des icônes fonctionnera très bien si vous déposez vos fichiers de remplacement et vos nouveaux fichiers dans l’un des 3 dossiers suivants:

  • Icônes des… erm… (reste à définir): ./assets/uikit/src/images/backgrounds/
  • Icônes des composants: ./assets/uikit/src/images/components/
  • Icônes de la bibliothèque d’icônes: ./assets/uikit/src/images/icons/

Note: dans le cas où une même icône est utilisée pour un ou plusieurs composants ET dans la bibliothèque (la croix de fermeture par exemple, présente au minimum dans le composant Notification ET dans la bibliothèque), le fichier doit être présent dans les deux dossiers ./assets/uikit/src/images/components/close-icon.svg et ./assets/uikit/src/images/icons/close.svg (libellé différent, et le code peut-être différent également pour une même icône, cf. ici (components/close-icon.svg) et là (icons/close.svg)).

Fichier assets/uikit/build/util.js

Ce fichier est, à la base, une copie conforme du fichier source https://github.com/uikit/uikit/blob/v3.6.19/build/util.js.

Je ne donne ci-dessous que la constante const svgo = new SVGO qui est à modifier avec l’ajout de deux nouveaux paramètres, mais l’intégralité du code issu du fichier source est, bien entendu, à conserver!:

  • removeAttrs qui va s’occuper de nettoyer le fichier SVG source en supprimant des attributs, inutiles pour nous, qu’on va par exemple retrouver dans les icônes issues de la populaire bibliothèque Font Awesome.
  • addAttributesToSVGElement qui va s’occuper d’ajouter les attributs width="20" et height="20", nécessaires au bon fonctionnement de la bibliothèque d’icônes UIkit, là où ils manquent. Attention: si ces attributs existent déjà avec des valeurs similaires ou d’autres valeurs, ils ne seront pas écrasés par ce paramètre!

Petit récapitulatif de l’arborescence attendue

…sous forme de capture d’écran.


Le script bash

Nouvelle méthode (au 04/05/2021):

Dans le fichier package.json qui devrait se trouver à la racine de votre projet, nous allons ajouter un script qui va générer automatiquement les sources dist optimisées d’UIkit:

Nous allons ensuite créer un fichier build/build-uikit.sh qui va contenir le script en question:

ATTENTION: afin de rendre ce script exécutable, il faut lancer depuis la racine de votre projet la commande chmod +x ./build/build-uikit.sh!

Désormais, vous pourrez lancer différentes commandes pour générer votre build à la carte d’UIkit:

  • yarn run uk: générer les sources JS et le sprite d’icônes SVG d’UIkit
  • yarn run uk uikit: générer uniquement les sources JS d’UIkit
  • yarn run uk icons: générer uniquement le sprite d’icônes SVG d’UIkit

Note: nous n’avons bien sûr pas de commande relative aux styles car ils sont générés directement via Webpack Encore.

Méthode précédente (dépréciée):

Attention: les sources du framework front-end UIkit consignées dans le dossier node_modules/ de votre projet ont leur propre fichier package.json. Pour exécuter les différents scripts de build, il convient donc d’avoir au préalable déployé les dépendances Node au sein du dossier à l’aide de la commande npm install. En d’autres termes, si le dossier node_modules n’est pas présent dans le dossier ./node_modules/uikit/, les commandes de build vont vous péter à la tronche :D.

Depuis la racine de votre projet:

On copie nos fichiers custom d’UIkit vers le dossier où sont consignées les sources issues du Git officiel (les fichiers initiaux existants seront écrasés par les nôtres; c’est ce qu’on veut):

On se rend dans le dossier où sont consignées les sources d’UIkit:

La manipulation suiffante n’est à effectuer que dans deux cas:

  1. Vous n’avez encore jamais lancé la commande npm install depuis ce dossier et le dossier node_modules n’est donc pas présent à la racine de ./node_modules/uikit/.
  2. Vous avez effectué des modifications dans le fichier ./node_modules/uikit/package.json (vérifier que ce fichier est présent dans ./assets/uikit/; ça peut être une bonne indication du fait qu’il faille lancer les deux commandes ci-dessous).

Effectuer un build non-minifié (paramètre -d – c’est Webpack Encore qui assurera la minification par la suite) des sources JS d’UIkit qui contient uniquement notre sélection de composants et la bibliothèque d’icônes:

Note: voir les autres paramètres possibles pour la commande node build/build.

On retourne à la racine de notre projet et on lance la commande de build propre à Webpack Encore:

Vos sources pour afficher votre site dans le navigateur sont prêtes!

Quelques chiffres suite à mes tests

Caveats connus!

  • Les icônes des composants, si elles proviennent d’une autre source que la bibliothèque UIkit, ne sont pas nettoyées par par les modifications apportées au script de build de cette dernière ce qui occasionne des soucis d’affichage. Solution de correction possible: passer au préalable par Webpack (plutôt que par une modification des scripts de build d’UIkit) pour nettoyer tous les SVG et les rendre « UIkit-compliant » avant de les envoyer vers ./node_modules/uikit/* et d’effectuer un build.

Méthode alternative (attention: limitations connues au niveau des icônes)

ATTENTION: plusieurs limitations au niveau des icônes avec cette méthode de bundle:

Diagnostique des erreurs:

M’affiche l’erreur suivante en console:

fastdom.js:67 TypeError: Cannot read property ‘cloneNode’ of undefined
at getIcon (icon.js:186)
at UIkitComponent.getSvg (icon.js:63)
at UIkitComponent.connected (svg.js:38)
at hooks.js:10
at Array.forEach ()
at UIkitComponent.UIkit._callHook (hooks.js:10)
at UIkitComponent.UIkit._callConnected (hooks.js:31)
at UIkitComponent.UIkit.$mount (instance.js:28)
at UIkitComponent.UIkit._init (state.js:23)
at new UIkitComponent (global.js:30)

Les icônes des composants sont générées séparément du sprite d’icônes utilisables à la carte (et qui, lui, fonctionne!).
Lorsque je compare aux sources JS fournies dans le dossier dist, je remarque l’absence du code suivant dans mon bundle Webpack:

Pas de résolution à ce jour.

Fichiers impliqués

Fichier assets/app.js

Fichier webpack.config.js:

Bundle Javascript – Fichier assets/uikit-explicit-pieces.js:

Bundle Styles – Fichier: uikit-explicit-pieces.scss:

Préconisations supports graphiques pour développement front-end

Quelques bonnes pratiques, à l’attention de nos amis graphistes, pour fournir des supports de découpe exploitables.

Prise en charge des différents navigateurs et OS

Proposer une prise en charge des versions n -1 de chaque navigateur et OS (pour les mobiles) sur la base des dernières statistiques (en fonction de la zone géographique visée) accessibles ici https://www.w3counter.com/globalstats.php.
Suivant la cible d’utilisateurs propre au projet on peut affiner si il le faut, mais par contre on ne va pas différer le scope de prise en charge en fonction des zones géographiques (France : telle et telle version, Angleterre : telle et telle version, etc..). Il faut absolument dégager un tronc commun de versions de navigateurs et d’OS.

Autres sources d’informations sur la fréquentation des sites selon les OS, navigateurs, résolutions d’écran, etc…:

Pour une liste exhaustive et chronologique des versions des OS et des navigateurs: https://crossbrowsertesting.com/browsers.

Peut-être se caler sur le support de Flexbox ? http://caniuse.com/#search=flexbox.

Etat des lieux OS et navigateurs au 22/03/2017

  • Internet Explorer 11
  • Edge 14, 13
  • Firefox 52, 51
  • Chrome 57, 56
  • Safari 10, 9.1
  • iOS Safari 10.2, 9.3

Points de rupture

Les points de rupture préconisés à l’heure actuelle (précos fondées sur des stats d’utilisation à l’échelle mondiale – W3Counter Global Web Stats) sont :

  • Limite haute Smartphone : 640px; (soit, à partir de 641px, on passe en vue Tablette)
  • Limite haute Tablette : 768px; (soit, à partir de 769px, on passe en vue Desktop)

On ne cible pas un modèle ou une marque de smartphone ou de tablette, mais des résolutions cibles moyennes.

Si le site exploite la totalité de la largeur disponible en vue Desktop

La page s’étend sur 100% de la largeur de l’écran. A ce moment-là, pas de préconisations si ce n’est de respecter les deux points de rupture donnés ci-dessus.

Pour un site dont la page serait contenue dans une largeur fixe et centrée en vue Desktop

Voici les largeurs maximum préconisées par vue, gouttières (marges) incluses :

  • Smartphone : 640px (soit 610px avec 15px de gouttières à gauche et à droite)
  • Tablette : 768px (soit 738px avec 15px de gouttières à gauche et à droite)
  • Desktop : 1200px (soit 1170px avec 15px de gouttières à gauche et à droite)

Si le principe de gouttières n’est pas maîtrisé côté graphistes, me les envoyer.

Grille

La grille de 12 colonnes est un standard aujourd’hui car elle est pratique à diviser (2,3,4,6 ont tous 12 comme multiple).
Aujourd’hui, la version SASS de Bootstrap nous permet de générer à la volée des grilles du nombre de colonnes qu’on veut.
Donc ils peuvent très bien partir sur du 6, 14, 16, 18, 24 colonnes si ils ont envie.

Ce qui est important par contre, c’est :

  • d’avoir la même grille sur toutes les pages, peu importe la vue (Mobile, Tablette, Desktop)
  • de bien maîtriser le concept de gouttières et de les exploiter pour créer des espaces verticaux entre les différentes zones dans les maquettes

Texte dans les supports graphiques

Utiliser l’unité px pour vos tailles de texte. L’unité pt n’a de valeur que pour les documents destinés à l’impression papier et 10pt ne sont pas l’équivalent de 10px.

Polices de caractères spé

Dans l’idéal, les polices de caractères spé viennent de https://www.google.com/fonts.

Le client peut, bien entendu, imposer l’utilisation d’une police payante si il s’acquitte des droits nécessaires à son utilisation pour le support web.
La plupart du temps, il s’agit d’un service qui fonctionne comme Google Fonts (à savoir qu’il héberge les polices et fournit un CDN qui permet de les exploiter sur son site), mais payant.
Plusieurs types de forfaits sont généralement proposés.
Si le client fait ce choix, nous irons plus loin dans les explications de ce qu’il doit nous fournir.

En tout cas, de notre côté, il faut refuser de passer des fontes TTF à la moulinette. C’est illégal. D’ailleurs, le service en ligne qui permet de convertir des TTF dans des formats exploitables sur le web (Font Squirrel Webfont Generator) bloque la conversion des polices soumises à des droits d’utilisation sur demande des auteurs.
Aucune police Adobe ne passe, par exemple.

Polices de caractères spé : pour aller plus loin

Voir aussi plus bas: cas des polices Adobe

La maquette livrée intègre plusieurs déclinaisons d’une police propriétaire ?

Le client doit dans un permier temps s’acquitter des droits d’utilisation de cette police et de ses déclinaisons et dans un second temps nous fournir des sources dans un format exploitable pour le support web (« Webfont » sur la plupart des services d’achat, j’y viens plus bas).

Polices manquantes identifiées :

  • FuturaStd Book
  • FuturaStd Bold
  • FuturaStd Medium
  • FuturaStd Heavy

J’ai trouvé une police « Futura », diffusée par « Adobe », sur le suite suivant : https://www.myfonts.com/fonts/adobe/futura/. Mais il semble qu’elle soit uniquement commercialisée dans un format à destination des supports « print » (Cliquer sur « Buying choices » : elle est disponible pour une utilisation « Desktop » seulement).

Il existe d’autres polices « Futura » (https://www.myfonts.com/fonts/bitstream/futura/alternate_cuts.html), comme par exemple celle-ci diffusée par « Bitstream » : https://www.myfonts.com/fonts/bitstream/futura/#index. En cliquant sur « Buying choices », on voit que les sources sont disponibles pour une utilisation « Desktop », mais aussi « Webfont » qui nous conviendra mieux.

On voit dans la liste déroulante que cette police se loue pour un nombre de pages vues par mois (10 000, 100 000, 1 000 000, illimité).
Je parle de location car ce type de service fonctionne comme Google Fonts en fournissant un CDN que l’acquéreur peut ensuite déclarer dans les en-têtes des pages de son site afin d’accéder à la police.
Avec ce fonctionnement, la police sera hébergée sur un serveur du service myfonts.com.

Ce service va surveiller le nombre de pages vues qui accèdent à la police et couper l’accès lorsque le seuil de pages à afficher défini lors l’achat est dépassé.
La police sera alors remplacée par une version déclarée en fallback dans nos CSS.
Les personnes en charge de la charte doivent nous communiquer laquelle. Il faut préférer une police répandue, installée sur une majorité de postes comme Arial, Verdana…
Le service http://www.cssfontstack.com/ donne un bon aperçu des polices les plus disponibles suivant les environnements (Win, Mac).

J’ignore par ailleurs si l’itération de la police « Futura » proposée par « Bitstream » conviendra pour la charte que nous devons mettre en place.
Il en existe d’autres sinon (lien déjà donné plus haut – https://www.myfonts.com/fonts/bitstream/futura/alternate_cuts.html).
C’est aux personnes en charge de la charte graphique de nous confirmer ça.

Voilà pour les pratiques actuelles. Le client peut, bien-sûr, trouver un autre service si le mode de fonctionnement ou les tarifs de celui-ce venaient à ne pas convenir.
Je ne le préconise pas particulièrement; c’est juste qu’il met à disposition la police utilisée.

Il reste possible de remplacer les polices propriétaires par des polices gratuites fournies sur le même mode par https://www.google.com/fonts.
Gage aux graphistes de nous en communiquer la liste, avec équivalence pour chaque itération de la police Futura (un remplacement des polices dans les sources psd et une nouvelle livraison sera demandé côté intégrateurs).

Attention si le client nous fournit un pack de polices arrivé de nulle-part à exploiter : il existe encore aujourd’hui des moulinettes en ligne capables, à partir d’une police au format *.TTF de générer des packs « Webfont ».
La plupart de ces outils (comme https://www.fontsquirrel.com/) bloquent la conversion de polices nécessitant des droits d’utilisation.

Dans tous les cas, si le client nous fournit un pack de fichiers, il devra également nous fournir la preuve d’achat et l’autorisation et les conditions d’exploitation qui vont avec.

Cas des polices Adobe

Voici les différentes formules proposées par Adobe : https://typekit.com/plans.

La police Aktiv Grotesk n’est pas disponible dans la formule GRATUIT : https://typekit.com/fonts/aktiv-grotesk/availability.

  • La formule PORTEFEUILLE (50$/an) permet l’affichage de la police Aktiv Grotesk pour 500 000 pages vues/mois.
  • La formule PERFORMANCES (100$/an) permet l’affichage de la police Aktiv Grotesk pour 1 000 000 de pages vues/mois.

Mode d’utilisation légale des polices Adobe sur un site web : https://helpx.adobe.com/fr/typekit/using/add-fonts-website.html.

  1. On se connecte à Typekit
  2. On sélectionne les polices qu’on souhaite exploiter sur notre site
  3. On récupère un code javascript qui nous permet d’afficher les polices choisies dans les pages de notre site (https://helpx.adobe.com/fr/typekit/using/add-fonts-website.html#main-pars_text_4).
  4. Utilisation des noms font-family dans votre code CSS. Pour une police dont la classe ajoutée à l’élément html correspond à wf-aktivgroteskthin-i2-active, le code à ajouter dans les styles est : font-family: aktiv-grotesk-thin, sans-serif;.

Convertir une source TTF en police WEB (formats WOFF, WOFF2 notamment) qu’on hébergerait sur serveur nous appartenant est une pratique illégale pour des polices ADOBE.

Icônes, pictogrammes

Quelques règles de base

  • Eviter de fournir des icônes au format bitmap (BMP, JPG ou GIF récupérées sur internet et sur lesquels ont été appliqués des filtres Photoshop comme l’incrustration de couleur – HTML/CSS/JS ne nous permettent pas de faire la même chose dans un navigateur).

Icônes libres de droits

Icônes spé (designées côté créas)

  • Les icônes spé doivent nous être fournies au format SVG de manière à faciliter la création d’une police d’icônes.
  • 1 icône = 1 fichier SVG. Pas de fichier/planche unique comprenant toutes les icônes.
  • Ces icônes doivent être monochromes; elles pourront être fournies dans n’importe quelle couleur car nous pourrons modifier la teinte via CSS.
  • Si une même icône est assemblée à partir de plusieurs tracés vectoriels, s’assurer que ces derniers sont bien liés avant de générer le SVG. Les tracés vectoriels de vos icônes doivent être convertis en éléments pleins pour être exploitables. Démarche à suivre sous Illustrator et Fireworks.
  • Si vous utilisez Illustrator, sauvegardez vos SVG avec les paramètres définis ici.
  • Avant de nous renvoyer les pictos modifiés, le graphiste peut vérifier l’intégrité de ses fichiers SVG en tentant de les importer dans un outil en ligne de création de polices d’icônes : https://icomoon.io/app/#/select. Il suffit de cliquer sur le gros bouton mauve « Import Icons », d’uploader les fichiers SVG et de vérifier que l’affichage est optimal.

Guide de styles

Un article (en français) qui explique bien l’intérêt du guide et ce qu’il doit contenir : 24 jours de web – Un guide qui a du style.

Un exemple de guide (base Bootstrap 3 – mais il y a trop de choses) : Bootstrap Style Guide Boilerplate by Monolinea.

Cet exemple contient beaucoup d’informations. Le graphiste doit lister uniquement les éléments et composants récurrents qui vont réellement servir. Les indispensables selon moi :

  • Foundation
    • Colors
    • Grid
    • Typography
  • Base styles
    • Buttons (on a 6 boutons dans l’exemple ; pas la peine d’essayer de placer les 6. On peut très bien s’en sortir avec 2, 3 ou 4 différents seulement. Ne créer plusieurs couleurs de boutons que si ils ont réellement un sens d’action différente attendue de la part de l’utilisateur)
    • Form Controls
    • Headings (pareil : on a 6 niveau de titres ; pas la peine d’essayer de tous les placer. On peut très bien s’en sortir avec 4)
    • Images (ici, consigner absolument tous les formats d’images qui seront utilisés. Passé 5 ou 6 formats différents, il y en a trop…)
    • Lists
    • Tables
    • Text Elements
  • Patterns
    • Alerts (ne créer plusieurs couleurs d’alertes que si elles ont réellement un sens différent pour l’utilisateur)
    • Forms
    • Navs – Tous les mécanismes de navigation du site (navigation principale, navigation contextuelle, fil d’Ariane, onglets, pagination…)

Des éléments non présents dans cette liste peuvent être rajoutés au besoin si d’autres composants récurrents sont présents dans les pages.


Travail avec Zeplin ou Avocode

  • Absolument toutes les tailles (pas uniquement les textes) sont en points (pt) dans les maquettes que j’ai vu. Il est très important pour nous d’avoir des tailles en pixels (px).
  • J’ai repéré au moins une taille d’élément (tuto-step-3 > cercle ’30 min’) dont la largeur était un nombre décimal (105.3pt). On ne va pas implémenter d’éléments dont les dimensions sont fondées sur des nombres décimaux.
  • Les informations de couleurs sont en RGB. Il faut nous les fournir en hexadécimal. J’ai vu qu’elles étaient en hexadécimal dans le Guide de Styles. Il faudrait qu’elles s’affichent en hexadécimal directement dans les maquettes afin de ne pas avoir à switcher systématiquement entre le Guide de Styles et les maquettes pour obtenir une couleur.
  • Les sorties proposées pour les icônes/pictogrammes sont au format PDF et PNG. Il nous faudrait une sortie au format SVG ou, à défaut, que toutes les icônes proviennent d’un pack d’icônes de type http://fontawesome.io/ qui fournit une fonte web. Si un pack d’icônes payant a été utilisé, il faudra nous le fournir. Nous n’allons pas traiter les icônes sous forme de sprite PNG, mais sous forme de fonte.
  • Je vois dans la page ‘login’ que tous les éléments graphiques sont au format Bitmap et qu’on ne peut pas les extraire. A ce titre :
    • Les sorties proposées pour les visuels d’illustrations (photos, bannières, etc…) doivent inclure le format Jpg.
    • Les logos et autres éléments qu’on ne considère pas comme des icônes ou pictogrammes doivent être extractibles sous forme de PNGs transparents.
  • Zeplin laisse-t’il la possibilité d’afficher la grille en surimpression sur les maquettes (de manière légèrement transparente) ?

Remarque d’ordre plus général :

  • Les points énoncés dans la liste ci-dessus doivent être respectés pour nous permettre de réaliser un travail optimal de notre côté.
  • On ne s’engage pas sur du Pixel Perfect. On garantira simplement des espacements et des alignements homogènes entre les différents composants des pages. L’intérêt d’utiliser une grille est également de pouvoir caler les composants de pages dessus. Par exemple, un champ texte de formulaire ou un visuel dans une page donnée ne fait pas 300px de large mais 3 colonnes. L’espacement entre deux éléments alignés ne fait pas 30px de large mais la largeur de la gouttière de la grille, etc …
    Je crois qu’ils ont parlé de Pixel Perfect. En responsive, ça n’a pas de sens sachant que toutes les largeurs (voir certaines hauteurs, notamment pour les images) s’adaptent de manière homothétique/fluide en fonction de la largeur de l’écran du support de consultation. Et des supports de consultation, il peut y en avoir 15.000 différents …
  • Sachant que nous acceptons de travailler avec un outil (Zeplin) imposé par nos interlocuteurs afin qu’ils puissent travailler dans les meilleures conditions, nous attendons de leur part d’être réactifs si nous rencontrons des soucis d’exploitation des sources fournies.

Ressources externes

Photoshop etiquette

Photoshop etiquette – A guide to discernable webdesign. Défend une approche organisée du webdesign en promouvant la clarté, l’empathie et l’intention.

Les objets dynamiques liés dans Photoshop

Les objets dynamiques sont des calques qui contiennent les données d’images pixellisées ou vectorielles, comme les fichiers Photoshop ou Illustrator. Ils conservent le contenu source des images avec toutes leurs caractéristiques d’origine, vous permettant ainsi d’apporter des modifications non destructrices au calque. Comme avec du templating, vous y trouverez quelques avantages :

  • moins de répétition ;
  • une propagation des changements « automagique » ;
  • une organisation proche de celle de votre CMS ;
  • et une facilité pour travailler à plusieurs.

© 2021 devfrontend.info

Theme by Anders NorénUp ↑