Pompage le web design puisé à la source http://www.pompage.net https://s2.googleusercontent.com/s2/favicons?alt=feed&domain=www.pompage.net f43.me Sun, 19 Apr 2026 16:52:31 +0200 <![CDATA[Traduit ailleurs : Travailler avec les icônes SVG]]>

on SVG, CSS, Intermédiaire, Design

Un bel article de notre frenchie Florens Verschelde qui a fait le buzz et a été repris par l'excellent CSS-Tricks. Explications claires du process et réflexions pour aller plus loin.

Par Florens Verschelde

Il existe bien des façons d’utiliser les icônes SVG en HTML et en CSS, et je ne les ai pas toutes essayées. Ce qui suit correspond à la façon de travailler de la petite équipe front-end de Kaliop. Elle répond à nos besoins, qui comprennent :

Des sites web de communication et de contenu, souvent basés sur de gros CMS, plutôt que des applications full-JavaScript. Des icônes qui sont souvent de simples icônes monochromes — chacune pouvant être utilisée en différentes couleurs, selon le contexte et les interactions utilisateur — mais possibilité d’avoir des icônes en bichromie.

Compatibilité navigateurs IE9+.

Table des matières

Préparer vos icônes

Lorsque vous recevez une icône SVG, conçue par un designer ou livrée avec un outil graphique (Illustrator, Adobe Assets, Sketch, Inkscape, etc.), il peut être tentant de l’inclure directement dans votre projet. Cependant, une petite révision dans votre outil favori peut vous épargner quelques maux de tête et améliorer significativement le résultat.

Une icône simple sur un plan de travail Illustrator (à gauche) et sur un artboard Sketch (à droite)

Travailler avec un nouveau document ou artboard

Créez un nouveau document ou un nouvel artboard (plan de travail) dans votre outil favori et copiez-collez votre icône au centre. C’est une excellente façon de vous assurer que votre icône soit propre et ne contienne pas une tonne de chemins cachés.

La coupe au carré c’est plus facile

Votre icône ne doit pas nécessairement être un carré, mais les icônes carrées sont plus faciles à traiter (sauf si votre graphique est vraiment très haut ou très large).

Les dimensions exactes importent seulement si vous voulez gérer au pixel près pour obtenir les résultats les plus nets possible sur les écrans à faible densité. Par exemple, si toutes vos icônes tiennent sur une grille de 15px × 15px, et si elles sont utilisées le plus souvent avec ces dimensions exactes, vous pouvez y aller et continuer à travailler avec des artboards ou des documents de 15 × 15. Quand je ne suis pas sûr, je préfère utiliser un artboard de 20 × 20.

Bien dégagé autour des oreilles

Laissez un peu de marge autour de la forme, surtout si elle est arrondie. Les navigateurs utilisent l’anticrénelage (anti-aliasing) pour rendre les formes SVG mais parfois les pixels supplémentaires de l’anticrénelage sont rendus en dehors de la viewBox et sont coupés.

Nous n’avons pas laissé d’espace autour de l’icône, donc il y a des chances qu’elle soit rendue avec des côtés légèrement carrés. Et si le navigateur ne rend pas le SVG à la perfection, ça peut être encore pire.

Une bonne règle générale, pour une icône de 16 ou 20px, serait de laisser un espace de 0.5 ou 1px de chaque côté. De plus, n’oubliez pas d’exporter tout l’artboard, pas seulement les chemins sélectionnés, sinon vous perdriez l’espace autour de la forme.

Exporter en SVG

  • dans Illustrator, j’utilise simplement “Save as” et je choisis le format “SVG”.
  • dans Inkscape, vous pouvez faire “Save as” et choisir “Optimized SVG”.
  • dans Sketch, vous pouvez sélectionner un artboard, cliquer sur “Make exportable” en bas à droite et choisir le format “SVG”.

Apprendre un peu de SVG

Il est vraiment utile de connaître les bases de SVG pour pouvoir lire et comprendre la structure de fichiers SVG simples. Au minimum, vous devriez connaître :

  • Elements: <svg>, <symbol>, <g>, <path>.
  • Attributes: d, fill, stroke, stroke-width.

Remarque : quand vous exportez un SVG depuis un outil de design, il comprendra souvent du markup et des métadonnées inutiles, ainsi que des données excessivement précises pour le chemin (dans l’attribut d). Essayez l’outil SVGOMG and comparez le code avant et après pour voir ce qui est supprimé ou simplifié.

Supprimer les données de couleurs

Pour les icônes monochromes, assurez-vous que :

  1. dans votre fichier source, les chemins sont noirs (#000000)
  2. dans le code exporté, il n’y a pas d’attribut fill.

Si nous avons des fill dans le code SVG, nous ne pourrons pas remplacer ces couleurs à partir de notre code CSS. Il est donc préférable de les supprimer, du moins pour les icônes monochromes.

Illustrator ne produit pas d’attributs fill pour les chemins qui sont entièrement noirs (#000000). Par contre, Sketch crée ces attributs, donc il vous faudra sans doute supprimer manuellement les attributs fill="#000000".

Créer un sprite SVG

Cette partie comprend pas mal de code mais il n’est pas compliqué du tout. Nous voulons créer un document SVG contenant des éléments <symbol>. Chaque <symbol> doit avoir un attribut id et un attribut viewBox, et contiendra les éléments <path/> de l’icône (ou d’autres éléments graphiques).

J’appelle sprite ce document SVG en référence aux sprites dans les jeux vidéos et CSS, mais on pourrait aussi bien l’appeler sprite sheet (feuille de sprites) ou symbol store (entrepôt de symboles).

Voici un sprite contenant une seule icône : 

<svg xmlns="http://www.w3.org/2000/svg"> <symbol id="cross" viewBox="0 0 20 20"> <path d="M17.1 5.2l-2.6-2.6-4.6 4.7-4.7-4.7-2.5 2.6 4.7 4.7-4.7 4.7 2.5 2.5 4.7-4.7 4.6 4.7 2.6-2.5-4.7-4.7"/> </symbol>
</svg>

Ajouter une icône à notre sprite

Imaginons qu’Illustrator nous ait donné ce code pour une nouvelle icône : 

<?xml version="1.0" encoding="utf-8"?> <!-- Generator: Adobe Illustrator 19.2.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) --> <svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 15 15" style="enable-background:new 0 0 15 15;" xml:space="preserve"> <path id="ARROW" d="M7.5,0.5c3.9,0,7,3.1,7,7c0,3.9-3.1,7-7,7c-3.9,0-7-3.1-7-7l0,0C0.5,3.6,3.6,0.5,7.5,0.5 C7.5,0.5,7.5,0.5,7.5,0.5L7.5,0.5L7.5,0.5z M6.1,4.7v5.6l4.2-2.8L6.1,4.7z"/>
</svg>

Nous pouvons la simplifier (manuellement ou via SVGOMG), en ne conservant que l’attribut viewBox et les données essentielles : 

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 15 15"> <path d="M7.5,0.5c3.9,0,7,3.1,7,7c0,3.9-3.1,7-7,7c-3.9,0-7-3.1-7-7l0,0C0.5,3.6,3.6,0.5,7.5,0.5 C7.5,0.5,7.5,0.5,7.5,0.5L7.5,0.5L7.5,0.5z M6.1,4.7v5.6l4.2-2.8L6.1,4.7z"/>
</svg>

Nous pouvons maintenant la copier/coller dans notre sprite. Nous devons transformer l’élément <svg viewBox="…"> en élément <symbol id="…" viewBox="…"> et l’insérer manuellement dans notre sprite : 

<svg xmlns="http://www.w3.org/2000/svg"> <symbol id="cross" viewBox="0 0 20 20"> <path d="M17.1 5.2l-2.6-2.6-4.6 4.7-4.7-4.7-2.5 2.6 4.7 4.7-4.7 4.7 2.5 2.5 4.7-4.7 4.6 4.7 2.6-2.5-4.7-4.7"/> </symbol> <symbol id="play" viewBox="0 0 15 15"> <path d="M7.5,0.5c3.9,0,7,3.1,7,7c0,3.9-3.1,7-7,7c-3.9,0-7-3.1-7-7l0,0C0.5,3.6,3.6,0.5,7.5,0.5 C7.5,0.5,7.5,0.5,7.5,0.5L7.5,0.5L7.5,0.5z M6.1,4.7v5.6l4.2-2.8L6.1,4.7z"/> </symbol>
</svg>

On peut le faire à la main pour chaque icône, mais il existe des outils permettant d’automatiser le processus. Nous utilisons gulg-svg-sprite (voici un exemple réel de fichier gulpfile.js si vous êtes curieux), mais il y a d’autres outils graphiques ou en ligne qui exportent les sprites de symboles SVG, dont Icomoon.

Astuce : Créez un dossier pour vos icônes sources

Si vous réalisez vos sprites manuellement, je vous recommande de créer un dossier contenant chaque icône : 

assets/ icons/ cross.svg play.svg search.svg ...
public/ sprite/ icons.svg

Par la suite, si vous devez reconstruire le icons.svg ou modifier une icône individuelle, vous avez les sources pour travailler. Veillez à ne pas laisser votre sprite et votre dossier source désynchronisés.

Évidemment, si vous utilisez un build process (avec Grunt ou Gulp ou autre), vous pouvez lui donner votre dossier source et le laisser créer le sprite directement.

Ajouter les icônes à votre page

La mauvaise nouvelle est que si nous voulons utiliser nos icônes SVG, nous devons les intégrer au HTML. Pas de backgrounds CSS, pas de pseudo-éléments ::before. La bonne nouvelle, c’est que ce n’est pas du tout verbeux : 

<svg><use xlink:href="/path/to/icons.svg#play"></use></svg>
une icone play simple, triangle blanc sur disque noir

Fournir un texte alternatif

Il existe plusieurs façons d’ajouter un texte alternatif à une icône. Sur la base de nos test de lecteurs d’écran, voici celle que nous utilisons pour une meilleure accessibilité.

Tout d’abord, si nous ne voulons pas ajouter de texte alternatif (en général parce qu’il y a déjà un texte suffisant dans le contexte), nous utilisons aria-hidden="true" pour garantir que les lecteurs d’écran ne liront pas l’icône à haute voix : 

<a href="/news/"> <svg aria-hidden="true"> <use xlink:href="/path/to/icons.svg#newspaper"></use> </svg> Latest News
</a>

Le second cas d’usage ressemble à ceci : nous avons un lien ou un bouton dont le seul contenu est une icône. Dans ce cas, nous utilisons aria-label, de préférence sur l’élément <a> ou <button> : 

<a href="/news/" aria-label="Latest News"> <svg aria-hidden="true"> <use xlink:href="/path/to/icons.svg#newspaper"></use> </svg>
</a>

Une autre option consiste à utiliser l’élément <title>. Il est particulièrement utile en dehors des éléments interactifs (où aria-label pourrait ne pas être lu par les lecteurs d’écran). Par exemple, si vous montrez des marqueurs oui/non (type “hirondelle” ou croix) dans une colonne de tableau, vous pourriez avoir : 

<td> <svg> <title>Yes</title> <use xlink:href="/path/to/icons.svg#tick"></use> </svg>
</td>

Enfin, n’oubliez pas que :

  • votre texte accessible peut changer selon le contexte (une icône “loupe” peut signifier “montrer le formulaire de recherche” dans un contexte, et “envoyer ma requête” dans un autre).
  • votre texte accessible doit changer lorsque la langue de votre page est modifiée.

C’est pourquoi votre texte alternatif doit être situé dans le HTML où est inséré votre icône. Certains articles recommandent de mettre les éléments <title> dans votre sprite, mais en pratique ça ne fonctionne pas — et de plus la plupart des lecteurs d’écran les ignoreront.

Sprites externes et en ligne

Jusqu’à présent nous avons montré des exemples de sprite externe. Mais certains navigateurs anciens — en particulier les WebKits anciens et toutes les versions d’Internet Explorer (avant Edge 13) — ne supportent les références en ligne que pour <use xlink:href="#some-id"/>.

On peut utiliser un polyfill pour cela (svg4everybody, svgxuse). Ou bien, vous pouvez choisir d’inclure votre sprite dans le code HTML de chaque page. 

<body> <!-- Données cachées --> <svg aria-hidden="true" style="display:none"> <symbol id="icon-play">…</symbol> <symbol id="icon-cross">…</symbol> <symbol id="icon-search">…</symbol> </svg> <!-- Une icône visible : --> <button aria-label="Start playback"> <svg aria-hidden="true"><use xlink:href="#icon-play"/></svg> </button>
</body>

Chaque méthode a ses pour et ses contre :

Sprite en ligne Sprite externe
Support navigateur

Support natif in IE9+.

Safari/WebKit ancien mettre le sprite au début de la page (avant toute référence).

Support natif dans Edge 13+, Safari 9+.

IE Safari/WebKit anciens, utiliser un polyfill comme svg4everybody or svgxuse.

Chargement d’un sprite externe depuis un domaine différent impossible (même avec CORS, voir Chromium bug p.ex.). Polyfill possible avec svgxuse.
Cache

Pas de cache.

Le poids de votre sprite (5KB, 15KB, 50KB…) est ajouté à chaque page.

Le sprite est un fichier séparé et peut être mise en cache par le navigateur.

De plus il ne gonfle pas votre cache HTTP côté serveur.
Vitesse de rendu

Rendu instantané des icônes.

Sur les réseaux lents, le rendu de la structure et du contenu de la page peut être retardé si vous avez un sprite SVG lourd inséré avant votre contenu.

Attention au FONSI! (Flash of No SVG Icons, mais bon, cet acronyme est une blague, à ne pas réutiliser ok ?)

Les icônes peuvent apparaître avec un petit retard parce que (a) elles requièrent une requête HTTP séparée et (b) le navigateur n’a pas considéré le chargement de ce fichier comme une priorité (via son look-ahead pre-parser).
Mises à jour

Quand vous mettez à jour votre sprite, vous devez vous assurer qu’il est ajouté à chaque page. Soit en régénérant toutes les pages HTML si vous utilisez un générateur statique, soit en invalidant tous les caches.

Seul un fichier public est modifié, donc la gestion des mises à jour et du cache côté-client est plus facile.

J’aime bien combiner les deux méthodes, en créant deux sprites :

  1. un petit, contenant les icônes essentielles (p.ex. les icônes principales utilisées dans le header), à insérer en ligne dans chaque page. Taille cible : 5KB ou moins.
  2. un plus grand, contenant toutes les icônes du projet, et conservé comme un fichier externe. Taille cible : 50KB ou moins.

Sur de plus gros projets, on pourrait ajouter d’autres sprites externes lorsque certaines icônes peuvent être regroupées et ne sont utilisées que dans une partie du site pour des fonctionnalités spécifiques.

Appliquer des styles CSS aux icônes

OK, nous avons nos icônes et nos sprites SVG, nous savons comment ajouter des icônes à notre HTML et ça nous a pris un bon bout de temps, pouvons-nous enfin passer au style ?

Bien sûr, je vous mets juste une ou deux classes d’abord

Vous pourriez sélectionner tous les éléments <svg> dans CSS mais ce n’est pas idéal si vous utilisez SVG pour plusieurs icônes. De plus, il y a un bug connu de Firefox qui pourrait vous jouer des tours si faisions comme cela (voir plus bas), donc évitons.

À la place, je recommande d’ajouter deux classes pour chaque icône : une générique et une portant le nom de l’icône.

<svg class="Icon Icon--arrow" aria-hidden="true"> <use xlink:href="/path/to/icons.svg#arrow"></use>
</svg>

Nous utilisons les conventions de nommage SUIT CSS, mais vous pouvez utiliser un style différent (par exemple class="icon-arrow" est plus court et il peut être ciblé sur toutes les icônes via un sélecteur comme svg[class*="icon-"]).  NdT : pour plus d’infos sur le ciblage via les sélecteurs ou les attributs, voir l’article Attribut du Dico CSS.

Style d’icône par défaut

Je recommande ce style par défaut pour vos icônes : 

.Icon { /* Permet de redimensionner en changeant la font-size de l’icône */ width: 1em; height: 1em; /* Bel alignement visuel des icônes avec le texte */ vertical-align: -0.15em; /* fill par défaut = valeur de la propriété couleur de son élément parent */ fill: currentColor; /* Les paths et les strokes qui dépassent de la viewBox peuvent apparaître dans IE. Si vous utilisez normalize.css, inutile de l’ajouter. */ overflow: hidden;
}
Icônes avec notre style par défaut. la seule différence entre la rangée du haut et celle du bas est la font-size et la couleur du container.

Ensuite, si vous voulez personnaliser une icône dans un contexte spécifique, vous pouvez ajouter des styles comme ceux-ci : 

.MyComponent-button .Icon { /* Modifier la largeur et la hauteur */ font-size: 40px; /* Changer la couleur de remplissage (fill) */ color: purple; /* Changer l’alignement vertical si vous avez besoin de plus de précision (parfois nécessaire pour un rendu parfait au pixel près) */ vertical-align: top;
}

Avec ce code, vos icônes SVG devraient être petites par défaut et utiliser la couleur du texte de l’élément parent.

Si les formes de l’icône n’héritent pas de la couleur du texte de l’élément parent (currentColor), vérifiez que vous n’avez pas des attributs fill dans le code de votre icône.

Styles SVG hérités

De nombreuses propriétés de style SVG sont héritées. Par exemple lorsque nous fixons la propriété CSS fill sur notre élément <svg> conteneur, elle se propage à notre <path>, <circle> et autres éléments graphiques.

Nous pouvons utiliser cette technique pour d’autres propriétés CSS SVG, par exemple les propriétés stroke : 

.Icon--goldstar { fill: gold; stroke: coral; stroke-width: 5%; stroke-linejoin: round;
}
Icône d’étoile, avec les styles par défaut et personnalisé.

La plupart du temps nous ne changerons pas grand chose : uniquement la propriété fill pour la couleur principale et parfois nous ajouterons ou modifierons une stroke (un peu comme une bordure).

Deux couleurs de remplissage par icône

Voici une technique assez simple pour permettre à une icône d’avoir deux chemins avec deux valeurs de fill (autrement dit deux couleurs). 

<symbol id="check" viewBox="0 0 20 20"> <!-- héritera de la valeur de la propriété CSS fill --> <path d="…" /> <!-- héritera de la valeur de la propriété CSS color --> <path fill="currentColor" d="…" />
</symbol>

...et le CSS :

.Icon--twoColors { fill: rebeccapurple; color: mediumturquoise;
}
Des icônes en deux couleurs.

Laisser un peu d’espace pour les traits

Vous vous rappelez ce que nous disions à propos de l’espace à laisser autour de nos formes ? C’est d’autant plus important si vous utilisez les strokes (les traits, dont on peut régler l’épaisseur). 

.Icon--strokespace { fill: none; stroke: currentColor; stroke-width: 5%;
}

Dans SVG, les strokes sont peints des deux côtés du chemin. Si votre chemin touche les limites du viewport, la moitié du chemin sera coupée, faute d’avoir laissé un espace autour de la forme.

Dans cet exemple, la première icône n’a pas d’espace réservé sur les côtés, la seconde en a un peu (0.5px pour un viewport de 15px).

Utiliser des pourcentages pour stroke-width

Donner l’épaisseur correcte à un trait peut relever du défi. Regardez ces deux exemples dans lesquels nous utilisons stroke-width:1px sur l’élément <svg> :

Deux icônes en forme de coeur avec deux traits d’épaisseur différente

Que se passe-t-il ? La propriété stroke-width accepte une valeur de "longueur" mais cette valeur est relative aux coordonnées locales de votre icône. Dans les exemples ci-dessus :

  1. la première icône a une viewBox de 20px × 20px. Donc un trait de 1px a une épaisseur de 1/20e de la taille de l’icône, c’est important mais pas trop grand.
  2. la deuxième icône a une viewBox de 500px × 500px, et donc un stroke de 1px a une épaisseur de 1/500e de la taille de l’icône, et c’est vraiment très petit.

Si toutes nos icônes utilisent une viewbox identique, ce n’est pas un problème. Par contre, si elles diffèrent grandement, qu’elles utilisent des pixels ou des valeurs sans unité (stroke-width:1), on est mal. Que faire ?

Les pourcentages peuvent nous aider. Le même exemple avec stroke-width:5%.

Deux icônes en forme de coeur avec des traits de même épaisseur

Voilà qui est mieux. Pour les icônes carrées, stroke-width:N% marchera parfaitement, mais remarquez qu’il peut se comporter différemment pour les éléments SVG larges ou hauts, voyez la partie avancée ci-dessous.

Tout n’est pas icône

Ce n’est pas parce que vous avez un SVG qu’il doit obligatoirement se retrouver dans un sprite. Par exemple :

  • les illustrations que vous n’avez pas besoin de styler : utilisez plutôt l’élément <img>
  • les illustrations que vous voulez animer : insérez plutôt le <svg> en ligne dans votre page, de façon à pouvoir sélectionner et styler des groupes spécifiques ou des chemins ou des formes, animer certaines parties, etc.

Une bonne règle générale pourrait être que si c’est une grande illustration que vous devez afficher à 100px × 100px ou plus, ou si elle contient des dizaines d’éléments, ce n’est pas une “icône”.

Sujets avancés et astuces

Nous avons vu dans la section précédente tout ce dont vous avez besoin pour utiliser les icônes SVG. Cette section avancée ajoute des informations plus complexes.

Éviter les grandes icônes non stylées

Que se passe-t-il si votre feuille de style principale ne se charge pas parce que l’utilisateur a une connexion peu fiable, par exemple dans un train (ça m’arrive tout le temps) ? La page peut toujours s’afficher sans styles. Si vous avez une structure HTML correcte, la page sera lisible mais vos icônes apparaîtront vraiment trop grandes.

Les navigateurs récents dimensionnent l’élément svg à 300px par 150px par défaut. D’autres navigateurs peuvent leur donner une largeur géante de 100% !

Je recommande d’insérer ceci dans la partie <head> de vos pages : 

<style>.Icon{width:1em;height:1em}</style>

Bref & concis.

Précharger les sprites externes

Dans la section Ajouter des icônes à vos pages, nous avons dit que les icônes chargées depuis un sprite externe peuvent apparaître avec un temps de retard, entre autres parce que le scan de préchargement du navigateur (ou look-ahead ou pre-parser) ne comprend pas que <use xlink:href="/path/to/icons.svg#something"></use> signifie que nous avons un fichier important à charger le plus tôt possible.

Que faire pour y remédier ?

  • solution standard (et future) : ajoutez <link rel="preload" href="/path/to/icons.svg" as="image"> dans la partie <head> de la page (détails sur preload, compatible bientôt dans tous les bons Chromes proches de chez vous et espérons-le dans les autres navigateurs par la suite).
  • solution vieille école : ajoutez <img style="display:none" alt="" src="/path/to/icons.svg"> au début de votre <body>.

Je n’ai pas testé ces solutions, en général le compromis “en ligne + externe” donne des performances suffisamment bonnes pour qu’on n’ait pas à recourir au préchargement. Mais ça vaudrait de le coup d’y regarder de plus près.

Sélectionner les formes et chemins individuels

Nous avons vu comment personnaliser les fills et les strokes pour tous les chemins d’un <symbol> et deux ou plus de couleurs de différents chemins. Mais il serait intéressant de pouvoir sélectionner des chemins spécifiques (en utilisant des classes, peut-être ?) directement dans l’instance du <symbol>. Est-ce possible ?

Là, maintenant, la réponse est : oui et non.

  1. Si vous utilisez des sprites externes, vous ne pouvez pas sélectionner de chemins individuels (ou d’autres éléments) à l’intérieur d’un <symbol> utilisé.
  2. Si votre sprite est en ligne, vous pouvez sélectionner et styler des éléments à l’intérieur du sprite, mais ces styles s’appliqueront à toutes les instances des symboles.

Donc, même avec un sprite en ligne, vous pourriez faire ceci : 

#my-symbol .style1 { /* Styles pour un groupe de chemins */
}
#my-symbol .style2 { /* Styles pour un autre groupe */
}

Mais pas cela : 

.MyComponent-button .Icon .style1 { /* Pour 1 groupe de chemins pour cette icône dans ce contexte */
}
.MyComponent-button .Icon .style2 { /* Styles pour un autre groupe */
}

Sauf dans Firefox ! Il se trouve que dans Firefox la sélection à l’intérieur d’une instance du symbole fonctionne parfaitement. Le seul problème est que c’est un comportement non standard, donc il n’y a aucune chance que les autres navigateurs s’alignent. En fait, il serait même souhaitable que FF corrige ce bug.

À l’avenir, il y aura peut-être une façon standard de sélectionner via le shadow DOM, mais ce n’est pas sûr du tout (il existait un combinateur /deep/ mais il a été supprimé).

Plus de deux couleurs avec des propriétés CSS personnalisées

Comme nous l’avons vu, nous pouvons facilement changer les couleurs de nos icônes SVG à partir de CSS pour des icônes monochromes (c’est facile) et en bichromie (ça demande une petite préparation). Existe-t-il une façon de réaliser des icônes multicolores avec plus de deux couleurs personnalisables ?

Nous pourrions y parvenir avec les propriétés CSS personnalisées (également connues comme Variables CSS). Cela demande une petite préparation du côté de notre SVG : 

<symbol id="iconic-aperture" viewBox="0 0 128 128"> <path fill="var(--icon-color1)" d="…" /> <path fill="var(--icon-color2)" d="…" /> <path fill="var(--icon-color3)" d="…" /> <path fill="var(--icon-color4)" d="…" /> <path fill="var(--icon-color5)" d="…" /> <path fill="var(--icon-color6)" d="…" />
</symbol>

Pour cette démo, j’ai emprunté une icône de l’excellent Iconic, qui offre des icônes SVG responsives et multicolores (alimentées par CSS et du JavaScript, si je comprends bien). J’ai essayé d’imiter leur exemple multicolore pour cette icône, j’espère qu’ils ne m’en voudront pas.

Un symbole utilisant six propriétés CSS personnalisées. Fonctionne avec Firefox, Chrome ou Safari 9.1+

Cela fonctionne assez bien avec les navigateurs compatibles. Il n’y a qu’une seule icône : la première instance ne déclare pas les variables attendues, donc elle se résoud en currentColor. Les deux instances suivantes déclarent chacune un ensemble de valeurs déclarées comme variables.

Comment sont calculés les pourcentages de stroke-with?

À quoi correspond le pourcentage dans stroke-width:N% ? Est-ce la largeur, la hauteur de l’icône ? En fait, c’est la diagonale, mais avec une formule funky (spec) : la diagonale est divisée par la racine carrée de 2, à peu près 1,4.

Qu’est-ce que cela signifie ? Eh bien pour les icônes carrées, le résultat de cette formule est le côté du carré. Donc 1% signifie “un pourcent de la largeur ou un pourcent de la hauteur”. Simple et clair.

Pour les icônes plus larges ou plus hautes cependant le résultat peut être variable :

Dans la seconde icône (ratio d’aspect de 2:1, montré avec la même hauteur et une largeur double), le stroke-width:5% nous donne un stroke de 7,91% de la hauteur et 3,95% de la largeur.

Toutes choses bien considérées, je recommande quand même d’utiliser les valeurs de pourcentage pour stroke-width. Si vous vous en tenez à des icônes carrées, vous pouvez utiliser les valeurs en pourcentage en sachant que grosso modo elles signifient “pourcentage de la largeur de l’icône”.

Désolé, pas de remplissage dégradé

Avec toutes ces possibilités de couleurs de remplissage, nous pouvons certainement réaliser des choses aussi simples qu’utiliser un dégradé comme fill ?

Malheureusement non. La propriété fill n’accepte pas les valeurs d’image, et la fonction CSS linear-gradient() génère une valeur d’image.

SVG a sa propre syntaxe pour coder et utiliser les dégradés. Mais son utilisation nous entraînerait assez loin des icônes SVG simples, donc je dirais juste que cela pourrait se faire, mais ça demanderait du travail et vous auriez à coder au moins quelques paramètres. Essayez si vous voulez :)

Conventions inspirées par les bugs des navigateurs

Safari : évitez les attributs de largeur et hauteur

Pour éviter les icônes géantes dans les pages non stylées, nous nous sommes d’abord appuyés sur les attributs width et height de l’élément <svg> : 

<svg width="20" height="20"> <use xlink:href="…"></use>
</svg>

Puis nous avons testé nos premiers sites web “basés sur les icônes SVG” dans Safari et iOS, et la moitié des icônes étaient corrompues ! Pourquoi ?!??

Il se trouve que Safari/WebKit n’apprécie pas d’avoir des attributs width et height avec une seule dimension, et le code CSS qui essaie de modifier cette dimension par la suite. En particulier lorsqu’on diminue la taille de l’icône, celle-ci rapetisse mais pas le contenu !

Notre solution a été de laisser tomber ces attributs et de nous appuyer sur le seul CSS pour dimensionner les icônes.

Remarquez que ce bug a peut-être été corrigé dans les dernières livraisons de Safari (9.1 pour le desktop, iOS 9.3).

Safari : évitez le padding sur le conteneur svg

Si vous voulez une couleur de background, des bordures, du padding, etc., vous devriez essayer de styler l’élément contenant l’icône et non l’élément <svg> lui-même. Bien que cela semble fonctionner dans les derniers navigateurs, il existe des problèmes connus de rendu dans les versions anciennes de navigateurs WebKit, donc je recommande de styler un élément enveloppant (wrapper, comme <span>, <button>, <a>, etc.).

Styles de boîtes appliqués sur l’élément svg directement ou sur un élément wrapper. La plupart des navigateurs devraient rendre l’élément de la même façon, mais les versions anciennes de WebKit risquent de se fâcher.

 NdT : pour inspecter le code, vous pouvez vous reporter à l’article original, que vous pouvez également consulter en version txt.

Firefox : évitez de cibler l’élément svg

Cela créera des problèmes dans Firefox. Pourquoi ? Lorsque nous utilisons l’élément <use>, les navigateurs créent un shadow DOM (un DOM fantôme) où ils dupliquent les contenus des <symbol> que nous utilisons. Schématiquement, ça ressemble à ceci : 

<svg class="Icon Icon--something" aria-hidden="true"> <use xlink:href="#something"> <svg viewBox="0 0 20 20"> <path d="…" /> </svg> </use>
</svg>

Comme expliqué dans la section précédente, Firefox permet actuellement la sélection dans le shadow DOM créé par l’élément <use>. Donc si vous avez ce CSS ... 

svg { fill: red;
}
.Icon--something { fill: green;
}

...dans Firefox les styles seront :

<svg class="Icon Icon--something" aria-hidden="true" fill="green;"> <use xlink:href="#something"> <svg viewBox="0 0 20 20" fill="red;"> <path d="…" /> </svg> </use>
</svg>

Dans d’autres navigateurs, l’icône sera verte (comme attendu), mais dans Firefox elle sera rouge car l’élément <svg> intérieur prendra les styles du premier ensemble de règles (fill: red).

Une autre façon d’éviter ce bug est d’utiliser ce sélecteur : 

:not(use) > svg { … }

Intéressé par SVG ? Retrouvez une liste des meilleurs articles et ressources du web.

Tous les articles sur SVG parus dans la Cascade.

Tous les articles sur les bases SVG parus dans la Cascade.

Tous les articles sur Sketch3 parus dans la Cascade.

Articles sur les mêmes thèmes dans la Cascade :

Utiliser SVG, par Chris Coyier
SVG, style et animation, par Sara Soueidan
Grunt pour ceux qui pensent que Grunt est compliqué, par Chris Coyier
Gulp pour les débutants, par Zell Liew

Article original paru le 26 mars 2016 dans le blog de Florens Verschelde. Vous pouvez consulter les sources du texte ici.

Sur l’auteur : Florens Verschelde est un professionnel du web, auteur et photographe. On peut le suivre sur twitter et sur son blog.

Traduit avec l’aimable autorisation de l’auteur.
Copyright Florens Verschelde © 2016.

]]> https://la-cascade.io/comment-travailler-avec-des-icones-en-svg/ https://la-cascade.io/comment-travailler-avec-des-icones-en-svg/ Tue, 30 Aug 2016 03:08:00 +0200 <![CDATA[Traduit ailleurs : Traitement de texte multicanal]]> 28 août 2016 · 23 minutes

Comme je l’expliquais dans la mouvance statique, il est important de bien choisir le format de fichier dans lesquels nous allons stocker nos écrits. C’est souvent la solution la plus simple qui est aussi la plus efficace : du texte brut mise en forme à l’aide d’une syntaxe elle aussi en texte brut. Markdown est de ce fait un format de fichier de plus en plus populaire car il assure une pérennité et une compatibilité à nos documents, tout en préservant une mise en forme au format texte. Markdown est le format par défaut des contenus dans la plupart des générateurs de site statique et il devrait devenir aussi le format par défaut dans lequel vous rédigez vos notes, vos rapports, vos articles de blog ou vos livres.

Il existe de nombreux éditeurs de Markdown, j’utilise personnellement selon le contexte l’éditeur Atom et quelques plugins ou iA Writer pour m’y aider.

Les concepteurs d’iA Writer ont rédigé un essai sur l’importance d’utiliser des formats texte comme Markdown. Markdown n’est pas le seul, il y en a d’autres comme reStructuredText, Textile ou Asciidoc mais la popularité de Markdown est grandissante depuis quelques années.

Tendance des recherches du terme Markdown dans Google

Aussi ai-je pensé que la lecture instructive de cet essai, qui revient sur les enjeux et les problématiques auxquels nous sommes tous confrontés quand il s’agit de migrer des contenus textuels devrait vous intéresser.

J’espère que ce texte vous donnera envie de tester et d’adopter Markdown, de trouver les outils d’édition qui vous conviennent le mieux et surtout que vos écrits ne dépendront plus de formats qui les emprisonnent.

Traduction de l’essai Multichannel Text Processing paru chez Information Architects.

Du bon vieux temps des traitements de texte, le texte prenait vie entre MS Word et une imprimante. Aujourd’hui, le texte est écrit et édité sur différents appareils et applications, puis envoyé par mail, imprimé, copié, collé, annoté, publié, indexé dans des flux RSS, partagé et re-partagé à l’aide de tout un tas d’outils et de plateformes. Les formats de fichiers propriétaires rigides sont voués à l’échec dans ce nouvel environnement frénétique. Le texte brut s’en sort mieux, mais il n’offre pas les possibilités de mise en forme du texte enrichi. Markdown pourrait bien être notre remède miracle. Si seulement, il avait l’air un peu plus attractif !.

1. Le texte enrichi

Le texte enrichi comme MS Word ou le format .rtf sont devenus populaires en faisant la promesse du WYSIWYG (What You See Is What You Get). Nous pouvons utiliser le gras, l’italique, différentes polices ou mises en forme et nous voyons immédiatement le résultat sur notre écran ! Lors de son apparition ce fut une véritable révolution comparé aux encombrants éditeurs qui affichaient des fenêtres de formatage de code ou à ceux qui ne proposaient pas de mise en forme du tout. Cependant, il y a quelques inconvénients.

Comparaison des deux formats de fichier

Au format texte brut, le texte est la source. Avec le texte enrichi, ce que nous voyons est une simulation. Ce que nous voyons peut nous plaire, mais sous la surface, notre traitement de texte génère en secret un texte encodé bien plus complexe. Vous pouvez visiter ce monde enfoui en créant un document Pages ou Word, tapez “Bonjour monde” et sauvegardez, puis changez l’extension de fichier en .zip et décompressez l’archive. Bienvenue en 1979 !1

Contenu d’un fichier Word

Si vous êtes assez téméraires pour aller inspecter le contenu du dossier généré, vous allez peut-être commencer à vous demander si vous avez tapé “Bonjour monde” ou “Bonjour l’enfer” :

fenêtres montrant du code source de fichiers texte au format XML

Les formats personnalisés sont plus lourds que les formats en texte brut. Le souci majeur de ces formats personnalisés est que la relation entre le code source et le texte — entre ce que nous voyons et ce que nous ne voyons pas — est fantasque. Voici ce que vous obtenez vraiment quand vous travaillez avec ces formats en 2016 :

Des bugs et des problèmes d’ergonomie Comment sortir d’une liste ou supprimer une indentation ? Comment supprimer un lien ? Comment supprimer cette mise en gras, cet espacement de ligne ou cette taille de titre ? Et comment diable placer deux images côte à côte ? Parfois on ne sait plus très bien si nous sommes face à une anomalie ou une erreur d’ergonomie du logiciel.

Spaghettis de copier-coller Le principal souci avec les formats personnalisés dans un environnement de publication multicanal est qu’ils empêchent le copier-coller. Nous copions un simple paragraphe à partir d’un fichier PDF et quand on le colle dans notre email, le texte en français se transforme en Western spaghetti italien dramatique avec tout un tas d’espaces et de retours à la ligne. Et cela ne concerne pas que le PDF. Avec le texte formaté nous ne savons jamais ce que nous obtiendrons lorsque nous allons coller notre texte.

Compatibilité Bien que le .rtf soit un format assez établi et que la plupart des traitements de texte lisent les .docx, des applications diverses interpréteront ces formats différemment. Vous ne pouvez pas ajouter de texte au format RTF ou Docx de manière fiable dans votre CMS. Et n’imaginez même pas pouvoir aller et venir à votre aise d’un CMS à un document Word.

Versions Exporter se fait peut être en un clic, mais décliner votre texte en plusieurs versions complique votre processus de travail. Les retours ou les propositions de modification ne peuvent pas être incorporés facilement dans un fichier principal. Gérer ces versions devient rapidement un cauchemar.

Accessibilité Le format texte enrichi ne vous permet pas de toucher à la source de votre document. Peut-être que le texte est dans un dossier qui prétend être un fichier ou caché quelque part “à l’abri de l’utilisateur”, enfoui dans les profondeurs de dossiers de code spaghetti ou chiffré dans le Fort Know d’une base de données secrète.

Bien entendu, en tant qu’homme d’affaires vous aimez les chaînes dorées des formats personnalisés. En tant que personne qui écrit du texte en 2016, en utilisant différents appareils, applications, plateformes et formats, vous ne les aimez pas du tout. Après tout, qui sait quel sera notre ressenti vis à vis des .docx dans 10 ans ? Et dans 30 ans ?

Même si les logiciels de traitement de texte modernes peuvent faire des trucs super — comme ajouter des graphiques, des tableaux et des images, en appliquant des styles sophistiqués — il y a une chose qu’ils ne savent pas faire : garantir que les mots que j’écris aujourd’hui seront encore lisibles dans dix ans. C’est une des raisons pour lesquelles je préfère travailler en texte brut : c’est éternel. Mes petits-enfants pourront lire un fichier texte que j’ai écrit aujourd’hui, longtemps après que quelqu’un se souvienne ce que diable est un fichier .dotx 2

Dans l’environnement de texte multicanal d’aujourd’hui le format de fichier texte enrichi crée plus de barrières qu’à l’époque où les choses étaient plus simples. Le fait de devoir installer une certaine version d’une application sur une certaine version d’un système d’exploitation pour ouvrir un fichier est une vaste fumisterie. Pour pouvoir être partagé entre différentes applications et plateformes, le texte lui-même doit être libéré des carcans d’une application, d’une plateforme ou d’un appareil.

2. Le texte brut

Le seul format de fichier qui fonctionne partout comme prévu, c’est pas de format du tout, en d’autres termes : du texte brut. Et c’est de tout ce dont nous avons besoin pour écrire nos premiers brouillons.

Le texte brut désigne des mots séparés par des espaces, des phrases séparées par des points, des paragraphes séparés en général par une seul retour à la ligne. Si vous travaillez dans l’édition ou même dans l’édition en ligne, c’est souvent tout ce dont vous avez besoin.3

Le texte brut est simple. Il vous aide à vous concentrer ce que vous voulez dire.

Le texte brut est gratuit. TextPad, TextEdit, Vim, votre téléphone cellulaire, l’application AOL Mail 1997 de votre oncle… pas besoin de sortir le porte-monnaie.

Le texte brut est léger.

Le texte brut s’écoule comme de l’eau. Mais contrairement à l’eau, il n’étanche pas toutes les soifs. Que ce soit pour l’impression, un article de blog, un PDF, un email ou même un fax, à un moment ou à un autre, le texte va devoir prendre forme sur un médium approprié pour être lu. Comme nos mots prennent forme à l’intérieur d’un medium, ils exigent une structure visuelle. Les documents d’entreprise ont besoin d’en-têtes, de pieds de page et de pages de couverture. Certains textes ne prennent vie que lorsque ils sont illustrés et enrichis avec des photos, des vidéos ou des tableaux. Nous voulons des liens quand nous écrivons en ligne. Nous avons besoin de notes de bas de page dans un livre blanc.

La transition du texte brut au texte formaté est généralement brusque et irréversible. Vous écrivez dans TextEdit ou Notepad, mais une fois que vous vous passez en RTF, docx ou HTML il n’y a plus de retour en arrière possible. Mais le texte veut naturellement et lentement se transformer à partir de simples mots en de la prose formatée . C’est là que Markdown entre en scène.

3. Markdown

Les langages de balisage, comme Markdown, MediaWiki ou LaTeX, vous permettent de structurer vos mots sans construire un royaume invisible sous le text brut. Hélas…

3.1 Markdown ça craint !

Vous avez peut être essayé d’écrire du Markdown ou de modifier une entrée dans Wikipédia et vous avez détesté ça, parce que vous vous demandiez “Mais pourquoi devrais-je apprendre une nouvelle ‘syntaxe’ pour formater du texte quand j’ai un outil qui fait ça en appuyant sur un bouton et qui me montre exactement ce que j’obtiendrais ?”4 Et vous avez raison :

  • Baliser du texte peut vous éviter des problèmes de copier-coller mais le Markdown brut a toujours l’air compliqué,
  • Bien que Markdown soit plus simple que le HTML, vous devez toujours vous souvenir de la syntaxe et rechercher à chaque fois comment ajouter un lien vous sort de votre flux,
  • Balisage, Markdown, MultiMachin… ces formats ont leur propres problèmes de compatibilité.

Markdown n’est pas la solution parfaite pour tous les types de rédacteurs ou toutes les formes et les étapes d’écriture. Mais si vous tout faîtes vous-même, de la prise de notes à la publication, c’est la solution la plus efficace à ce jour. Si votre éditeur vous impose des outils de rédaction, Markdown est une option moins évidente. Mais encore une fois, la possibilité de pouvoir partager plus simplement qu’avec les formats de fichier traditionnels rend la collaboration considérablement plus fluide…

3.2 Un plaidoyer pour Markdown

Considérations esthétiques mises à part, Markdown est imbattable quand vous n’avez besoin que de mise en gras ou d’italique. Taper #, ## ou ### pour les différents niveaux de titre peut paraître un peu bizarre au début. Mais une fois appris, taper des dièses est plus simple et plus rapide que de retirer les mains de votre clavier, repérer le pointeur de la souris, sélectionner un morceau de texte et cliquer sur le menu déroulant WYSIWYG des styles pour choisir le bon niveau de titre. Et contrairement à ses satanés formats de styles, les dièses se comportent toujours comment ils le devraient.

Si vous connaissez ces trois choses, *, ** et #, vous en savez assez sur Markdown pour vous lancer. Et plus vous serez à l’aise avec Markdown, moins il y aura de friction dans votre procédé global d’écriture. Voyons ensemble quelques défis plus difficiles :

Les liens

Les liens Markdown peuvent complètement ruiner l’aspect de votre texte. C’est utile de voir les liens dans le texte et pouvoir se passer de clics droits et de fenêtres intrusives, mais si vous utilisez beaucoup trop de liens dans un texte, c’est affreux. Une manière de contourner le problème est d’utiliser le format des liens de références. Un autre pourrait être de masquer les liens dans l’éditeur, mais cela reviendrait à reproduire les problèmes du texte enrichi.

Avoir plus de libertés avec les images dans le texte est cool. Si vous voulez un logiciel qui permet de parfaitement mettre en page les images, utilisez InDesign, ou faites-le dans votre CMS. N’essayez pas avec Word et n’allez pas croire que votre éditeur de Markdown fera tout aussi bien qu’il vous aide à trouver vos mots. Oui, vous pouvez utiliser Markdown dans InDesign.5

Les tableaux en texte brut ont mauvaise réputation. S’ils sont complexes, c’est vrai qu’ils ont l’air affreux. Mais pour quelques lignes et colonnes ils marchent bien : contrairement à Word, vous voyez exactement ce qui se passe. (Si vous faites des tableaux avancés Word est votre ennemi, utilisez toujours un tableur comme Excel ou Numbers). Ils sont pénibles à créer, mais avec un peu de magie…

Automatisation

Avec le format MultiMarkdown6 (une version améliorée de Markdown) vous pouvez créer des tables des matières automatiquement et à l’aide des variables de métadonnées vous pouvez même créer des modèles de lettres. Okay, ça a l’air hardcore. Et c’est hardcore. Mais vous devriez essayer. Vous n’avez pas besoin d’être un hacker ninja rockstar pour comprendre les bases. Et une fois que vous comprenez les bases, cela devient plus facile de générer une table des matières en MultiMarkdown que dans MS Word.

Notes de bas de page

MultiMarkdown gère aussi les notes de bas de page. La syntaxe est un petit peu lourdingue comme pour les liens mais c’est aussi abscond dans les éditeurs de texte enrichi. Avec un éditeur de Markdown qui propose un fonction aperçu vous pouvez apprendre la syntaxe tout en écrivant cliquant.

Plus vous maîtriserez Markdown, plus vous passerez rapidement et facilement du texte brut au texte formaté. C’est là où Markdown excelle : en comblant le fossé entre le texte brut et le texte enrichi, il vous permet de constamment modeler le texte — de la première note prise au hasard jusqu’à la publication multicanale.

Rendu en temps réel

Il existe différentes manières d’améliorer le rendu de Markdown, comme en en masquant certaines parties, mais si vous générez le rendu du Markdown dans le texte, WYSIWYG, vous réintroduisez tous les problèmes qui rendent les éditeurs de texte enrichi obsolètes et vous en ajoutez de nouveaux. Si vous essayez de faire tout ce que sait faire Word avec Markdown, vous allez créer un nouveau Word avec un langage qui n’est pas fait pour le WYSIWYG. C’est pour cette raison qu’iA Writer ne masque aucun caractère Markdown.

4. Un processus de publication moderne

Nous pouvons imaginer que les différentes étapes d’un procédé d’écriture comme étant composées de phases distinctes que nous pouvons contrôler et classer par ordre chronologique. En réalité, nous prenons des notes en amont de l’écriture et nous continuons d’assembler des matériaux jusqu’à la publication. L’édition commence avec le premier brouillon et — pas seulement dans les médias numériques — se poursuit bien après la publication.7

Distinguer les étapes d’un procédé créatif est nécessaire mais les processus de travail agiles ne ressemblent pas à une cascade : ils se chevauchent, interagissent, s’influencent mutuellement et notre écriture et nos outils de publication devraient nous permettre d’aller et venir comme nous le souhaitons.8 L’écriture est espiègle par nature.

Écrire en étant concentré ne veut pas dire écrire avec des œillères, cela signifie que votre attention est principalement dirigée sur un seul aspect du procédé global. Il peut être même utile d’aller et venir consciemment entre deux étapes voisines. Markdown vous permet de ne pas vous soucier de ces transitions.

4.1 Écrire et prévisualiser

Aller et venir entre les différentes étapes d’un procédé est nécessaire et rafraîchissant. Si vous aimez travaillez dans un éditeur WYSIWYG ou imprimer votre texte de temps en temps, ou regarder l’aperçu sur votre blog avant de publier, vous savez déjà que : un formatage défini nous aide à nous mettre à la place du lecteur du texte. Voir notre texte imprimé change la perception que nous avons de lui. Vous obtenez le même effet quand vous sortez du Markdown pour aller regarder l’aperçu du rendu de votre texte en HTML.

Écrire et prévisualiser

L’effet n’est peut être pas aussi frappant que le passage de l’écran au papier, mais il laisse entrevoir la forme du texte à venir. Avec le sentiment de la façon dont un lecteur verra votre texte, vous pouvez revenir à votre texte avec des yeux neufs. C’est plus rapide car cela évite l’exercice chronophage de devoir retaper les corrections manuscrites.

Le passage conscient entre le texte brut et le texte formaté vous laisse imaginer comment le texte sera lu par une personne externe.

4.2 Modifier et publier

Le même changement de perspective se produit quand vous passez de la vue back-end de votre texte à la vue front-end — après avoir migré le contenu dans votre CMS.

Si vous écrivez déjà vos textes en Markdown, assurez vous que vos outils de publication vous permettent d’éditer le texte brut sans perdre toute la mise en forme. Vous n’avez pas besoin de passer à un CMS basé sur des fichiers Markdown. Si vous utilisez Wordpress, vous pouvez utiliser un plugin Markdown pour l’éditeur. Ça aide si les applications que vous utilisez permettent la publication sur différentes plateformes tout de go. C’est pour cela qu’iA Writer vous permet de publier directement sur Wordpress et Medium :

Publier directement depuis votre application d’écriture est cool. Mais l’important c’est de pouvoir copier-coller votre texte ici et là sans perdre votre travail. À moins que vous ne soyez un génie du procédé de travail, vous aurez toujours besoin d’ajouter quelques touches finales dans Indesign, Wordpress ou Pages. À quoi bon utiliser un outil de publication qui ne vous laisse pas faire les choses qu’un traitement de texte ne sait pas faire ?

Conclusion

Nous utilisons différents appareils pour prendre des notes, différentes applications pour créer des brouillons et faire des modifications, nous envoyons du texte à d’autres personnes et nous utilisons différentes plateformes pour mettre en forme et publier nos textes. Le procédé de production et la forme finale de notre texte sont plus difficiles à anticiper. Nous avons besoin de quelque chose de mieux que les formats de texte traditionnels, qui nous enferment dans un cadre format/application/plateforme/appareil défini, pour faire face à la réalité complexe d’aujourd’hui pour ce qui est de la mise en forme et de la publication.

De par son universalité et sa simplicité, le texte brut nous emmène plus loin que tout autre type de format. Et pourtant, les éditeurs de texte brut ne sont pas fait pour visualiser la structure du texte, optimiser des mises en page complexes, batailler avec des détails typographiques ou lier entre eux des corps de texte. Ils sont géniaux pour vous aider à trouver les bons mots, mais ont du mal lorsque le texte devient plus long. Un procédé d’écriture contemporain doit nous permettre d’aller et venir librement entre le text brut et le texte mis en forme, grâce à des processus de travail automatisés ou du copier-coller.

Pour le moment les langages de balisage légers comme Markdown sont les seuls à permettre cela. Markdown peut avoir l’air un peu brouillon et oui, tout un tas d’améliorations sont possibles et nécessaires. Malgré ces lacunes, il résout des problèmes méthodiques complexes, là où la séparation entre le texte brut et le texte mis en forme échoue. Cela nous permet de pouvoir utiliser notre texte et le fichier qui le contient partout, indépendamment de l’appareil, de la plateforme ou de l’application. Le moment où vous passez du texte à la mise en forme, du conditionnement au contenu, du corps de texte à la mise en page, doit être une phase où vous pouvez aller et venir à votre guise. Markdown rend cela possible.

Si vous vous voulez des mises en forme plus complexes comme les liens, les images, les notes de bas de page et une table des matières, utilisez l’interface ou les raccourcis clavier. Pour améliorer vos compétences en Markdown avec la syntaxe plus avancée, faites vous aider par un éditeur qui propose un aperçu en temps réel. Cela vous donne aussi un aperçu de la mise en forme très tôt et vous permet d’utiliser un balisage plus complexe car vous pouvez identifier rapidement n’importe quelle erreur.

L’automatisation entre un service en ligne, une application de prise de notes, un éditeur de texte et un environnement de publication est cool, mais pas essentiel. Ce qui est fondamental, c’est la capacité de pouvoir copier-coller votre texte à loisir sans perdre de mise en forme ou d’information. Seul le format texte brut garantie cela. Configurez vos plateformes de publication pour interpréter le Markdown, de manière à pouvoir vous balader librement entre l’écriture, la modification et la publication. Il y a plusieurs manières et plusieurs applications pour y parvenir. Et c’est précisément l’idée. Le texte brut est léger et gratuit et doit le rester. Évitez les applications qui veulent vous enchaîner.

]]> https://frank.taillandier.me/2016/08/28/traitement-de-texte-multicanal/ https://frank.taillandier.me/2016/08/28/traitement-de-texte-multicanal/ Tue, 30 Aug 2016 03:08:00 +0200 <![CDATA[De l'audit de contenu aux idées de design : : Comment un audit de contenu facilite le processus de décision et influence la stratégie de design]]>

Par Christopher Detzi

Tout au long de ma carrière, j’ai généralement compris la valeur apportée par un audit de contenu (qu’on le fasse ou qu’on en bénéficie) dans le cadre du redesign d’un site web. Un audit de contenu est une évaluation du contenu d’un site, à la fois, d’un point de vue quantitatif (par exemple “Combien de contenu est présent ?”) et qualitatif (par exemple “Est-ce qu’il est bon ?”). Par contre, ce qui n’est souvent pas bien discuté ou compris à propos des audits de contenu ce sont les bénéfices significatifs qu’ils procurent au delà de la simple évaluation de quantité et de qualité.

Dans un projet récent sur lequel j’ai travaillé, l’audit de contenu a été crucial pour faciliter les discussions stratégiques sur la direction du design. Ces conversations auraient été beaucoup plus difficiles sans avoir l’audit de contenu complet. Nous avons utiliser l’audit de plusieurs façons, chacune très importante pour guider nos efforts :

  • Révéler la vraie ampleur du contenu du site (il y en avait moins que nous le pensions)
  • Clarifier et affiner la portée du projet (le point clé a été différent de celui auquel nous nous attendions)
  • Faciliter les discussions stratégiques sur les objectifs de design et la direction (qui étaient différents de ceux que les parties prenantes avaient imaginées)
  • Établir un langage commun à toute l’équipe pour la durée du projet (cela s’est révélé plus compliqué que nous l’avions anticipé)

Je vais utiliser ce projet comme modèle pour mettre en évidence comment mener et utiliser les audits de contenu dans le contexte d’un projet de redesign de site web.

Le Projet

La tâche était immense : revigorer et rendre pertinent un intranet poussiéreux pour les employés qui avait été une décharge à contenus sans réglementation pendant dix ans. La négligence de longue date avait fait des ravages et les utilisateurs du site avaient tout simplement arrêté de l’utiliser. Les problèmes étaient évidents :

  • Les employés ne pouvaient pas trouver les informations dont ils avaient besoin,
  • Les informations qu’ils trouvaient n’étaient pas à jour ou pas pertinentes,
  • Le contenu était catégorisé, structuré et affiché de façon incohérente,
  • Les employés allaient ailleurs pour trouver ce dont ils avaient besoin.

Le processus

Un audit de contenu commence avec un catalogue (ou un inventaire) du contenu du site. Cela peut être un processus laborieux et chronophage suivant le volume de contenu qui se trouve sur la site. Beaucoup de designers avec lesquels j’ai travaillé admettent à contrecœur la valeur de cette activité mais elle se retrouve mise de côté parce qu’elle est perçue comme un investissement en temps trop important par rapport à sa valeur. D’une manière ou d’une autre, cette perception est exacte. Un inventaire du contenu du site sur un tableur n’est qu’un amas de données brutes. Il n’indique pas grand chose sur le contenu au delà de ce qui s’y trouve. Le travail difficile et, finalement, le bénéfice dépendent de la découverte de pépites de sagesse qui se trouvent dans les données brutes.

Nous pouvons faire cela en utilisant l’audit de contenu comme plate-forme pour faciliter des conversations souvent difficiles avec les parties prenantes sur la mission du site, les priorités des utilisateurs et les contraintes et opportunités opérationnelles.

Il existe de nombreuses façons de découper et analyser le contenu d’un site web pour faciliter ces discussions et éclairer les décisions de design. Voici les domaines que je considère être les plus efficaces dans le contexte d’un redesign de site web :

Identifier et documenter le volume et le type des contenus

Au début de tout redesign, il y a souvent de grandes exagérations par rapport au volume de contenu dont il faudra s’occuper. Ces opinions ont tendance à provoquer de l’anxiété, à accabler les membres de l’équipe et elles sont souvent la raison pour laquelle la perspective de finir des audits de contenu est très rapidement écartée. Avoir des données sur le volume réel de contenu donne un nombre réel que tous les membres de l’équipe peuvent considérer objectivement et utiliser pour la planification.

Sur ce projet d’intranet, nous avons immédiatement réalisé que les chiffres avaient été grandement surestimés. Le site était gros mais pas aussi gros que tout le monde le pensait. Plus de 60% des “pages” étaient, en fait, des fichiers PDF ou Microsoft Office, dont une grande partie étaient des duplicatas de pages HTML existantes. Cette découverte a aidé à clarifier l’ampleur de notre tâche.

Une fois que nous avons trié et récolté le contenu du site, l’étape suivante était de l’utiliser pour faciliter les discussions sur les plans futurs pour le contenu :

  • Tout ce contenu est-il encore pertinent ? Quels besoins d’affaire, de client ou d’employé aide-t-il à résoudre ?
  • Quels nouveaux contenus devront être créés dans les prochains mois ? D’où viennent ces besoins ?
  • Qu’est-ce qui motive les décisions sur les types de fichiers et/ou les variations existantes de format ? Est-ce que ces décisions sont encore d’actualité ?

Identifier et documenter la structure actuelle du contenu

Il y a toujours un semblant de structure, même sur les sites mal conçus. Créer des représentations visuelles de ces structures et de leurs principes d’organisation révèle souvent des problèmes ou des bizarreries qui pourront aider à orienter vers la solution de conception.

Sur le projet d’intranet, nous avons découverts que l’organisation du contenu avait été mal conçue et n’était pas adaptée aux réalités opérationnelles. Par exemple, il y avait neuf aires de contenu, par ailleurs, plus de 50% du contenu était dans une seule de ces aires. Cette distribution déséquilibrée créait trop de couches de navigation et contribuait à une mauvaise expérience de découverte et de retour vers les contenus.

Une fois que vous avez une représentation visuelle de la façon dont le contenu est structuré et organisé, vous pouvez l’utiliser pour faciliter les discussions suivantes :

  • Pourquoi le contenu a-t-il été organisé de cette façon ? Qu’est-ce qui a initialement conduit à prendre ces décisions ?
  • Quelles informations ont été difficiles à classer et à organiser dans ce système ?
  • Quels sont les types de contenu les plus importants par rapport aux objectifs commerciaux ?
  • Qu’est-ce que les gens vous ont dit à propos de l’organisation actuelle du contenu ?

Déterminer si le contenu est utilisé

Avoir l’inventaire de contenu (URLs de production incluses) donnent une carte et un point de référence pour les statistiques du site. Même si ces rapports peuvent parfois être mal interprétés, ils donnent une idée générale de l’utilisation ou de la non-utilisation actuelle du site et indique les contenus les plus souvent utilisés.

Dans le projet d’intranet, nous avons utilisé ces rapports pour améliorer les résultats de nos entretiens avec les utilisateurs. Par exemple. les utilisateurs n’ont pas exprimés le désir de comprendre l’organisation hiérarchique ou la structure de présentation des résultats, pourtant, les vues et les téléchargements d’organigrammes étaient élevées. Ce sont des données importantes à prendre en compte pour le design.

Ces données peuvent être utilisées pour avoir des discussions franches à propos de ce qui est utile et de ce qui ne l’est pas sur le site.

  • Quels contenus sont rarement utilisés ? Peut-on en tirer des conclusions définitives ?
  • Que nous apprend la popularité de certains contenus sur les personnes qui utilisent le site ? Peut-on étendre et améliorer ces contenus pour leur en donner encore plus ?
  • Comment peut-on structurer le design pour faciliter l’accès aux informations que l’on sait importantes ?
  • Y-a-t-il des manières de révéler la pertinence du contenu qui n’est pas utilisé pour le moment ?

Documenter la présentation incohérente du contenu

Un problème commun avec les sites négligés ou mal gérés est le niveau d’incohérence dans le design et la présentation du contenu. Faire des copies d’écran d’une large palette de pages et de types de présentation pendant votre audit est une très bonne manière de rendre compte des incohérences et d’identifier des opportunités de consolidation.

Dans le projet d’intranet, nous avons montré une large sélection de captures d’écran et ensuite montré comment la structure de contenu pouvait être normalisée au niveau de la présentation, éliminant les incohérences et les variations inutiles. Nous avons fait cela en identifiant les attributs communs des contenus, même si leur présentation variait grandement.

Passer du temps à capturer et annoter les captures d’écran tôt dans le projet est essentiel pour des discussions productives à propos des réalités opérationnelles et la future direction de design. Utiliser ces outils pour répondre aux questions suivantes :

  • Y-a-t-il une raison pour que des contenus similaires soient présentés différemment ? Parfois, il existe des raisons commerciales légitimes, telles que s’aligner sur du matériel de communication hors ligne.
  • Où les efforts de consolidations ont-ils mal tourné ? Qu’est-ce qui cause ces incohérences en dehors du manque de sensibilisation ?

Les résultats

Dans le projet d’intranet, ce processus a permis de nombreuses réalisations qui ont mené directement à des décisions de design, parmi les plus notables :

Une conscience aiguë des priorités

Savoir quels sont les contenus qui sont sur le site, pourquoi, et lesquels sont vraiment utilisés est essentiel pour comprendre les priorités. L’audit a facilité les conversations et donner forme aux questions à propos de l’utilité et l’utilisation du contenu qui n’auraient pas été aussi fructueuses ou révélatrices.

Contraintes opérationnelles et commerciales

Les contraintes opérationnelles et d’affaires sont souvent révélées au travers du processus d’audit. Dans ce projet, il y avait clairement des contraintes opérationnelles qui limitaient les solutions de design que nous pouvions proposer. Par exemple, alors que les parties prenantes appréciaient le concept d’une page d’accueil orientée sur les nouvelles fraîches, ils n’avaient pas les capacités de faire des mises à jour régulières. Les évaluations et discussions de suivi ont révélé ces contraintes plus clairement que si nous n’avions pas entrepris l’audit. Et ces discussions ont formé notre approche du design, nous assurant ainsi que nos recommandations n’entraient pas en conflit avec les réalités opérationnelles.

Un langage commun

Les audits peuvent révéler un langage et une terminologie spécifiques à l’organisation qui seront peu familiers pour les personnes de l’extérieur. Dans ce projet, le contenu était hermétique pour de multiples raisons et l’audit nous a aidé à décoder le contenu et à établir une compréhension commune des concepts. Ainsi, les revues de design étaient moins abstraites et s’alignaient plus précisément avec la manière dont les équipes internes pensaient et parlaient du contenu. De plus, nous avons été en mesure de réutiliser du contenu existant dans nos prototypes pour révéler des décisions structurelles et, où cela s’est avéré nécessaire, écrire de la copie représentative destinée à servir de guide dans les futurs développement de contenu.

Un vrai sens de l’échelle

Le site était certainement gros, mais pas de la façon dont tout le monde ou nous le pensions. Nous avons acquis une perspective nuancée du contenu, comprenant que nous ne parlions pas d’un site de 10 000 pages. Cela a changé la manière dont nous avons pensé au design, au nombre de pages, et aux variations de design des types de contenus dont nous devions tenir compte. Cette prise de conscience a aussi apporté une saine dose d’objectivité aux conversations et calmé un grand nombre d’anxiétés causées (en grande partie) par nos incertitudes.

Si on les aborde correctement, les audits de contenu sont des outils d’une puissance exceptionnelle. Au delà de l’évaluation de la quantité et de la qualité du contenu, ils aident les concepteurs à comprendre l’environnement informationnel, facilitent les discussions stratégiques et permettent la découverte d’informations qui ont directement influencés la direction du design et la stratégie. En résumé, nous avons augmenté les chances de succès de notre redesign en approchant les audits en gardant ces buts à l’esprit.

]]> http://www.pompage.net/traduction/de-l-audit-de-contenu-aux-idees-de-design http://www.pompage.net/traduction/de-l-audit-de-contenu-aux-idees-de-design Wed, 21 Oct 2015 08:10:00 +0200 <![CDATA[De l'audit de contenu aux idées de design : : Comment un audit de contenu facilite le processus de décision et influence la stratégie de design]]>

Par Christopher Detzi

Tout au long de ma carrière, j’ai généralement compris la valeur apportée par un audit de contenu (qu’on le fasse ou qu’on en bénéficie) dans le cadre du redesign d’un site web. Un audit de contenu est une évaluation du contenu d’un site, à la fois, d’un point de vue quantitatif (par exemple “Combien de contenu est présent ?”) et qualitatif (par exemple “Est-ce qu’il est bon ?”). Par contre, ce qui n’est souvent pas bien discuté ou compris à propos des audits de contenu ce sont les bénéfices significatifs qu’ils procurent au delà de la simple évaluation de quantité et de qualité.

Dans un projet récent sur lequel j’ai travaillé, l’audit de contenu a été crucial pour faciliter les discussions stratégiques sur la direction du design. Ces conversations auraient été beaucoup plus difficiles sans avoir l’audit de contenu complet. Nous avons utiliser l’audit de plusieurs façons, chacune très importante pour guider nos efforts :

  • Révéler la vraie ampleur du contenu du site (il y en avait moins que nous le pensions)
  • Clarifier et affiner la portée du projet (le point clé a été différent de celui auquel nous nous attendions)
  • Faciliter les discussions stratégiques sur les objectifs de design et la direction (qui étaient différents de ceux que les parties prenantes avaient imaginées)
  • Établir un langage commun à toute l’équipe pour la durée du projet (cela s’est révélé plus compliqué que nous l’avions anticipé)

Je vais utiliser ce projet comme modèle pour mettre en évidence comment mener et utiliser les audits de contenu dans le contexte d’un projet de redesign de site web.

Le Projet

La tâche était immense : revigorer et rendre pertinent un intranet poussiéreux pour les employés qui avait été une décharge à contenus sans réglementation pendant dix ans. La négligence de longue date avait fait des ravages et les utilisateurs du site avaient tout simplement arrêté de l’utiliser. Les problèmes étaient évidents :

  • Les employés ne pouvaient pas trouver les informations dont ils avaient besoin,
  • Les informations qu’ils trouvaient n’étaient pas à jour ou pas pertinentes,
  • Le contenu était catégorisé, structuré et affiché de façon incohérente,
  • Les employés allaient ailleurs pour trouver ce dont ils avaient besoin.

Le processus

Un audit de contenu commence avec un catalogue (ou un inventaire) du contenu du site. Cela peut être un processus laborieux et chronophage suivant le volume de contenu qui se trouve sur la site. Beaucoup de designers avec lesquels j’ai travaillé admettent à contrecœur la valeur de cette activité mais elle se retrouve mise de côté parce qu’elle est perçue comme un investissement en temps trop important par rapport à sa valeur. D’une manière ou d’une autre, cette perception est exacte. Un inventaire du contenu du site sur un tableur n’est qu’un amas de données brutes. Il n’indique pas grand chose sur le contenu au delà de ce qui s’y trouve. Le travail difficile et, finalement, le bénéfice dépendent de la découverte de pépites de sagesse qui se trouvent dans les données brutes.

Nous pouvons faire cela en utilisant l’audit de contenu comme plate-forme pour faciliter des conversations souvent difficiles avec les parties prenantes sur la mission du site, les priorités des utilisateurs et les contraintes et opportunités opérationnelles.

Il existe de nombreuses façons de découper et analyser le contenu d’un site web pour faciliter ces discussions et éclairer les décisions de design. Voici les domaines que je considère être les plus efficaces dans le contexte d’un redesign de site web :

Identifier et documenter le volume et le type des contenus

Au début de tout redesign, il y a souvent de grandes exagérations par rapport au volume de contenu dont il faudra s’occuper. Ces opinions ont tendance à provoquer de l’anxiété, à accabler les membres de l’équipe et elles sont souvent la raison pour laquelle la perspective de finir des audits de contenu est très rapidement écartée. Avoir des données sur le volume réel de contenu donne un nombre réel que tous les membres de l’équipe peuvent considérer objectivement et utiliser pour la planification.

Sur ce projet d’intranet, nous avons immédiatement réalisé que les chiffres avaient été grandement surestimés. Le site était gros mais pas aussi gros que tout le monde le pensait. Plus de 60% des “pages” étaient, en fait, des fichiers PDF ou Microsoft Office, dont une grande partie étaient des duplicatas de pages HTML existantes. Cette découverte a aidé à clarifier l’ampleur de notre tâche.

Une fois que nous avons trié et récolté le contenu du site, l’étape suivante était de l’utiliser pour faciliter les discussions sur les plans futurs pour le contenu :

  • Tout ce contenu est-il encore pertinent ? Quels besoins d’affaire, de client ou d’employé aide-t-il à résoudre ?
  • Quels nouveaux contenus devront être créés dans les prochains mois ? D’où viennent ces besoins ?
  • Qu’est-ce qui motive les décisions sur les types de fichiers et/ou les variations existantes de format ? Est-ce que ces décisions sont encore d’actualité ?

Identifier et documenter la structure actuelle du contenu

Il y a toujours un semblant de structure, même sur les sites mal conçus. Créer des représentations visuelles de ces structures et de leurs principes d’organisation révèle souvent des problèmes ou des bizarreries qui pourront aider à orienter vers la solution de conception.

Sur le projet d’intranet, nous avons découverts que l’organisation du contenu avait été mal conçue et n’était pas adaptée aux réalités opérationnelles. Par exemple, il y avait neuf aires de contenu, par ailleurs, plus de 50% du contenu était dans une seule de ces aires. Cette distribution déséquilibrée créait trop de couches de navigation et contribuait à une mauvaise expérience de découverte et de retour vers les contenus.

Une fois que vous avez une représentation visuelle de la façon dont le contenu est structuré et organisé, vous pouvez l’utiliser pour faciliter les discussions suivantes :

  • Pourquoi le contenu a-t-il été organisé de cette façon ? Qu’est-ce qui a initialement conduit à prendre ces décisions ?
  • Quelles informations ont été difficiles à classer et à organiser dans ce système ?
  • Quels sont les types de contenu les plus importants par rapport aux objectifs commerciaux ?
  • Qu’est-ce que les gens vous ont dit à propos de l’organisation actuelle du contenu ?

Déterminer si le contenu est utilisé

Avoir l’inventaire de contenu (URLs de production incluses) donnent une carte et un point de référence pour les statistiques du site. Même si ces rapports peuvent parfois être mal interprétés, ils donnent une idée générale de l’utilisation ou de la non-utilisation actuelle du site et indique les contenus les plus souvent utilisés.

Dans le projet d’intranet, nous avons utilisé ces rapports pour améliorer les résultats de nos entretiens avec les utilisateurs. Par exemple. les utilisateurs n’ont pas exprimés le désir de comprendre l’organisation hiérarchique ou la structure de présentation des résultats, pourtant, les vues et les téléchargements d’organigrammes étaient élevées. Ce sont des données importantes à prendre en compte pour le design.

Ces données peuvent être utilisées pour avoir des discussions franches à propos de ce qui est utile et de ce qui ne l’est pas sur le site.

  • Quels contenus sont rarement utilisés ? Peut-on en tirer des conclusions définitives ?
  • Que nous apprend la popularité de certains contenus sur les personnes qui utilisent le site ? Peut-on étendre et améliorer ces contenus pour leur en donner encore plus ?
  • Comment peut-on structurer le design pour faciliter l’accès aux informations que l’on sait importantes ?
  • Y-a-t-il des manières de révéler la pertinence du contenu qui n’est pas utilisé pour le moment ?

Documenter la présentation incohérente du contenu

Un problème commun avec les sites négligés ou mal gérés est le niveau d’incohérence dans le design et la présentation du contenu. Faire des copies d’écran d’une large palette de pages et de types de présentation pendant votre audit est une très bonne manière de rendre compte des incohérences et d’identifier des opportunités de consolidation.

Dans le projet d’intranet, nous avons montré une large sélection de captures d’écran et ensuite montré comment la structure de contenu pouvait être normalisée au niveau de la présentation, éliminant les incohérences et les variations inutiles. Nous avons fait cela en identifiant les attributs communs des contenus, même si leur présentation variait grandement.

Passer du temps à capturer et annoter les captures d’écran tôt dans le projet est essentiel pour des discussions productives à propos des réalités opérationnelles et la future direction de design. Utiliser ces outils pour répondre aux questions suivantes :

  • Y-a-t-il une raison pour que des contenus similaires soient présentés différemment ? Parfois, il existe des raisons commerciales légitimes, telles que s’aligner sur du matériel de communication hors ligne.
  • Où les efforts de consolidations ont-ils mal tourné ? Qu’est-ce qui cause ces incohérences en dehors du manque de sensibilisation ?

Les résultats

Dans le projet d’intranet, ce processus a permis de nombreuses réalisations qui ont mené directement à des décisions de design, parmi les plus notables :

Une conscience aiguë des priorités

Savoir quels sont les contenus qui sont sur le site, pourquoi, et lesquels sont vraiment utilisés est essentiel pour comprendre les priorités. L’audit a facilité les conversations et donner forme aux questions à propos de l’utilité et l’utilisation du contenu qui n’auraient pas été aussi fructueuses ou révélatrices.

Contraintes opérationnelles et commerciales

Les contraintes opérationnelles et d’affaires sont souvent révélées au travers du processus d’audit. Dans ce projet, il y avait clairement des contraintes opérationnelles qui limitaient les solutions de design que nous pouvions proposer. Par exemple, alors que les parties prenantes appréciaient le concept d’une page d’accueil orientée sur les nouvelles fraîches, ils n’avaient pas les capacités de faire des mises à jour régulières. Les évaluations et discussions de suivi ont révélé ces contraintes plus clairement que si nous n’avions pas entrepris l’audit. Et ces discussions ont formé notre approche du design, nous assurant ainsi que nos recommandations n’entraient pas en conflit avec les réalités opérationnelles.

Un langage commun

Les audits peuvent révéler un langage et une terminologie spécifiques à l’organisation qui seront peu familiers pour les personnes de l’extérieur. Dans ce projet, le contenu était hermétique pour de multiples raisons et l’audit nous a aidé à décoder le contenu et à établir une compréhension commune des concepts. Ainsi, les revues de design étaient moins abstraites et s’alignaient plus précisément avec la manière dont les équipes internes pensaient et parlaient du contenu. De plus, nous avons été en mesure de réutiliser du contenu existant dans nos prototypes pour révéler des décisions structurelles et, où cela s’est avéré nécessaire, écrire de la copie représentative destinée à servir de guide dans les futurs développement de contenu.

Un vrai sens de l’échelle

Le site était certainement gros, mais pas de la façon dont tout le monde ou nous le pensions. Nous avons acquis une perspective nuancée du contenu, comprenant que nous ne parlions pas d’un site de 10 000 pages. Cela a changé la manière dont nous avons pensé au design, au nombre de pages, et aux variations de design des types de contenus dont nous devions tenir compte. Cette prise de conscience a aussi apporté une saine dose d’objectivité aux conversations et calmé un grand nombre d’anxiétés causées (en grande partie) par nos incertitudes.

Si on les aborde correctement, les audits de contenu sont des outils d’une puissance exceptionnelle. Au delà de l’évaluation de la quantité et de la qualité du contenu, ils aident les concepteurs à comprendre l’environnement informationnel, facilitent les discussions stratégiques et permettent la découverte d’informations qui ont directement influencés la direction du design et la stratégie. En résumé, nous avons augmenté les chances de succès de notre redesign en approchant les audits en gardant ces buts à l’esprit.

]]> http://www.pompage.net/traduction/de-l-audit-de-contenu-aux-idees-de-design http://www.pompage.net/traduction/de-l-audit-de-contenu-aux-idees-de-design Wed, 21 Oct 2015 08:10:00 +0200 <![CDATA[De l'audit de contenu aux idées de design : : Comment un audit de contenu facilite le processus de décision et influence la stratégie de design]]>

Par Christopher Detzi

Tout au long de ma carrière, j’ai généralement compris la valeur apportée par un audit de contenu (qu’on le fasse ou qu’on en bénéficie) dans le cadre du redesign d’un site web. Un audit de contenu est une évaluation du contenu d’un site, à la fois, d’un point de vue quantitatif (par exemple “Combien de contenu est présent ?”) et qualitatif (par exemple “Est-ce qu’il est bon ?”). Par contre, ce qui n’est souvent pas bien discuté ou compris à propos des audits de contenu ce sont les bénéfices significatifs qu’ils procurent au delà de la simple évaluation de quantité et de qualité.

Dans un projet récent sur lequel j’ai travaillé, l’audit de contenu a été crucial pour faciliter les discussions stratégiques sur la direction du design. Ces conversations auraient été beaucoup plus difficiles sans avoir l’audit de contenu complet. Nous avons utiliser l’audit de plusieurs façons, chacune très importante pour guider nos efforts :

  • Révéler la vraie ampleur du contenu du site (il y en avait moins que nous le pensions)
  • Clarifier et affiner la portée du projet (le point clé a été différent de celui auquel nous nous attendions)
  • Faciliter les discussions stratégiques sur les objectifs de design et la direction (qui étaient différents de ceux que les parties prenantes avaient imaginées)
  • Établir un langage commun à toute l’équipe pour la durée du projet (cela s’est révélé plus compliqué que nous l’avions anticipé)

Je vais utiliser ce projet comme modèle pour mettre en évidence comment mener et utiliser les audits de contenu dans le contexte d’un projet de redesign de site web.

Le Projet

La tâche était immense : revigorer et rendre pertinent un intranet poussiéreux pour les employés qui avait été une décharge à contenus sans réglementation pendant dix ans. La négligence de longue date avait fait des ravages et les utilisateurs du site avaient tout simplement arrêté de l’utiliser. Les problèmes étaient évidents :

  • Les employés ne pouvaient pas trouver les informations dont ils avaient besoin,
  • Les informations qu’ils trouvaient n’étaient pas à jour ou pas pertinentes,
  • Le contenu était catégorisé, structuré et affiché de façon incohérente,
  • Les employés allaient ailleurs pour trouver ce dont ils avaient besoin.

Le processus

Un audit de contenu commence avec un catalogue (ou un inventaire) du contenu du site. Cela peut être un processus laborieux et chronophage suivant le volume de contenu qui se trouve sur la site. Beaucoup de designers avec lesquels j’ai travaillé admettent à contrecœur la valeur de cette activité mais elle se retrouve mise de côté parce qu’elle est perçue comme un investissement en temps trop important par rapport à sa valeur. D’une manière ou d’une autre, cette perception est exacte. Un inventaire du contenu du site sur un tableur n’est qu’un amas de données brutes. Il n’indique pas grand chose sur le contenu au delà de ce qui s’y trouve. Le travail difficile et, finalement, le bénéfice dépendent de la découverte de pépites de sagesse qui se trouvent dans les données brutes.

Nous pouvons faire cela en utilisant l’audit de contenu comme plate-forme pour faciliter des conversations souvent difficiles avec les parties prenantes sur la mission du site, les priorités des utilisateurs et les contraintes et opportunités opérationnelles.

Il existe de nombreuses façons de découper et analyser le contenu d’un site web pour faciliter ces discussions et éclairer les décisions de design. Voici les domaines que je considère être les plus efficaces dans le contexte d’un redesign de site web :

Identifier et documenter le volume et le type des contenus

Au début de tout redesign, il y a souvent de grandes exagérations par rapport au volume de contenu dont il faudra s’occuper. Ces opinions ont tendance à provoquer de l’anxiété, à accabler les membres de l’équipe et elles sont souvent la raison pour laquelle la perspective de finir des audits de contenu est très rapidement écartée. Avoir des données sur le volume réel de contenu donne un nombre réel que tous les membres de l’équipe peuvent considérer objectivement et utiliser pour la planification.

Sur ce projet d’intranet, nous avons immédiatement réalisé que les chiffres avaient été grandement surestimés. Le site était gros mais pas aussi gros que tout le monde le pensait. Plus de 60% des “pages” étaient, en fait, des fichiers PDF ou Microsoft Office, dont une grande partie étaient des duplicatas de pages HTML existantes. Cette découverte a aidé à clarifier l’ampleur de notre tâche.

Une fois que nous avons trié et récolté le contenu du site, l’étape suivante était de l’utiliser pour faciliter les discussions sur les plans futurs pour le contenu :

  • Tout ce contenu est-il encore pertinent ? Quels besoins d’affaire, de client ou d’employé aide-t-il à résoudre ?
  • Quels nouveaux contenus devront être créés dans les prochains mois ? D’où viennent ces besoins ?
  • Qu’est-ce qui motive les décisions sur les types de fichiers et/ou les variations existantes de format ? Est-ce que ces décisions sont encore d’actualité ?

Identifier et documenter la structure actuelle du contenu

Il y a toujours un semblant de structure, même sur les sites mal conçus. Créer des représentations visuelles de ces structures et de leurs principes d’organisation révèle souvent des problèmes ou des bizarreries qui pourront aider à orienter vers la solution de conception.

Sur le projet d’intranet, nous avons découverts que l’organisation du contenu avait été mal conçue et n’était pas adaptée aux réalités opérationnelles. Par exemple, il y avait neuf aires de contenu, par ailleurs, plus de 50% du contenu était dans une seule de ces aires. Cette distribution déséquilibrée créait trop de couches de navigation et contribuait à une mauvaise expérience de découverte et de retour vers les contenus.

Une fois que vous avez une représentation visuelle de la façon dont le contenu est structuré et organisé, vous pouvez l’utiliser pour faciliter les discussions suivantes :

  • Pourquoi le contenu a-t-il été organisé de cette façon ? Qu’est-ce qui a initialement conduit à prendre ces décisions ?
  • Quelles informations ont été difficiles à classer et à organiser dans ce système ?
  • Quels sont les types de contenu les plus importants par rapport aux objectifs commerciaux ?
  • Qu’est-ce que les gens vous ont dit à propos de l’organisation actuelle du contenu ?

Déterminer si le contenu est utilisé

Avoir l’inventaire de contenu (URLs de production incluses) donnent une carte et un point de référence pour les statistiques du site. Même si ces rapports peuvent parfois être mal interprétés, ils donnent une idée générale de l’utilisation ou de la non-utilisation actuelle du site et indique les contenus les plus souvent utilisés.

Dans le projet d’intranet, nous avons utilisé ces rapports pour améliorer les résultats de nos entretiens avec les utilisateurs. Par exemple. les utilisateurs n’ont pas exprimés le désir de comprendre l’organisation hiérarchique ou la structure de présentation des résultats, pourtant, les vues et les téléchargements d’organigrammes étaient élevées. Ce sont des données importantes à prendre en compte pour le design.

Ces données peuvent être utilisées pour avoir des discussions franches à propos de ce qui est utile et de ce qui ne l’est pas sur le site.

  • Quels contenus sont rarement utilisés ? Peut-on en tirer des conclusions définitives ?
  • Que nous apprend la popularité de certains contenus sur les personnes qui utilisent le site ? Peut-on étendre et améliorer ces contenus pour leur en donner encore plus ?
  • Comment peut-on structurer le design pour faciliter l’accès aux informations que l’on sait importantes ?
  • Y-a-t-il des manières de révéler la pertinence du contenu qui n’est pas utilisé pour le moment ?

Documenter la présentation incohérente du contenu

Un problème commun avec les sites négligés ou mal gérés est le niveau d’incohérence dans le design et la présentation du contenu. Faire des copies d’écran d’une large palette de pages et de types de présentation pendant votre audit est une très bonne manière de rendre compte des incohérences et d’identifier des opportunités de consolidation.

Dans le projet d’intranet, nous avons montré une large sélection de captures d’écran et ensuite montré comment la structure de contenu pouvait être normalisée au niveau de la présentation, éliminant les incohérences et les variations inutiles. Nous avons fait cela en identifiant les attributs communs des contenus, même si leur présentation variait grandement.

Passer du temps à capturer et annoter les captures d’écran tôt dans le projet est essentiel pour des discussions productives à propos des réalités opérationnelles et la future direction de design. Utiliser ces outils pour répondre aux questions suivantes :

  • Y-a-t-il une raison pour que des contenus similaires soient présentés différemment ? Parfois, il existe des raisons commerciales légitimes, telles que s’aligner sur du matériel de communication hors ligne.
  • Où les efforts de consolidations ont-ils mal tourné ? Qu’est-ce qui cause ces incohérences en dehors du manque de sensibilisation ?

Les résultats

Dans le projet d’intranet, ce processus a permis de nombreuses réalisations qui ont mené directement à des décisions de design, parmi les plus notables :

Une conscience aiguë des priorités

Savoir quels sont les contenus qui sont sur le site, pourquoi, et lesquels sont vraiment utilisés est essentiel pour comprendre les priorités. L’audit a facilité les conversations et donner forme aux questions à propos de l’utilité et l’utilisation du contenu qui n’auraient pas été aussi fructueuses ou révélatrices.

Contraintes opérationnelles et commerciales

Les contraintes opérationnelles et d’affaires sont souvent révélées au travers du processus d’audit. Dans ce projet, il y avait clairement des contraintes opérationnelles qui limitaient les solutions de design que nous pouvions proposer. Par exemple, alors que les parties prenantes appréciaient le concept d’une page d’accueil orientée sur les nouvelles fraîches, ils n’avaient pas les capacités de faire des mises à jour régulières. Les évaluations et discussions de suivi ont révélé ces contraintes plus clairement que si nous n’avions pas entrepris l’audit. Et ces discussions ont formé notre approche du design, nous assurant ainsi que nos recommandations n’entraient pas en conflit avec les réalités opérationnelles.

Un langage commun

Les audits peuvent révéler un langage et une terminologie spécifiques à l’organisation qui seront peu familiers pour les personnes de l’extérieur. Dans ce projet, le contenu était hermétique pour de multiples raisons et l’audit nous a aidé à décoder le contenu et à établir une compréhension commune des concepts. Ainsi, les revues de design étaient moins abstraites et s’alignaient plus précisément avec la manière dont les équipes internes pensaient et parlaient du contenu. De plus, nous avons été en mesure de réutiliser du contenu existant dans nos prototypes pour révéler des décisions structurelles et, où cela s’est avéré nécessaire, écrire de la copie représentative destinée à servir de guide dans les futurs développement de contenu.

Un vrai sens de l’échelle

Le site était certainement gros, mais pas de la façon dont tout le monde ou nous le pensions. Nous avons acquis une perspective nuancée du contenu, comprenant que nous ne parlions pas d’un site de 10 000 pages. Cela a changé la manière dont nous avons pensé au design, au nombre de pages, et aux variations de design des types de contenus dont nous devions tenir compte. Cette prise de conscience a aussi apporté une saine dose d’objectivité aux conversations et calmé un grand nombre d’anxiétés causées (en grande partie) par nos incertitudes.

Si on les aborde correctement, les audits de contenu sont des outils d’une puissance exceptionnelle. Au delà de l’évaluation de la quantité et de la qualité du contenu, ils aident les concepteurs à comprendre l’environnement informationnel, facilitent les discussions stratégiques et permettent la découverte d’informations qui ont directement influencés la direction du design et la stratégie. En résumé, nous avons augmenté les chances de succès de notre redesign en approchant les audits en gardant ces buts à l’esprit.

]]> https://www.pompage.net/traduction/de-l-audit-de-contenu-aux-idees-de-design https://www.pompage.net/traduction/de-l-audit-de-contenu-aux-idees-de-design Wed, 21 Oct 2015 08:10:00 +0200 <![CDATA[Concevoir un design sans la couleur]]>

Par Mark Boulton

La conception d'un design efficace est une affaire délicate, et souvent rendue plus difficile encore par les choix de couleurs. Pourquoi ne pas imaginer un mode initial de conception qui s'affranchisse totalement de la couleur au profit d'un travail sur les tons?

Faire un design en travaillant sur la couleur, c’est peut-être l’une des choses les plus difficiles à faire dans le domaine du design graphique. Pourquoi ? Parce qu’il n’y a rien de plus subjectif. Certains trouveront génial de choisir une palette de gris sombre avec quelques touches de rose vif, tandis que d’autres trouveront ça très laid. On voit trop souvent des designers prendre des décisions arbitraires sur cette question, qu’ils soient ou non formés à la théorie chromatique, et c’est au moment où ils tentent de justifier ces choix auprès de leurs clients que tout se complique. Dans ce premier article, je vais m’intéresser aux tons et à l’avantage qu’on trouvera à limiter l’étendue de sa palette.

On baisse d’un ton

Il y a quelques années (houlà, ça fait même une bonne quinzaine d’années…) j’étais en première année aux Beaux-Arts, ici à Stockport au Royaume-Uni. Je voulais devenir peintre, ou plus exactement illustrateur. Dès la première semaine, on nous a demandé de nous débarrasser de tous les beaux pinceaux qu’on venait de s’acheter pour les cours. Nous avons donc dû laisser notre matériel tout neuf à la maison, puis aller dehors récolter des brindilles et dénicher de l’encre noire. Je n’étais vraiment pas enthousiaste. Comment imaginer qu’un artiste puisse créer à l’aide d’outils aussi primitifs ? Nos professeurs nous ont donc fait peindre avec des brindilles, puis avec nos pieds, puis les yeux bandés : bref, la totale. À l’époque j’ai trouvé ça nul, et je ne comprenais pas où ils voulaient en venir. Maintenant que j’ai pris du recul, je perçois bien l’intérêt de cet horrible démarrage. Ils nous apprenaient à observer et à produire des œuvres qui n’étaient pas dictées par nos outils. En d’autres termes, si nous avions disposé de couleurs variées et de beaux pinceaux, la tentation de les exploiter aurait été trop grande. Faute de pinceaux et de couleurs, nous avons été contraints de communiquer la notion de couleur uniquement avec des effets de ton.

C’est par cela que je voudrais commencer.

Faisons sans la couleur

L’une des choses que j’apprécie dans le design éditorial, et en particulier dans le design typographique, c’est l’importance du noir et blanc. Bien sûr, la couleur constitue une étape très importante de tout travail typographique, mais je m’intéresse avant tout au ton et à la forme. Je crois qu’il y a tout à gagner à retirer complètement la couleur de l’équation afin de focaliser sur les questions de tonalité d’un design, avant d’y appliquer des couleurs. Quelques exemples notables suffiront à montrer qu’un design basé seulement sur du noir peut être original et attirant.

On ne saurait parler du design web en noir et blanc sans évoquer le site de Khoi Vinh, Subtraction.com. Khoi travaille avec du noir et de l’orange pour correspondre au style suisse du design (ou style typographique international, NdT).


Le site Substraction.com par Khoi Vinh

Form, un magazine de design allemand, utilise une typographie en noir et blanc (basée sur une grille rigoureuse) pour transmettre son concept de marque aux utilisateurs du site. On voit l’effet qui est atteint avec ce noir et blanc : l’ouvrage qui est mis en lumière, avec sa couleur vive, se détache très nettement du cadre noir et blanc.


Le magazine allemand de design Form

D’abord du gris

Faites donc le test pour votre prochain design. Comme indiqué dans le titre, contentez-vous de le démarrer avec du gris en différentes nuances. N’ajoutez aucune couleur tant que vous n’êtes pas satisfait du design en noir et blanc. Il y a de grandes chances que les décisions de palette et de couleurs que vous prendrez seront ensuite beaucoup plus simples, parce que le design ne dépendra plus de la couleur pour fonctionner. C’est particulièrement pertinent si on cherche à créer un design avec une bonne accessibilité. Ce n’est pas le sujet de cet article, puisque je me concentre ici sur le design graphique, mais l’accessibilité reste néanmoins une question qui ne doit pas être négligée. En basant votre design sur le noir et blanc, vous vous assurez que la solution retenue ne dépendra jamais de la couleur.
J’utilise souvent la couleur pour mettre des éléments du design en avant, mais en général ils ont déjà un rôle dans le graphisme retenu, comme par exemple les lignes horizontales du site ci-dessous. On peut aussi imaginer mettre en valeur un bouton de recherche, ou bien les éléments d’une barre de navigation. La couleur sert alors à faire ressortir des éléments fonctionnels cruciaux de l’interface.


On résout d’abord les questions de tons avant d’appliquer de la couleur

Vers des palettes mono- et duo-tonales

Dans mon prochain billet, je vais aller un peu plus loin avec mes gris.
On a quand même de la chance, nous les designers du web. On peut employer pratiquement n’importe quelle couleur. Les designers papier, eux, sont confrontés à des limites sur l’usage des couleurs depuis l’origine de l’imprimerie. Du coup, cela les a rendus très attentifs à ces questions du design en couleur. Je trouve qu’il n’y a rien de plus formateur que de créer des projets à une ou deux couleurs, mais appliquées à un grand nombre de situations, afin de mieux réfléchir à la façon dont la couleur est employée. Je vais essayer d’évoquer cet axe de réflexion (et cette contrainte) dans mon prochain billet.

]]> http://www.pompage.net/traduction/concevoir-un-design-sans-la-couleur http://www.pompage.net/traduction/concevoir-un-design-sans-la-couleur Tue, 09 Sep 2014 10:09:00 +0200 <![CDATA[Concevoir un design sans la couleur]]>

Par Mark Boulton

La conception d'un design efficace est une affaire délicate, et souvent rendue plus difficile encore par les choix de couleurs. Pourquoi ne pas imaginer un mode initial de conception qui s'affranchisse totalement de la couleur au profit d'un travail sur les tons?

Faire un design en travaillant sur la couleur, c’est peut-être l’une des choses les plus difficiles à faire dans le domaine du design graphique. Pourquoi ? Parce qu’il n’y a rien de plus subjectif. Certains trouveront génial de choisir une palette de gris sombre avec quelques touches de rose vif, tandis que d’autres trouveront ça très laid. On voit trop souvent des designers prendre des décisions arbitraires sur cette question, qu’ils soient ou non formés à la théorie chromatique, et c’est au moment où ils tentent de justifier ces choix auprès de leurs clients que tout se complique. Dans ce premier article, je vais m’intéresser aux tons et à l’avantage qu’on trouvera à limiter l’étendue de sa palette.

On baisse d’un ton

Il y a quelques années (houlà, ça fait même une bonne quinzaine d’années…) j’étais en première année aux Beaux-Arts, ici à Stockport au Royaume-Uni. Je voulais devenir peintre, ou plus exactement illustrateur. Dès la première semaine, on nous a demandé de nous débarrasser de tous les beaux pinceaux qu’on venait de s’acheter pour les cours. Nous avons donc dû laisser notre matériel tout neuf à la maison, puis aller dehors récolter des brindilles et dénicher de l’encre noire. Je n’étais vraiment pas enthousiaste. Comment imaginer qu’un artiste puisse créer à l’aide d’outils aussi primitifs ? Nos professeurs nous ont donc fait peindre avec des brindilles, puis avec nos pieds, puis les yeux bandés : bref, la totale. À l’époque j’ai trouvé ça nul, et je ne comprenais pas où ils voulaient en venir. Maintenant que j’ai pris du recul, je perçois bien l’intérêt de cet horrible démarrage. Ils nous apprenaient à observer et à produire des œuvres qui n’étaient pas dictées par nos outils. En d’autres termes, si nous avions disposé de couleurs variées et de beaux pinceaux, la tentation de les exploiter aurait été trop grande. Faute de pinceaux et de couleurs, nous avons été contraints de communiquer la notion de couleur uniquement avec des effets de ton.

C’est par cela que je voudrais commencer.

Faisons sans la couleur

L’une des choses que j’apprécie dans le design éditorial, et en particulier dans le design typographique, c’est l’importance du noir et blanc. Bien sûr, la couleur constitue une étape très importante de tout travail typographique, mais je m’intéresse avant tout au ton et à la forme. Je crois qu’il y a tout à gagner à retirer complètement la couleur de l’équation afin de focaliser sur les questions de tonalité d’un design, avant d’y appliquer des couleurs. Quelques exemples notables suffiront à montrer qu’un design basé seulement sur du noir peut être original et attirant.

On ne saurait parler du design web en noir et blanc sans évoquer le site de Khoi Vinh, Subtraction.com. Khoi travaille avec du noir et de l’orange pour correspondre au style suisse du design (ou style typographique international, NdT).


Le site Substraction.com par Khoi Vinh

Form, un magazine de design allemand, utilise une typographie en noir et blanc (basée sur une grille rigoureuse) pour transmettre son concept de marque aux utilisateurs du site. On voit l’effet qui est atteint avec ce noir et blanc : l’ouvrage qui est mis en lumière, avec sa couleur vive, se détache très nettement du cadre noir et blanc.


Le magazine allemand de design Form

D’abord du gris

Faites donc le test pour votre prochain design. Comme indiqué dans le titre, contentez-vous de le démarrer avec du gris en différentes nuances. N’ajoutez aucune couleur tant que vous n’êtes pas satisfait du design en noir et blanc. Il y a de grandes chances que les décisions de palette et de couleurs que vous prendrez seront ensuite beaucoup plus simples, parce que le design ne dépendra plus de la couleur pour fonctionner. C’est particulièrement pertinent si on cherche à créer un design avec une bonne accessibilité. Ce n’est pas le sujet de cet article, puisque je me concentre ici sur le design graphique, mais l’accessibilité reste néanmoins une question qui ne doit pas être négligée. En basant votre design sur le noir et blanc, vous vous assurez que la solution retenue ne dépendra jamais de la couleur.
J’utilise souvent la couleur pour mettre des éléments du design en avant, mais en général ils ont déjà un rôle dans le graphisme retenu, comme par exemple les lignes horizontales du site ci-dessous. On peut aussi imaginer mettre en valeur un bouton de recherche, ou bien les éléments d’une barre de navigation. La couleur sert alors à faire ressortir des éléments fonctionnels cruciaux de l’interface.


On résout d’abord les questions de tons avant d’appliquer de la couleur

Vers des palettes mono- et duo-tonales

Dans mon prochain billet, je vais aller un peu plus loin avec mes gris.
On a quand même de la chance, nous les designers du web. On peut employer pratiquement n’importe quelle couleur. Les designers papier, eux, sont confrontés à des limites sur l’usage des couleurs depuis l’origine de l’imprimerie. Du coup, cela les a rendus très attentifs à ces questions du design en couleur. Je trouve qu’il n’y a rien de plus formateur que de créer des projets à une ou deux couleurs, mais appliquées à un grand nombre de situations, afin de mieux réfléchir à la façon dont la couleur est employée. Je vais essayer d’évoquer cet axe de réflexion (et cette contrainte) dans mon prochain billet.

]]> http://www.pompage.net/traduction/concevoir-un-design-sans-la-couleur http://www.pompage.net/traduction/concevoir-un-design-sans-la-couleur Tue, 09 Sep 2014 10:09:00 +0200 <![CDATA[Concevoir un design sans la couleur]]>

Par Mark Boulton

La conception d'un design efficace est une affaire délicate, et souvent rendue plus difficile encore par les choix de couleurs. Pourquoi ne pas imaginer un mode initial de conception qui s'affranchisse totalement de la couleur au profit d'un travail sur les tons?

Faire un design en travaillant sur la couleur, c’est peut-être l’une des choses les plus difficiles à faire dans le domaine du design graphique. Pourquoi ? Parce qu’il n’y a rien de plus subjectif. Certains trouveront génial de choisir une palette de gris sombre avec quelques touches de rose vif, tandis que d’autres trouveront ça très laid. On voit trop souvent des designers prendre des décisions arbitraires sur cette question, qu’ils soient ou non formés à la théorie chromatique, et c’est au moment où ils tentent de justifier ces choix auprès de leurs clients que tout se complique. Dans ce premier article, je vais m’intéresser aux tons et à l’avantage qu’on trouvera à limiter l’étendue de sa palette.

On baisse d’un ton

Il y a quelques années (houlà, ça fait même une bonne quinzaine d’années…) j’étais en première année aux Beaux-Arts, ici à Stockport au Royaume-Uni. Je voulais devenir peintre, ou plus exactement illustrateur. Dès la première semaine, on nous a demandé de nous débarrasser de tous les beaux pinceaux qu’on venait de s’acheter pour les cours. Nous avons donc dû laisser notre matériel tout neuf à la maison, puis aller dehors récolter des brindilles et dénicher de l’encre noire. Je n’étais vraiment pas enthousiaste. Comment imaginer qu’un artiste puisse créer à l’aide d’outils aussi primitifs ? Nos professeurs nous ont donc fait peindre avec des brindilles, puis avec nos pieds, puis les yeux bandés : bref, la totale. À l’époque j’ai trouvé ça nul, et je ne comprenais pas où ils voulaient en venir. Maintenant que j’ai pris du recul, je perçois bien l’intérêt de cet horrible démarrage. Ils nous apprenaient à observer et à produire des œuvres qui n’étaient pas dictées par nos outils. En d’autres termes, si nous avions disposé de couleurs variées et de beaux pinceaux, la tentation de les exploiter aurait été trop grande. Faute de pinceaux et de couleurs, nous avons été contraints de communiquer la notion de couleur uniquement avec des effets de ton.

C’est par cela que je voudrais commencer.

Faisons sans la couleur

L’une des choses que j’apprécie dans le design éditorial, et en particulier dans le design typographique, c’est l’importance du noir et blanc. Bien sûr, la couleur constitue une étape très importante de tout travail typographique, mais je m’intéresse avant tout au ton et à la forme. Je crois qu’il y a tout à gagner à retirer complètement la couleur de l’équation afin de focaliser sur les questions de tonalité d’un design, avant d’y appliquer des couleurs. Quelques exemples notables suffiront à montrer qu’un design basé seulement sur du noir peut être original et attirant.

On ne saurait parler du design web en noir et blanc sans évoquer le site de Khoi Vinh, Subtraction.com. Khoi travaille avec du noir et de l’orange pour correspondre au style suisse du design (ou style typographique international, NdT).


Le site Substraction.com par Khoi Vinh

Form, un magazine de design allemand, utilise une typographie en noir et blanc (basée sur une grille rigoureuse) pour transmettre son concept de marque aux utilisateurs du site. On voit l’effet qui est atteint avec ce noir et blanc : l’ouvrage qui est mis en lumière, avec sa couleur vive, se détache très nettement du cadre noir et blanc.


Le magazine allemand de design Form

D’abord du gris

Faites donc le test pour votre prochain design. Comme indiqué dans le titre, contentez-vous de le démarrer avec du gris en différentes nuances. N’ajoutez aucune couleur tant que vous n’êtes pas satisfait du design en noir et blanc. Il y a de grandes chances que les décisions de palette et de couleurs que vous prendrez seront ensuite beaucoup plus simples, parce que le design ne dépendra plus de la couleur pour fonctionner. C’est particulièrement pertinent si on cherche à créer un design avec une bonne accessibilité. Ce n’est pas le sujet de cet article, puisque je me concentre ici sur le design graphique, mais l’accessibilité reste néanmoins une question qui ne doit pas être négligée. En basant votre design sur le noir et blanc, vous vous assurez que la solution retenue ne dépendra jamais de la couleur.
J’utilise souvent la couleur pour mettre des éléments du design en avant, mais en général ils ont déjà un rôle dans le graphisme retenu, comme par exemple les lignes horizontales du site ci-dessous. On peut aussi imaginer mettre en valeur un bouton de recherche, ou bien les éléments d’une barre de navigation. La couleur sert alors à faire ressortir des éléments fonctionnels cruciaux de l’interface.


On résout d’abord les questions de tons avant d’appliquer de la couleur

Vers des palettes mono- et duo-tonales

Dans mon prochain billet, je vais aller un peu plus loin avec mes gris.
On a quand même de la chance, nous les designers du web. On peut employer pratiquement n’importe quelle couleur. Les designers papier, eux, sont confrontés à des limites sur l’usage des couleurs depuis l’origine de l’imprimerie. Du coup, cela les a rendus très attentifs à ces questions du design en couleur. Je trouve qu’il n’y a rien de plus formateur que de créer des projets à une ou deux couleurs, mais appliquées à un grand nombre de situations, afin de mieux réfléchir à la façon dont la couleur est employée. Je vais essayer d’évoquer cet axe de réflexion (et cette contrainte) dans mon prochain billet.

]]> https://www.pompage.net/traduction/concevoir-un-design-sans-la-couleur https://www.pompage.net/traduction/concevoir-un-design-sans-la-couleur Tue, 09 Sep 2014 10:09:00 +0200 <![CDATA[Écrire du JavaScript véloce et à faible empreinte mémoire]]>

Par Addy Osmani

Qu’il s’agisse de V8, de Spider Monkey (Firefox), de Caracan (Opéra) ou de Chakra (IE), connaître le fonctionnement interne du moteur JavaScript vous permettra de mieux optimiser vos applications. Cela ne veut pas dire qu’il faut que vous optimisiez votre code pour un seul moteur ou navigateur : ne faites jamais cela !

Vous devriez plutôt vous poser ce type de questions :

  1. Que puis-je faire pour rendre mon code plus efficient ?
  2. Quelles optimisations communes sont faites par les moteurs JavaScript ?
  3. Quelles sont les limites de l’optimisation de ces moteurs ? Le ramasse-miette est-il bien capable de libérer la mémoire comme je m’y attend ?
JPEG - 126.8 ko

Les sites véloces, comme les voitures de course, nécessitent des outils spécialisés. Crédti de l’image : dHybridcars

Nombreux sont les pièges quand on souhaite produire du code rapide et économe en mémoire. Cet article propose donc d’explorer plusieurs techniques testées et approuvées pour écrire du code qui s’exécute efficacement.

Comment fonctionne JavaScript au sein de V8 ?

Bien qu’il soit possible d’écrire des applications volumineuses sans comprendre le fonctionnement des moteurs JavaScript, n’importe quel conducteur vous dira qu’il a déjà jeté un œil sous le capot au moins une fois. Étant donné que Chrome est mon navigateur préféré, je vais vous parler quelque peu de son moteur Javascript. Le cœur de V8 est composé de différentes pièces :

  1. Un compilateur de base qui parcourt votre JavaScript et génère du code machine avant qu’il soit exécuté, plutôt que d’exécuter du bytecode ou simplement de l’interpréter. Ce code natif n’est pour le moment pas très optimisé.
  2. V8 représente vos objets dans un modèle objet. Les objets sont représentés au sein de tableaux associatifs en JavaScript, mais dans V8, ils sont représentés avec les classes cachées (hidden classes) qui sont un système de typage interne pour optimiser la recherche de références.
  3. Le profileur à l’exécution surveille le système en fonctionnement et identifie les fonctions « chaudes » (le code qui est fréquemment exécuté[a]).
  4. Un compilateur optimisé recompile et optimise les fonctions chaudes identifiées par le profileur à l’exécution et procède à des optimisations comme l’inlining (le remplacement des appels de fonction par le corps de la fonction appelée).
  5. V8 supporte le retour sur optimisation[b] ce qui signifie que le compilateur peut révoquer le code optimisé s’il découvre que les optimisations s’avèrent contre-productives.
  6. V8 a également un ramasse-miette. Comprendre son fonctionnement peut être tout aussi important qu’optimiser son JavaScript.

Le ramasse-miette

Le ramasse-miette est un système de gestion de la mémoire. Il introduit la notion de collecteur qui tente de libérer la mémoire occupée par des objets qui ne sont plus utilisés. Dans un langage à ramasse-miette tel que JavaScript les objets qui sont toujours référencés par votre application ne sont pas effacés.

Déréférencer manuellement les objets s’avère inutile la plupart du temps. En déclarant simplement les variables à l’endroit où elles sont nécessaires (idéalement le plus localement possible ; à l’intérieur de la fonction où elles sont utilisées plutôt que dans un contexte parent), cela devrait fonctionner tout seul.

JPEG - 109.8 ko

Le ramasse-miette en train de libérer de la mémoire. Crédits de l’image : Valtteri Mäki.

Il est impossible de forcer l’intervention du ramasse-miette en Javascript. Ne pensez pas que c’est dommage, car le processus de libération de la mémoire est contrôlé par l’environnement d’exécution et il sait généralement mieux que vous quand un nettoyage s’impose.

Les mythes du déréférencement

Dans un bon nombre de discussions en ligne à propos de la libération de mémoire en JavaScript, le mot-clé delete a amené certains développeurs à penser qu’ils pouvaient forcer le déréférencement en l’utilisant, alors qu’il est seulement supposé retirer une clé d’un tableau de hachage. Évitez d’utiliser delete si vous le pouvez. Dans l’exemple ci-dessous, delete o.x fait plus de mal que de bien contrairement aux apparences. Il change la classe cachée de l’objet o et le transforme en objet générique plus lent.

var o = { x: 1 };
delete o.x; // true
o.x; // undefined

Cela dit, vous pouvez être certains de trouver delete dans la plupart des bibliothèques JavaScript populaires. Il a une utilité au sein du langage. Ce qu’il faut retenir, c’est qu’il modifie la structure des objets « chauds » à l’exécution. Les moteurs JavaScript repèrent ces objets chauds et tentent de les optimiser. C’est plus facile si la structure de ces objets évolue peu au cours de leur utilisation, or delete impose des changements.

Il y a également des erreurs d’interprétation sur le fonctionnement de null. Attribuer à la référence d’un objet la valeur null ne détruit pas l’objet associé. Cela détruit en réalité la référence à cet objet. Il vaut mieux utiliser o.x=null plutôt que le mot-clé delete, mais c’est rarement utile.

var o = { x: 1 };
o = null;
o; // null
o.x; // TypeError

Si cette référence est la dernière pointant sur cet objet, alors il devient éligible pour être libéré de la mémoire. Mais si ce n’était pas la dernière référence à ce dernier, cet objet reste atteignable et ne sera donc pas détruit.

Une autre chose importante est que les variables globales ne sont pas détruites par le ramasse-miette durant toute la durée de vie de votre page. Que celles-ci soient affichées une fraction de seconde ou plusieurs heures, les variables affectées au contexte global d’exécution du JavaScript resteront en mémoire.

var monEspaceDeNomGlobal = {};

Les variables globales ne sont détruites que lorsque vous rafraîchissez la page, naviguez vers une autre page, fermez l’onglet ou votre navigateur. Les variables rattachées au contexte d’une fonction sont détruites quand elles tombent en dehors du contexte courant. Cela signifie qu’elles sont détruites quand les fonctions sont retirées de la pile d’exécution et qu’il n’y a plus de références pointant vers elles.

Quelques règles générales

Pour donner l’opportunité au ramasse-miette de libérer la mémoire occupée par vos variables le plus tôt possible, ne gardez pas de référence à vos objets plus longtemps que nécessaire. La plupart du temps, cela se fait automatiquement. Mais voici quelques règles à garder en tête :

  1. Comme dit plus haut, déclarez vos variables dans un contexte approprié plutôt que de les déréférencer manuellement. En d’autres termes, au lieu de créer une référence globale que vous devrez déréférencer plus tard, optez pour une variable locale qui sera détruite lorsque son contexte sera sorti de la pile. Vous aurez alors un code plus propre, et moins de choses à gérer.
  2. Assurez-vous de bien supprimer vos écouteurs d’événements des nœuds DOM dès lors qu’ils deviennent inutiles, en particulier juste avant de retirer les nœuds du document.
  3. Si vous cachez localement certaines données, assurez-vous de les nettoyer quand elles ne sont plus utiles ou de programmer leur suppression pour éviter que de trop grands volumes de données ne soient stockées en mémoire.

Les fonctions

Maintenant, intéressons-nous aux fonctions. Comme dit précédemment, le ramasse-miette fonctionne par récupération de pages mémoires qui ne sont plus référencées par l’application. Pour mieux illustrer notre propos, voyons quelques exemples.

function foo() { var bar = new GrosObjet(); bar.appelQuelconque();
}

Quand le fil d’exécution sort de la fonction foo, l’objet vers lequel pointe bar est automatiquement éligible pour être libéré de la mémoire car il n’existe plus aucune référence à cet objet.

Comparons cet exemple au code suivant :

function foo() { var bar = new GrosObjet(); bar.appelQuelconque(); return bar;
} //somewhere else
var b = foo();

Nous avons maintenant une référence à l’objet qui survit à l’appel de la fonction foo et qui persistera tant qu’aucun autre objet ne sera assigné à la variable b (ou tant que b sera dans le contexte d’exécution courant).

Les closures

Quand vous trouvez une fonction qui contient la déclaration d’une autre fonction et retourne une référence vers cette fonction, cette dernière aura accès au contexte de sa fonction parente même si sa fonction parente est retirée de la pile d’exécution. C’est ce qu’on appelle une closure ; c’est une expression qui a accès aux variables situées dans un contexte particulier. Par exemple :

function somme(x) { function faitLaSomme(y) { return x + y; }; return faitLaSomme;
} // Usage
var sommeA = somme(4);
var sommeB = sommeA(3);
console.log(sommeB); // Renvoie 7

L’objet de type function créé lors de l’appel à somme() ne peut être détruit puisqu’il est toujours référencé au sein du contexte global. Il est donc toujours référencé et reste tout ce qu’il y a de plus accessible via sommeA(n).

Intéressons-nous à un autre exemple. Pouvons-nous accéder à longueChaine ?

var a = function () { var longueChaine = new Array(1000000).join('x'); return function () { return longueChaine; };
}();

Oui, bien sûr, via a(), donc elle n’a pas été détruite. Et dans l’exemple suivant ?

var a = function () { var petiteChaine = 'x'; var longueChaine = new Array(1000000).join('x'); return function (n) { return petiteChaine; };
}();

On ne peut plus y accéder et elle est éligible pour être détruite par le ramasse-miette.

Les timers

On trouve beaucoup de fuites de mémoires dans les boucles, mais setTimeout()/setInterval() ne sont pas mal non plus pour ça.

Considérons l’exemple suivant :

var monObjet = { callMeMaybe: function () { var maReference = this; var val = setTimeout(function () { console.log('Tu perds ton temps!'); maReference.callMeMaybe(); }, 1000); }
};

Si nous appelons monObjet.callMeMaybe(); pour mettre en route le timer, nous pourrons voir toutes les secondes dans la console le message suivant : « Tu perds ton temps ! » Si nous tentons :

monObjet = null;

Le timer sera toujours actif. monObjet ne sera pas détruit puisque la closure transmise à setTimeout doit être conservée pour rester accessible. Par effet d’entraînement, monObjet est conservé puisqu’il encapsule maReference. Il en irait de même si nous avions passé cette closure à n’importe quelle autre fonction conservant une référence à cet objet.

C’est également important de garder à l’esprit que les références à l’intérieur des appels à setTimeout/setInterval, comme pour les fonctions, ne pourront être détruites qu’après la complète exécution de ces dernières.

Soyez à l’écoute des problèmes de performance

On ne le répétera jamais assez : n’optimisez votre code que lorsque vous constatez des problèmes de performance. On trouve des tas de micro-benchmarks démontrant que « N » est plus rapide que « M » dans V8, mais confronté à la réalité d’un vrai module de code ou d’une application concrète, l’impact de ces optimisations pourrait être bien moins important que ce que vous pensiez obtenir.

JPEG - 58.2 ko

En faire trop peut être aussi problématique que de ne rien faire du tout. Crédits image : Tim Sheerman-Chase

Imaginons que nous voulions créer un module qui :

  1. utilise une source de donnée locale contenant des éléments avec un identifiant numérique,
  2. affiche un tableau contenant ces données,
  3. assigne des gestionnaires d’événements qui commutent une classe quand un utilisateur clique sur une cellule.

Il y a plusieurs chose à prendre en compte dans ce problème, bien qu’il soit très simple à résoudre. Comment stockerons-nous les données ? Comment générer[e] le tableau de manière efficiente et l’insérer dans le DOM ? Comment pouvons-nous capturer les événements émis par le tableau de manière optimale ?

Une première méthode (naïve) serait de stocker chaque silo de données disponible dans des objets que nous regrouperions dans un tableau associatif. On pourrait utiliser jQuery pour parcourir ce tableau de données, générer le tableau et ensuite, l’insérer dans le DOM. Enfin, on pourrait utiliser les écouteurs d’événements pour programmer le comportement désiré au clic sur une cellule.

Ne faites SURTOUT PAS comme ça !

var moduleA = function () { return { data: dataArrayObject, init: function () { this.addTable(); this.addEvents(); }, addTable: function () { for (var i = 0; i < rows; i++) { $tr = $('<tr></tr>'); for (var j = 0; j < this.data.length; j++) { $tr.append('<td>' + this.data[j]['id'] + '</td>'); } $tr.appendTo($tbody); } }, addEvents: function () { $('table td').on('click', function () { $(this).toggleClass('active'); }); } };
}();

C’est basique, mais ça fait ce qui a été demandé.

Dans ce cas, cependant, nous ne faisons qu’utiliser la propriété ID de type numérique qui aurait été plus avantageusement stockée dans un simple tableau. Point intéressant, utiliser documentFragment et les méthodes natives du DOM est plus optimal que d’utiliser jQuery de cette manière pour générer notre tableau. Enfin, bien sûr, écouter les événements au niveau du tableau aurait été plus performant que d’écouter les clics sur chaque cellule.

Notez que jQuery fait appel à DocumentFragment en interne, mais dans notre exemple le code appelle la fonction append() à chaque itération de la boucle, cloisonnement qui empêche une bonne optimisation. Cela ne devrait pas être si catastrophique mais n’oubliez pas de passer votre code au banc d’essai pour vous en assurer.

Dans notre cas, procéder à ces améliorations engendrera de bons gains en performance comme nous pouvons nous y attendre. Écouter les événements au niveau du tableau[g] apporte une amélioration intéressante, quant à l’utilisation de DocumentFragment, elle dope véritablement les performances.

var moduleD = function () { return { data: dataArray, init: function () { this.addTable(); this.addEvents(); }, addTable: function () { var td, tr; var frag = document.createDocumentFragment(); var frag2 = document.createDocumentFragment(); for (var i = 0; i < rows; i++) { tr = document.createElement('tr'); for (var j = 0; j < this.data.length; j++) { td = document.createElement('td'); td.appendChild(document.createTextNode(this.data[j])); frag2.appendChild(td); } tr.appendChild(frag2); frag.appendChild(tr); } tbody.appendChild(frag); }, addEvents: function () { $('table').on('click', 'td', function () { $(this).toggleClass('active'); }); } };
}();

Nous pourrions également tenter d’autres approches pour améliorer les performances. Vous avez probablement lu quelque part qu’utiliser le prototypage est plus optimal que de créer un module (et nous l’avons confirmé au début de cet article), ou entendu que les moteurs de gabarits (templates) JavaScript sont très performants. Ils le sont parfois, mais utilisez-les pour clarifier votre code et précompilez vos gabarits. Testons et voyons si ces pratiques sont aussi intéressantes que ça.

var moduleG = function () {}; moduleG.prototype.data = dataArray;
moduleG.prototype.init = function () { this.addTable(); this.addEvents();
};
moduleG.prototype.addTable = function () { var template = _.template($('#template').text()); var html = template({'data' : this.data}); $tbody.append(html);
};
moduleG.prototype.addEvents = function () { $('table').on('click', 'td', function () { $(this).toggleClass('active'); });
}; var modG = new moduleG();

Comme on pouvait s’y attendre, les bénéfices en terme de performance sont négligeables ici. Les moteurs de template et le prototypage ne nous apportent rien de plus que ce que nous avions auparavant. Cela dit, ce n’est pas vraiment pour les performances que les développeurs modernes utilisent ces outils. C’est plutôt la clarté, le modèle d’héritage et la maintenabilité du code qui les motive.

Certains problèmes plus complexes concernent l’efficience du dessin avec canvas et la manipulation de pixels avec ou sans tableaux typés.

Jetez toujours un œil critique aux micro-benchmarks avant d’appliquer leurs conclusions à vos applications. Certains d’entre vous pourraient se souvenir de l’article Javascript templating shoot-off et la polémique qui s’en est suivie. Vous devez vous assurer que les résultats de vos tests ne sont pas influencés par des contraintes inexistantes dans une application concrète. Testez également ces optimisations dans leur contexte final.

Quelques astuces d’optimisation pour V8

Lister toutes les optimisations réalisables pour V8 s’éloignerait du sujet de cet article, mais voici cependant quelques astuces qui méritent d’être citées. En les gardant à l’esprit vous serez en mesure de limiter l’écriture de code non-performant.

  1. Certaines pratiques telles que l’utilisation de try...catch empêchent V8 de se lancer dans la moindre optimisation. Pour plus d’information sur les fonctions qui peuvent être optimisées et celles qui ne le peuvent pas, utilisez d8, un petit utilitaire en ligne de commande fourni avec V8, et l’option --trace-opt file.js.
  2. Si la vitesse d’exécution vous importe, essayez de garder vos fonctions monomorphes ; assurez-vous que les variables (tableaux, objets, paramètres de fonction) ne contiennent que des éléments du même type. Par exemple, évitez ce genre de code (NdT : en clair, faites comme si JavaScript était un langage typé) :
function ajoute(x, y) { return x+y;
} ajoute(1, 2); ajoute('a','b'); ajoute(mon_objet, undefined);
  1. Ne réutilisez pas des éléments désinitialisés ou supprimés. Le résultat sera identique, mais votre code sera bien plus lent.
  2. N’écrivez pas de fonctions gigantesques car elles sont plus difficiles à optimiser.

Pour plus de trucs et astuces, je vous recommande de visualiser la vidéo Breaking the Javascript speed limit with V8 de Daniel Clifford au Google IO. Je vous recommande également Optimizing For V8 - A Series dans la foulée.

Objets vs Tableaux : que dois-je utiliser ?

  1. Si vous souhaitez stocker un paquet de nombres ou une liste d’objets de même nature, utilisez les tableaux.
  2. Si ce dont vous avez besoin sémantiquement est un objet avec un lot de propriétés (de types différents), utilisez un objet avec des propriétés. C’est très efficient en terme de mémoire et assez rapide d’accès.
  3. Qu’elles soient stockées dans des objets ou des tableaux, les clés numériques sont plus rapides d’accès lors de vos itérations que les propriétés des objets.
  4. Les propriétés des objets sont très complexes : elle peuvent être crées avec des accesseurs (getters/setters) et utiliser différents type d’énumérabilité et d’accès en écriture. Les éléments d’un tableau sont au contraire peu personnalisables ; ils existent ou pas, point final. Au niveau du moteur JavaScript, cela permet plus d’optimisations en terme d’organisation de la mémoire pour représenter sa structure. C’est d’autant plus bénéfique quand ces tableaux contiennent des nombres. Par exemple, si vous avez besoin de stocker des vecteurs, ne définissez pas une classe avec des propriétés x, y et z ; utilisez plutôt un tableau.

Il existe une différence majeure entre les objets et les tableaux en JavaScript, c’est la propriété magique length. Si vous gérez cette propriété vous-même, vos objets seront tout aussi rapides que des tableaux dans V8.

Quelques astuces pour l’utilisation des objets

  1. Créez vos objets via leur fonction constructeur. Cela permet d’assigner à chaque objet la même classe cachée et évite de changer cette dernière par la suite. Un autre point qui plaide pour cela est que c’est légèrement plus rapide que son homologue Object.create().
  2. Il n’y a aucune restriction sur le nombre de types d’objets différents au sein d’une application ou sur leur complexité (tout en restant raisonnable : les longues chaînes de prototype tendent à ralentir l’application, et les objets avec un nombre limité de propriété bénéficient d’une représentation spéciale leur conférant une rapidité accrue). Pour les objets « chauds », essayez de garder une chaîne de prototypes courte et peu de propriétés.

Clonage d’objets

Le clonage d’objets est un problème que rencontrent tous les développeurs d’applications. Bien qu’il soit possible de tester ses différentes implémentations pour observer comment elles se comportent avec le moteur V8, soyez prudents quand vous copiez quoi que ce soit. Copier des gros lots de données est généralement lent, ne le faites pas. Les boucles for...in sont particulièrement inadaptées pour cela car elles ont une spécification démoniaque et ne seront jamais rapides pour des objets arbitraires, quel que soit le moteur JavaScript.

Si vous avez absolument besoin de copier des objets dans une partie critique de votre code en terme de performance (et que vous ne pouvez pas contourner le problème), utilisez un tableau ou un “constructeur de copie” personnalisé qui copie chaque propriété individuellement. C’est probablement la manière la plus rapide de le faire.

function clone(original) { this.foo = original.foo; this.bar = original.bar;
}
var copie = new clone(original);

Les fonctions en cache grâce aux modules

Mettre vos fonctions en cache grâce au patron de conception « module » peut améliorer les performances. Regardez l’exemple ci-dessous, vous constaterez que l’une ou l’autre méthodes que vous avez l’habitude de voir est plus lente car elle oblige à copier les fonctions membres sans arrêt.

Vous noterez également que cette approche peut se révéler significativement meilleure que de s’appuyer sur la technique du prototype (et un test jsPerf le confirme).

PNG - 40 ko

Mesure des gains de performance des techniques modules et prototypes.

Voici un test comparatif entre les patrons de conception module et prototype.

 // Technique "Prototype" Klass1 = function () {} Klass1.prototype.foo = function () { log('foo'); } Klass1.prototype.bar = function () { log('bar'); } // Technique "Module" Klass2 = function () { var foo = function () { log('foo'); }, bar = function () { log('bar'); }; return { foo: foo, bar: bar } } // Technique "Module avec fonctions mises en cache" var FooFunction = function () { log('foo'); }; var BarFunction = function () { log('bar'); }; Klass3 = function () { return { foo: FooFunction, bar: BarFunction } } // Tests comparatifs // Prototype var i = 1000, objs = []; while (i--) { var o = new Klass1() objs.push(new Klass1()); o.bar; o.foo; } // Module simple var i = 1000, objs = []; while (i--) { var o = Klass2() objs.push(Klass2()); o.bar; o.foo; } // Module avec fonctions mises en cache var i = 1000, objs = []; while (i--) { var o = Klass3() objs.push(Klass3()); o.bar; o.foo; }
// Le reste du code est sur jsPerf

Quelques astuces pour l’utilisation des tableaux

Maintenant, jetons un œil aux tableaux. En règle générale, ne supprimez pas d’éléments dans les tableaux. Cela oblige le moteur à basculer vers une représentation interne plus lente. Quand les clés d’un tableau deviennent éparpillées, le moteur est susceptible de le transformer en tableau associatif, qui est encore plus lent.

Représentation littérale des tableaux

L’initialisation littérale d’un tableau est préférable puisque cela donne un aperçu à la machine virtuelle de ce que vous souhaitez y stocker (taille, type de valeurs). Ils sont typiquement souhaitables pour des tableaux de taille petite à moyenne.

// Ici, le moteur JS voit que vous souhaitez un tableau contenant 4 nombres
var a = [1, 2, 3, 4]; // Ne faites pas ça :
a = []; // Ici, le moteur n'a aucune idée de ce qui ira dans le tableau
for(var i = 1; i <= 4; i++) { a.push(i);
}

Stocker un seul type de données versus données mixtes

Il n’est jamais bon de mélanger différents types de valeurs dans un même tableau (des nombres, chaînes, objets, booléens ou undefined, comme par exemple : var arr = [1, “1”, undefined, true, “true”]).

Test de performance de l’inférence de type

Comme vous pouvez le constater, le meilleur résultat est obtenu par le tableau d’entiers.

Tableaux à clés consécutives ou non

Quand vous utilisez des tableaux aux clés non consécutives, soyez bien conscients qu’accéder à leurs éléments est bien plus lent que si les clés se suivaient dans leur ordre naturel. La raison est que s’il manque trop d’éléments le moteur V8 choisira de ne pas leur allouer d’espace mémoire. À la place, il préférera les gérer au sein d’un tableau associatif, ce qui est bien plus lent en terme de temps d’accès.

Test comparatifs entre tableaux à clés éparses et clé consécutives

Ce test montre que la somme des éléments d’un tableau aux clés consécutives est plus rapide. Le fait qu’il contienne ou non des zéros ne fait aucune différence.

Tableaux « troués » contre tableaux « pleins »

Évitez de trouer vos tableaux (en supprimant des éléments ou en faisant a[x] = foo (dans le cas où x > a.length). Il suffit qu’un seul élément manque dans un tableau pour ralentir le code.

Test entre tableaux « troués » et tableaux « pleins »

Allouer l’espace du tableau à l’initialisation ou à la volée

Ne pré-allouez pas les tableaux dont la taille excéderait 64 000 éléments. Faites-les plutôt grossir à la volée. Avant d’interpréter les tests sur ce point, rappelez-vous bien que leurs résultats sont fortement dépendants du moteur JavaScript testé.

JPEG - 30.5 ko

Test des tableaux initialement vides par rapport aux tableaux pré-alloués.

Nitro (Safari) traite les tableaux pré-alloués plus favorablement. Cependant, c’est le contraire pour les autres moteurs (V8 et Spider Monkey) pour lesquels allouer l’espace à la volée est plus efficace.

Tester les tableaux pré-alloués

// Tableau vide
var arr = [];
for (var i = 0; i < 1000000; i++) { arr[i] = i;
} // Tableau pré-dimensionné
var arr = new Array(1000000);
for (var i = 0; i < 1000000; i++) { arr[i] = i;
}

Optimiser vos applications

Dans le monde des applications Web, la performance est primordiale. Aucun utilisateur ne souhaite qu’un tableur prenne plusieurs secondes pour faire la somme des cellules d’une colonne, ou attendre plusieurs minutes que s’affiche le résumé de leurs messages. C’est pourquoi rendre votre code aussi véloce que possible est parfois critique.

JPEG - 146.7 ko

Crédits de l’image : Per Olof Forsberg

Bien qu’il soit utile de comprendre et d’améliorer les performances de vos applications, cela peut être difficile. Nous recommandons la démarche suivante pour venir à bout des points qui vous ralentissent :

  1. Mesurer : repérer les points les plus lents de votre application ( 45%)
  2. Comprendre : trouver ce qui provoque cette lenteur ( 45%)
  3. Corriger ! ( 10%)

Quelques-uns des outils suivants peuvent vous aider dans cette tâche.

Mesurer la performance

Il existe de nombreuses façons de tester les performances de vos bouts de code en JavaScript mais en règle générale on effectue une comparaison entre deux chronométrages. L’équipe de jsPerf a proposé un modèle qui a été ensuite repris par les suites de tests que sont SunSpider et Kraken.

var tempsTotal, depart = new Date, iterations = 1000;
while (iterations--) { // Placer ici le code a tester
}
// tempsTotal → Nombre de millisecondes necessaires // pour executer les instructions 1000 fois
tempsTotal = new Date - depart;

Dans cet exemple le code à tester est placé dans une boucle et exécuté un nombre déterminé de fois. Une fois terminé, la date de début d’exécution est soustraite à la date de fin déterminant le temps écoulé durant le test.

Néanmoins cette façon de faire des tests est très réductrice, surtout si vous voulez mesurer dans différents navigateurs et environnements. Le ramasse-miette lui-même peut avoir des effets sur vos résultats. Même en affinant la mesure en utilisant window.performance, vous pouvez être sûrs que des impondérables viendront fausser les mesures.

Que vous écriviez simplement des tests sur des parties de votre code, des suites de tests ou une librairie complète, il y a bien plus de facteurs à prendre en compte que vous ne pouvez l’imaginer. Pour un guide plus complet sur les tests de performance, je vous recommande fortement de lire Javascript Benchmarking de Mathias Bynens et John-David Dalton.

Le profilage

Les outils pour développeur de Chrome permettent de profiler aisément vos applications. Vous pouvez utiliser cette fonctionnalité pour identifier les fonctions les plus chronophages pour les optimiser en priorité. Cette démarche est importante car la moindre petite modification de votre code peut avoir des conséquences importantes en termes de performance.

JPEG - 40.8 ko

L’onglet “profilage” des outils pour développeur de Chrome.

Pour commencer le profilage, il faut obtenir une mesure de base des performances actuelles de votre application. Cette dernière peut être obtenue grâce à l’onglet “timeline” (frise chronologique). Cela nous permettra de mesurer le temps effectif d’exécution de notre application.

L’onglet “profiles” nous donnera lui une vue plus détaillée de ce qui se passe vraiment dans notre application. Le profilage processeur (JavaScript CPU profile) nous permet de savoir combien de temps processeur est utilisé par notre application, le profilage des sélecteurs CSS (CSS selector profile) nous renseigne sur le temps nécessaire pour calculer les sélecteurs CSS, et les captures de pile de mémoire Heap (Heap snapshots) nous permet de savoir combien nos objets consomment de mémoire.

L’utilisation de ces outils nous permet d’ajuster et de profiler à nouveaux notre code afin de vérifier si les changements réalisés ont bien un impact positif sur les performances.

JPEG - 79.7 ko

Pour une bonne introduction au profilage dans Chrome, lisez Javascript Profiling With The Chrome Developper Tools par Zack Grossbart.

Petit truc : dans l’idéal, il vaut mieux éviter que les extensions et applications installées dans Chrome n’influent sur vos résultats. Pour cela, exécutez Chrome avec l’option --user-data-dir <un_répertoire_vide>. Cela suffit la plupart du temps, mais si vous avez besoin d’aller plus loin les options de V8 vous seront d’une grande aide.

Eviter les fuites mémoire : trois techniques pour les déceler

Les équipes internes de Google, celle de Gmail par exemple, utilisent énormément les outils pour développeurs de Chrome pour traquer et éliminer les fuites mémoires.

JPEG - 39 ko

Statistiques d’utilisation mémoire dans les outils pour développeurs.

Les statistiques utilisées par nos équipes sont par exemple : l’utilisation mémoire privée, la taille de la pile Heap de JavaScript, le nombre de nœuds DOM, l’effacement des données, le nombre de gestionnaires d’évènements et le comportement du ramasse-miette. Les habitués des architectures dirigées par les événements seront peut-être contents d’apprendre que la plupart de nos problèmes venaient de l’utilisation de listen() non suivi d’unlisten() (Closure) et par l’absence de dispose() pour les objets créant des gestionnaires d’évènements.

Par chance, les outils pour développeurs peuvent nous aider à localiser ces problèmes et Loreena Lee a créé une présentation fantastique, qui détaille la technique des trois captures pour détecter les fuites mémoires, que je ne vous recommenderai jamais assez de lire.

La base de la technique est d’enregistrer un certain nombre d’action utilisateur dans votre application, forcer l’éxecution du ramasse-miette, vérifier si le nombre de noeuds DOM reste supérieur à la normale puis comparer trois captures successives de la pile Heap pour détecter s’il y a une fuite de mémoire.

Gestion de la mémoire dans les applications sans rechargement de page

La gestion de la mémoire est très importante au sein des applications qui ne sont jamais rechargées (avec AngularJS, Backbone, Ember..). En effet, une fuite de mémoire devient rapidement handicapantes. C’est un énorme piège au sein des applications pour appareils mobiles (qui sont limités en mémoire) comme les clients mails ou les applications de réseaux sociaux qui ont une durée d’utilisation très importante. Comme on dit : de grands pouvoirs impliquent de grandes responsabilités.

Il y a plusieurs façon de se prémunir de cela. Dans Backbone, assurez-vous de toujours déréférencer vos vues et références en utilisant dispose() (actuellement disponible dans Backbone (edge)).

Cette fonction, ajoutée tout récemment, supprime tout gestionnaire associé aux évènements de la vue ainsi qu’à toute collection ou écouteur de modèle pour lesquels la vue a été passée en troisième argument (en tant que contexte de callback). dispose() est également appelé par la méthode remove() de la vue, et s’occupe de nettoyer la majorité de l’utilisation mémoire lorsque la vue est supprimée de l’écran. D’autres librairies, comme Ember, suppriment les observateurs quand ils détectent que les éléments ont étés supprimés de la vue pour éviter les fuites mémoires.

Voici les conseils avisés de Derick Bailey :

Plutôt que d’essayer de comprendre comment fonctionnent les évènements en terme de références, suivez simplement les règles standard de gestion de la mémoire en JavaScript et vous serez tranquilles. Si vous chargez des données dans une collection Backbone pleine d’objets Utilisateurs et voulez que cette collection soit nettoyée par la suite afin de ne plus utiliser de mémoire, vous devez supprimer toute référence à cette collection et aux objets qu’elle contient. Une fois toutes les références supprimées, la mémoire sera libérée. Ce n’est rien d’autre que le comportement standard du ramasse-miette de JavaScript.

Dans son article, Derick couvre la plupart des erreurs communes de gestion de mémoire liées à l’utilisation de Backbone et comment les corriger.

Il y a également un bon tutoriel disponible pour déboguer les fuites mémoires dans Node écrit par Felix Geisendörfer. Particulièrement intéressant si votre application Node est utilisée dans le contexte d’un application sans rechargement de page.

Eviter les réagencements

Quand un navigateur doit recalculer la position et la forme des éléments d’un document afin de les redessiner, il effectue ce qu’on appelle un reflow (réagencement). C’est une opération qui bloque l’interface utilisateur, il est donc important de savoir comment limiter le temps qu’elle dure.

JPEG - 45.7 ko

Graphique montrant une succession de réagencements

Il vaut mieux regrouper les méthodes qui provoquent des réagencements ou un repaint (changement d’apparence d’un ou plusieurs éléments, sans changements de dimensions) et les éviter autant que possible. Si c’est nécessaire, effectuez de préférence vos modification en-dehors du DOM. Utilisez pour cela un DocumentFragment qui fonctionne à l’identique mais est bien plus léger. Voyez-le comme une façon d’extraire une portion de l’arbre du document ou de créer un nouveau « fragment » de document. Plutôt que de constamment ajouter des nœuds au document principal via le DOM, nous pouvons construire un fragment de document avec ce dont nous avons besoin et l’insérer en une seule fois dans le DOM, ce qui évite des reflows successifs et inutiles.

Par exemple, écrivons une fonction qui ajoute 20 éléments div à un autre. Le faire en ajoutant le nouveau div aussitôt qu’il est créé risque de déclencher 20 réagencements.

function ajouteDivs(element) { var div; for (var i = 0; i < 20; i ++) { div = document.createElement('div'); div.innerHTML = 'Coucou!'; element.appendChild(div); }
}

Pour contourner ce problème, nous pouvons utiliser un DocumentFragment auquel nous ajouterons chaque div. Quand nous intègrerons ce fragment au document principal, tous ses nœuds enfants seront ajoutés en une fois, ce qui ne provoque qu’un seul recalcul.

function ajouteDivs(element) { var div; // Crée un fragment de document vide var fragment = document.createDocumentFragment(); for (var i = 0; i < 20; i ++) { div = document.createElement('a'); div.innerHTML = 'Coucou!'; fragment.appendChild(div); } element.appendChild(fragment);
}

Vous pouvez en savoir plus sur ce thème avec les articles Make the Web Faster, JavaScript Memory Optimization et Finding Memory Leaks.

Détecter les fuites de mémoires dans JavaScript

Afin d’aider à la détection des fuites mémoires, deux de mes collègues Googlers (Marja Hölttä et Jochen Eisinger) ont développé un outil qui fonctionne avec les outils pour développeurs de Google Chrome (avec le protocole d’inspection à distance pour être précis). L’outil récupère plusieurs captures de la pile heap pour détecter les objets provoquant des fuites mémoire.

JPEG - 27.5 ko

Un outil détectant les fuites mémoire dans Javascript

Il existe un billet complet sur la façon d’utiliser l’outil et je vous encourage à le lire ou à jeter un œil sur la page du projet Leak Finder.

Si vous vous demandez pourquoi un tel outil n’est pas directement intégré aux outils pour développeurs, sachez qu’il y a deux raisons. La première, c’est qu’à l’origine l’outil a été développé pour nous aider à capturer des scénarios spécifiques dans la Closure Library, et la deuxième c’est qu’il correspond plus à un outil externe (ou peut-être un jour en tant qu’extension, si nous mettons en place une API de profilage de la pile Heap).

Les options de V8 pour déboguer les optimisations et le ramasse-miette

Chrome supporte le passage d’options directement à V8 via l’option js-flags pour obtenir plus d’informations sur les optimisations effectuées par le moteur. Par exemple, cette commande trace les optimisations de V8 :

/Applications/Google Chrome/Google Chrome" --js-flags="--trace-opt --trace-deopt

Si vous êtes sur Windows, exécutez :

chrome.exe --js-flags="--trace-opt --trace-deopt"

Voici les options de débogage disponibles pour développer avec Chrome :

  1. trace-opt : enregistre dans un fichier le nom des fonctions optimisées et montre à quels endroits V8 ne peut optimiser le code faute de pouvoir le cerner correctement.
  2. trace-deopt : enregistre dans un fichier les portions de code qui ont été déoptimisées pendant l’exécution.
  3. trace-gc : enregistre dans un fichier chaque appel au ramasse-miette.

Dans ces fichiers, V8 indique les fonctions optimisées avec une astérisque (*) et celles qui ne le sont pas avec un tilde (~).

Si vous souhaitez en apprendre plus au sujet des options de V8 et de la façon dont il fonctionne je vous recommande fortement de jeter un œil à l’excellent billet de Vyacheslav Egorov qui résume les meilleurs ressources disponibles actuellement sur le sujet.

Mesures temporelles précises : HRT et Navigation Time API

High Resolution Time (HRT) est une interface JavaScript délivrant une mesure du temps avec une précision de l’ordre du millionième de microseconde, non sujette aux variations de l’horloge système et aux ajustements de cette dernière par l’utilisateur. Voyez cela comme une façon plus précise de faire des tests de performance que la méthode vue précédemment avec new Date() et Date.now(). C’est très pratique quand vous écrivez des tests de performance.

JPEG - 28.3 ko

High Resolution Time (HRT) indique le temps avec une précision au millionième de milliseconde près.

HRT est disponible dans Chrome (version stable) via window.performance.webkitNow(), mais la version canary de Chrome propose déjà une version non-préfixée (window.performance.now()) Paul Irish a rédigé une présentation plus complète de window.performance sur HTML5Rocks.

Nous avons une mesure temporelle précise, mais quid de la mesure précise de performance sur le web ?

Eh bien, nous avons maintenant à notre disposition la Navigation Timing API. Cette API propose une façon simple d’obtenir des mesures précises et détaillées, récupérées durant le chargement de la page et sa présentation aux utilisateurs. Les mesures sont exposées via l’objet window.performance.timing que vous pouvez simplement obtenir par le biais de la console Javascript.

JPEG - 51.8 ko

Mesure de performances affichées dans la console JavaScript.

On peut aisément extraire diverses informations très pratiques des données ci-dessus. Par exemple, la latence du réseau via responseEnd - fetchStart, le temps nécessaire au chargement de la page à partir de sa réception via loadEventEnd - responseEnd et le temps nécessaire pour passer du clic à l’affichage de la nouvelle page via loadEventEnd - navigationStart.

Comme vous pouvez le voir ci-dessus, une propriété performance.memory est disponible. Elle donne des informations sur l’usage de la mémoire par JavaScript comme par exemple la taille de la pile Heap.

Pour plus d’informations sur la Navigation Timing API, lisez le super billet de Sam Dutton : Measuring Page Load Speed With Navigation Timing.

About:memory et about:tracing

about:tracing dans Google Chrome affiche les performances du navigateur lui-même, et enregistre l’activité de chaque thread, de chaque onglet et de chaque processus.

JPEG - 30.1 ko

about:tracing montre les performances du navigateur.

Ce qui est très pratique c’est que cet outile permet de capturer et profiler les mécanismes internes de Chrome de manière à pouvoir ajuster et optimiser votre JavaScript de manière appropriée.

Lili Thompson a écrit un excellent article destiné aux développeurs de jeux vidéos HTML5 sur la façon d’utiliser about:tracing pour le profilage de WebGL. Les autres développeurs y trouveront aussi des informations utiles.

Naviguer à l’intérieur de la page about:memory de Chrome est également d’une grande aide. Il montre l’utilisation exacte de chaque onglet ce qui peut aider à détecter facilement les applications causant des fuites de mémoire.

Conclusion

Comme nous l’avons vu, il y a nombre de subtilités à connaître dans le monde de la performance des moteurs JavaScript, et pas de solution miracle. Ce n’est qu’en confrontant vos optimisations à des tests grandeur nature que vous pourrez estimer les gains en performance les plus importants. De plus, savoir comment les moteurs JavaScript interprètent et optimisent votre code peut vous fournir des pistes pour le développement de vos applications.

Mesurez, comprenez, corrigez ! ...et recommencez.

JPEG - 155.6 ko

Crédits image : Sally Hunter

Soyez conscients de l’importance de la performance, mais sans aller jusqu’aux micros optimisations qui pourraient nuire à la simplicité de votre code. Par exemple, certains développeurs préfèrent utiliser .forEach et Object.keys plutôt que les boucles for et for...in, malgré leur lenteur, pour pouvoir garder la main sur le contexte. Sachez distinguer les optimisations qui sont absolument indispensables à votre application de celles dont elle peut se passer.

Aussi, soyez bien conscient que bien que les moteurs Javascript continuent à améliorer leurs performances, la vraie bataille pour les performances se situe au niveau du DOM. Les réagencements et les recalculs graphiques (reflows et repaints) doivent être évités à tout prix, souvenez-vous donc de ne toucher au DOM que quand c’est absolument nécessaire. Et allez-y mollo sur le réseau : les requêtes HTTP sont précieuses, surtout dans un contexte de mobilité, vous devriez exploiter le maximum du potentiel du cache HTTP pour réduire le poids de vos ressources.

Garder tout cela à l’esprit vous assure de tirer le meilleur parti des informations contenues dans ce billet. J’espère que vous l’avez trouvé utile !

L'article original a été relu par Jakob Kummerow, Michael Starzinger; Sindre Sorhus, Mathias Bynens, John-David Dalton et Paul Irish.

]]> http://www.pompage.net/traduction/javascript-rapide-et-efficace http://www.pompage.net/traduction/javascript-rapide-et-efficace Tue, 26 Aug 2014 10:08:00 +0200 <![CDATA[]]>

Par Addy Osmani

Qu’il s’agisse de V8, de Spider Monkey (Firefox), de Caracan (Opéra) ou de Chakra (IE), connaître le fonctionnement interne du moteur JavaScript vous permettra de mieux optimiser vos applications. Cela ne veut pas dire qu’il faut que vous optimisiez votre code pour un seul moteur ou navigateur : ne faites jamais cela !

Vous devriez plutôt vous poser ce type de questions :

  1. Que puis-je faire pour rendre mon code plus efficient ?
  2. Quelles optimisations communes sont faites par les moteurs JavaScript ?
  3. Quelles sont les limites de l’optimisation de ces moteurs ? Le ramasse-miette est-il bien capable de libérer la mémoire comme je m’y attend ?

Les sites véloces, comme les voitures de course, nécessitent des outils spécialisés. Crédti de l’image : dHybridcars

Nombreux sont les pièges quand on souhaite produire du code rapide et économe en mémoire. Cet article propose donc d’explorer plusieurs techniques testées et approuvées pour écrire du code qui s’exécute efficacement.

Comment fonctionne JavaScript au sein de V8 ?

Bien qu’il soit possible d’écrire des applications volumineuses sans comprendre le fonctionnement des moteurs JavaScript, n’importe quel conducteur vous dira qu’il a déjà jeté un œil sous le capot au moins une fois. Étant donné que Chrome est mon navigateur préféré, je vais vous parler quelque peu de son moteur Javascript. Le cœur de V8 est composé de différentes pièces :

  1. Un compilateur de base qui parcourt votre JavaScript et génère du code machine avant qu’il soit exécuté, plutôt que d’exécuter du bytecode ou simplement de l’interpréter. Ce code natif n’est pour le moment pas très optimisé.
  2. V8 représente vos objets dans un modèle objet. Les objets sont représentés au sein de tableaux associatifs en JavaScript, mais dans V8, ils sont représentés avec les classes cachées (hidden classes) qui sont un système de typage interne pour optimiser la recherche de références.
  3. Le profileur à l’exécution surveille le système en fonctionnement et identifie les fonctions « chaudes » (le code qui est fréquemment exécuté[a]).
  4. Un compilateur optimisé recompile et optimise les fonctions chaudes identifiées par le profileur à l’exécution et procède à des optimisations comme l’inlining (le remplacement des appels de fonction par le corps de la fonction appelée).
  5. V8 supporte le retour sur optimisation[b] ce qui signifie que le compilateur peut révoquer le code optimisé s’il découvre que les optimisations s’avèrent contre-productives.
  6. V8 a également un ramasse-miette. Comprendre son fonctionnement peut être tout aussi important qu’optimiser son JavaScript.

Le ramasse-miette

Le ramasse-miette est un système de gestion de la mémoire. Il introduit la notion de collecteur qui tente de libérer la mémoire occupée par des objets qui ne sont plus utilisés. Dans un langage à ramasse-miette tel que JavaScript les objets qui sont toujours référencés par votre application ne sont pas effacés.

Déréférencer manuellement les objets s’avère inutile la plupart du temps. En déclarant simplement les variables à l’endroit où elles sont nécessaires (idéalement le plus localement possible ; à l’intérieur de la fonction où elles sont utilisées plutôt que dans un contexte parent), cela devrait fonctionner tout seul.

Le ramasse-miette en train de libérer de la mémoire. Crédits de l’image : Valtteri Mäki.

Il est impossible de forcer l’intervention du ramasse-miette en Javascript. Ne pensez pas que c’est dommage, car le processus de libération de la mémoire est contrôlé par l’environnement d’exécution et il sait généralement mieux que vous quand un nettoyage s’impose.

Les mythes du déréférencement

Dans un bon nombre de discussions en ligne à propos de la libération de mémoire en JavaScript, le mot-clé delete a amené certains développeurs à penser qu’ils pouvaient forcer le déréférencement en l’utilisant, alors qu’il est seulement supposé retirer une clé d’un tableau de hachage. Évitez d’utiliser delete si vous le pouvez. Dans l’exemple ci-dessous, delete o.x fait plus de mal que de bien contrairement aux apparences. Il change la classe cachée de l’objet o et le transforme en objet générique plus lent.

var o = { x: 1 };
delete o.x; // true
o.x; // undefined

Cela dit, vous pouvez être certains de trouver delete dans la plupart des bibliothèques JavaScript populaires. Il a une utilité au sein du langage. Ce qu’il faut retenir, c’est qu’il modifie la structure des objets « chauds » à l’exécution. Les moteurs JavaScript repèrent ces objets chauds et tentent de les optimiser. C’est plus facile si la structure de ces objets évolue peu au cours de leur utilisation, or delete impose des changements.

Il y a également des erreurs d’interprétation sur le fonctionnement de null. Attribuer à la référence d’un objet la valeur null ne détruit pas l’objet associé. Cela détruit en réalité la référence à cet objet. Il vaut mieux utiliser o.x=null plutôt que le mot-clé delete, mais c’est rarement utile.

var o = { x: 1 };
o = null;
o; // null
o.x; // TypeError

Si cette référence est la dernière pointant sur cet objet, alors il devient éligible pour être libéré de la mémoire. Mais si ce n’était pas la dernière référence à ce dernier, cet objet reste atteignable et ne sera donc pas détruit.

Une autre chose importante est que les variables globales ne sont pas détruites par le ramasse-miette durant toute la durée de vie de votre page. Que celles-ci soient affichées une fraction de seconde ou plusieurs heures, les variables affectées au contexte global d’exécution du JavaScript resteront en mémoire.

var monEspaceDeNomGlobal = {};

Les variables globales ne sont détruites que lorsque vous rafraîchissez la page, naviguez vers une autre page, fermez l’onglet ou votre navigateur. Les variables rattachées au contexte d’une fonction sont détruites quand elles tombent en dehors du contexte courant. Cela signifie qu’elles sont détruites quand les fonctions sont retirées de la pile d’exécution et qu’il n’y a plus de références pointant vers elles.

Quelques règles générales

Pour donner l’opportunité au ramasse-miette de libérer la mémoire occupée par vos variables le plus tôt possible, ne gardez pas de référence à vos objets plus longtemps que nécessaire. La plupart du temps, cela se fait automatiquement. Mais voici quelques règles à garder en tête :

  1. Comme dit plus haut, déclarez vos variables dans un contexte approprié plutôt que de les déréférencer manuellement. En d’autres termes, au lieu de créer une référence globale que vous devrez déréférencer plus tard, optez pour une variable locale qui sera détruite lorsque son contexte sera sorti de la pile. Vous aurez alors un code plus propre, et moins de choses à gérer.
  2. Assurez-vous de bien supprimer vos écouteurs d’événements des nœuds DOM dès lors qu’ils deviennent inutiles, en particulier juste avant de retirer les nœuds du document.
  3. Si vous cachez localement certaines données, assurez-vous de les nettoyer quand elles ne sont plus utiles ou de programmer leur suppression pour éviter que de trop grands volumes de données ne soient stockées en mémoire.

Les fonctions

Maintenant, intéressons-nous aux fonctions. Comme dit précédemment, le ramasse-miette fonctionne par récupération de pages mémoires qui ne sont plus référencées par l’application. Pour mieux illustrer notre propos, voyons quelques exemples.

function foo() { var bar = new GrosObjet(); bar.appelQuelconque();
}

Quand le fil d’exécution sort de la fonction foo, l’objet vers lequel pointe bar est automatiquement éligible pour être libéré de la mémoire car il n’existe plus aucune référence à cet objet.

Comparons cet exemple au code suivant :

function foo() { var bar = new GrosObjet(); bar.appelQuelconque(); return bar;
} //somewhere else
var b = foo();

Nous avons maintenant une référence à l’objet qui survit à l’appel de la fonction foo et qui persistera tant qu’aucun autre objet ne sera assigné à la variable b (ou tant que b sera dans le contexte d’exécution courant).

Les closures

Quand vous trouvez une fonction qui contient la déclaration d’une autre fonction et retourne une référence vers cette fonction, cette dernière aura accès au contexte de sa fonction parente même si sa fonction parente est retirée de la pile d’exécution. C’est ce qu’on appelle une closure ; c’est une expression qui a accès aux variables situées dans un contexte particulier. Par exemple :

function somme(x) { function faitLaSomme(y) { return x + y; }; return faitLaSomme;
} // Usage
var sommeA = somme(4);
var sommeB = sommeA(3);
console.log(sommeB); // Renvoie 7

L’objet de type function créé lors de l’appel à somme() ne peut être détruit puisqu’il est toujours référencé au sein du contexte global. Il est donc toujours référencé et reste tout ce qu’il y a de plus accessible via sommeA(n).

Intéressons-nous à un autre exemple. Pouvons-nous accéder à longueChaine ?

var a = function () { var longueChaine = new Array(1000000).join('x'); return function () { return longueChaine; };
}();

Oui, bien sûr, via a(), donc elle n’a pas été détruite. Et dans l’exemple suivant ?

var a = function () { var petiteChaine = 'x'; var longueChaine = new Array(1000000).join('x'); return function (n) { return petiteChaine; };
}();

On ne peut plus y accéder et elle est éligible pour être détruite par le ramasse-miette.

Les timers

On trouve beaucoup de fuites de mémoires dans les boucles, mais setTimeout()/setInterval() ne sont pas mal non plus pour ça.

Considérons l’exemple suivant :

var monObjet = { callMeMaybe: function () { var maReference = this; var val = setTimeout(function () { console.log('Tu perds ton temps!'); maReference.callMeMaybe(); }, 1000); }
};

Si nous appelons monObjet.callMeMaybe(); pour mettre en route le timer, nous pourrons voir toutes les secondes dans la console le message suivant : « Tu perds ton temps ! » Si nous tentons :

monObjet = null;

Le timer sera toujours actif. monObjet ne sera pas détruit puisque la closure transmise à setTimeout doit être conservée pour rester accessible. Par effet d’entraînement, monObjet est conservé puisqu’il encapsule maReference. Il en irait de même si nous avions passé cette closure à n’importe quelle autre fonction conservant une référence à cet objet.

C’est également important de garder à l’esprit que les références à l’intérieur des appels à setTimeout/setInterval, comme pour les fonctions, ne pourront être détruites qu’après la complète exécution de ces dernières.

Soyez à l’écoute des problèmes de performance

On ne le répétera jamais assez : n’optimisez votre code que lorsque vous constatez des problèmes de performance. On trouve des tas de micro-benchmarks démontrant que « N » est plus rapide que « M » dans V8, mais confronté à la réalité d’un vrai module de code ou d’une application concrète, l’impact de ces optimisations pourrait être bien moins important que ce que vous pensiez obtenir.

En faire trop peut être aussi problématique que de ne rien faire du tout. Crédits image : Tim Sheerman-Chase

Imaginons que nous voulions créer un module qui :

  1. utilise une source de donnée locale contenant des éléments avec un identifiant numérique,
  2. affiche un tableau contenant ces données,
  3. assigne des gestionnaires d’événements qui commutent une classe quand un utilisateur clique sur une cellule.

Il y a plusieurs chose à prendre en compte dans ce problème, bien qu’il soit très simple à résoudre. Comment stockerons-nous les données ? Comment générer[e] le tableau de manière efficiente et l’insérer dans le DOM ? Comment pouvons-nous capturer les événements émis par le tableau de manière optimale ?

Une première méthode (naïve) serait de stocker chaque silo de données disponible dans des objets que nous regrouperions dans un tableau associatif. On pourrait utiliser jQuery pour parcourir ce tableau de données, générer le tableau et ensuite, l’insérer dans le DOM. Enfin, on pourrait utiliser les écouteurs d’événements pour programmer le comportement désiré au clic sur une cellule.

Ne faites SURTOUT PAS comme ça !

var moduleA = function () { return { data: dataArrayObject, init: function () { this.addTable(); this.addEvents(); }, addTable: function () { for (var i = 0; i < rows; i++) { $tr = $('<tr></tr>'); for (var j = 0; j < this.data.length; j++) { $tr.append('<td>' + this.data[j]['id'] + '</td>'); } $tr.appendTo($tbody); } }, addEvents: function () { $('table td').on('click', function () { $(this).toggleClass('active'); }); } };
}();

C’est basique, mais ça fait ce qui a été demandé.

Dans ce cas, cependant, nous ne faisons qu’utiliser la propriété ID de type numérique qui aurait été plus avantageusement stockée dans un simple tableau. Point intéressant, utiliser documentFragment et les méthodes natives du DOM est plus optimal que d’utiliser jQuery de cette manière pour générer notre tableau. Enfin, bien sûr, écouter les événements au niveau du tableau aurait été plus performant que d’écouter les clics sur chaque cellule.

Notez que jQuery fait appel à DocumentFragment en interne, mais dans notre exemple le code appelle la fonction append() à chaque itération de la boucle, cloisonnement qui empêche une bonne optimisation. Cela ne devrait pas être si catastrophique mais n’oubliez pas de passer votre code au banc d’essai pour vous en assurer.

Dans notre cas, procéder à ces améliorations engendrera de bons gains en performance comme nous pouvons nous y attendre. Écouter les événements au niveau du tableau[g] apporte une amélioration intéressante, quant à l’utilisation de DocumentFragment, elle dope véritablement les performances.

var moduleD = function () { return { data: dataArray, init: function () { this.addTable(); this.addEvents(); }, addTable: function () { var td, tr; var frag = document.createDocumentFragment(); var frag2 = document.createDocumentFragment(); for (var i = 0; i < rows; i++) { tr = document.createElement('tr'); for (var j = 0; j < this.data.length; j++) { td = document.createElement('td'); td.appendChild(document.createTextNode(this.data[j])); frag2.appendChild(td); } tr.appendChild(frag2); frag.appendChild(tr); } tbody.appendChild(frag); }, addEvents: function () { $('table').on('click', 'td', function () { $(this).toggleClass('active'); }); } };
}();

Nous pourrions également tenter d’autres approches pour améliorer les performances. Vous avez probablement lu quelque part qu’utiliser le prototypage est plus optimal que de créer un module (et nous l’avons confirmé au début de cet article), ou entendu que les moteurs de gabarits (templates) JavaScript sont très performants. Ils le sont parfois, mais utilisez-les pour clarifier votre code et précompilez vos gabarits. Testons et voyons si ces pratiques sont aussi intéressantes que ça.

var moduleG = function () {}; moduleG.prototype.data = dataArray;
moduleG.prototype.init = function () { this.addTable(); this.addEvents();
};
moduleG.prototype.addTable = function () { var template = _.template($('#template').text()); var html = template({'data' : this.data}); $tbody.append(html);
};
moduleG.prototype.addEvents = function () { $('table').on('click', 'td', function () { $(this).toggleClass('active'); });
}; var modG = new moduleG();

Comme on pouvait s’y attendre, les bénéfices en terme de performance sont négligeables ici. Les moteurs de template et le prototypage ne nous apportent rien de plus que ce que nous avions auparavant. Cela dit, ce n’est pas vraiment pour les performances que les développeurs modernes utilisent ces outils. C’est plutôt la clarté, le modèle d’héritage et la maintenabilité du code qui les motive.

Certains problèmes plus complexes concernent l’efficience du dessin avec canvas et la manipulation de pixels avec ou sans tableaux typés.

Jetez toujours un œil critique aux micro-benchmarks avant d’appliquer leurs conclusions à vos applications. Certains d’entre vous pourraient se souvenir de l’article Javascript templating shoot-off et la polémique qui s’en est suivie. Vous devez vous assurer que les résultats de vos tests ne sont pas influencés par des contraintes inexistantes dans une application concrète. Testez également ces optimisations dans leur contexte final.

Quelques astuces d’optimisation pour V8

Lister toutes les optimisations réalisables pour V8 s’éloignerait du sujet de cet article, mais voici cependant quelques astuces qui méritent d’être citées. En les gardant à l’esprit vous serez en mesure de limiter l’écriture de code non-performant.

  1. Certaines pratiques telles que l’utilisation de try...catch empêchent V8 de se lancer dans la moindre optimisation. Pour plus d’information sur les fonctions qui peuvent être optimisées et celles qui ne le peuvent pas, utilisez d8, un petit utilitaire en ligne de commande fourni avec V8, et l’option --trace-opt file.js.
  2. Si la vitesse d’exécution vous importe, essayez de garder vos fonctions monomorphes ; assurez-vous que les variables (tableaux, objets, paramètres de fonction) ne contiennent que des éléments du même type. Par exemple, évitez ce genre de code (NdT : en clair, faites comme si JavaScript était un langage typé) :
function ajoute(x, y) { return x+y;
} ajoute(1, 2); ajoute('a','b'); ajoute(mon_objet, undefined);
  1. Ne réutilisez pas des éléments désinitialisés ou supprimés. Le résultat sera identique, mais votre code sera bien plus lent.
  2. N’écrivez pas de fonctions gigantesques car elles sont plus difficiles à optimiser.

Pour plus de trucs et astuces, je vous recommande de visualiser la vidéo Breaking the Javascript speed limit with V8 de Daniel Clifford au Google IO. Je vous recommande également Optimizing For V8 - A Series dans la foulée.

Objets vs Tableaux : que dois-je utiliser ?

  1. Si vous souhaitez stocker un paquet de nombres ou une liste d’objets de même nature, utilisez les tableaux.
  2. Si ce dont vous avez besoin sémantiquement est un objet avec un lot de propriétés (de types différents), utilisez un objet avec des propriétés. C’est très efficient en terme de mémoire et assez rapide d’accès.
  3. Qu’elles soient stockées dans des objets ou des tableaux, les clés numériques sont plus rapides d’accès lors de vos itérations que les propriétés des objets.
  4. Les propriétés des objets sont très complexes : elle peuvent être crées avec des accesseurs (getters/setters) et utiliser différents type d’énumérabilité et d’accès en écriture. Les éléments d’un tableau sont au contraire peu personnalisables ; ils existent ou pas, point final. Au niveau du moteur JavaScript, cela permet plus d’optimisations en terme d’organisation de la mémoire pour représenter sa structure. C’est d’autant plus bénéfique quand ces tableaux contiennent des nombres. Par exemple, si vous avez besoin de stocker des vecteurs, ne définissez pas une classe avec des propriétés x, y et z ; utilisez plutôt un tableau.

Il existe une différence majeure entre les objets et les tableaux en JavaScript, c’est la propriété magique length. Si vous gérez cette propriété vous-même, vos objets seront tout aussi rapides que des tableaux dans V8.

Quelques astuces pour l’utilisation des objets

  1. Créez vos objets via leur fonction constructeur. Cela permet d’assigner à chaque objet la même classe cachée et évite de changer cette dernière par la suite. Un autre point qui plaide pour cela est que c’est légèrement plus rapide que son homologue Object.create().
  2. Il n’y a aucune restriction sur le nombre de types d’objets différents au sein d’une application ou sur leur complexité (tout en restant raisonnable : les longues chaînes de prototype tendent à ralentir l’application, et les objets avec un nombre limité de propriété bénéficient d’une représentation spéciale leur conférant une rapidité accrue). Pour les objets « chauds », essayez de garder une chaîne de prototypes courte et peu de propriétés.

Clonage d’objets

Le clonage d’objets est un problème que rencontrent tous les développeurs d’applications. Bien qu’il soit possible de tester ses différentes implémentations pour observer comment elles se comportent avec le moteur V8, soyez prudents quand vous copiez quoi que ce soit. Copier des gros lots de données est généralement lent, ne le faites pas. Les boucles for...in sont particulièrement inadaptées pour cela car elles ont une spécification démoniaque et ne seront jamais rapides pour des objets arbitraires, quel que soit le moteur JavaScript.

Si vous avez absolument besoin de copier des objets dans une partie critique de votre code en terme de performance (et que vous ne pouvez pas contourner le problème), utilisez un tableau ou un “constructeur de copie” personnalisé qui copie chaque propriété individuellement. C’est probablement la manière la plus rapide de le faire.

function clone(original) { this.foo = original.foo; this.bar = original.bar;
}
var copie = new clone(original);

Les fonctions en cache grâce aux modules

Mettre vos fonctions en cache grâce au patron de conception « module » peut améliorer les performances. Regardez l’exemple ci-dessous, vous constaterez que l’une ou l’autre méthodes que vous avez l’habitude de voir est plus lente car elle oblige à copier les fonctions membres sans arrêt.

Vous noterez également que cette approche peut se révéler significativement meilleure que de s’appuyer sur la technique du prototype (et un test jsPerf le confirme).

Mesure des gains de performance des techniques modules et prototypes.

Voici un test comparatif entre les patrons de conception module et prototype.

 // Technique "Prototype" Klass1 = function () {} Klass1.prototype.foo = function () { log('foo'); } Klass1.prototype.bar = function () { log('bar'); } // Technique "Module" Klass2 = function () { var foo = function () { log('foo'); }, bar = function () { log('bar'); }; return { foo: foo, bar: bar } } // Technique "Module avec fonctions mises en cache" var FooFunction = function () { log('foo'); }; var BarFunction = function () { log('bar'); }; Klass3 = function () { return { foo: FooFunction, bar: BarFunction } } // Tests comparatifs // Prototype var i = 1000, objs = []; while (i--) { var o = new Klass1() objs.push(new Klass1()); o.bar; o.foo; } // Module simple var i = 1000, objs = []; while (i--) { var o = Klass2() objs.push(Klass2()); o.bar; o.foo; } // Module avec fonctions mises en cache var i = 1000, objs = []; while (i--) { var o = Klass3() objs.push(Klass3()); o.bar; o.foo; }
// Le reste du code est sur jsPerf

Quelques astuces pour l’utilisation des tableaux

Maintenant, jetons un œil aux tableaux. En règle générale, ne supprimez pas d’éléments dans les tableaux. Cela oblige le moteur à basculer vers une représentation interne plus lente. Quand les clés d’un tableau deviennent éparpillées, le moteur est susceptible de le transformer en tableau associatif, qui est encore plus lent.

Représentation littérale des tableaux

L’initialisation littérale d’un tableau est préférable puisque cela donne un aperçu à la machine virtuelle de ce que vous souhaitez y stocker (taille, type de valeurs). Ils sont typiquement souhaitables pour des tableaux de taille petite à moyenne.

// Ici, le moteur JS voit que vous souhaitez un tableau contenant 4 nombres
var a = [1, 2, 3, 4]; // Ne faites pas ça :
a = []; // Ici, le moteur n'a aucune idée de ce qui ira dans le tableau
for(var i = 1; i <= 4; i++) { a.push(i);
}

Stocker un seul type de données versus données mixtes

Il n’est jamais bon de mélanger différents types de valeurs dans un même tableau (des nombres, chaînes, objets, booléens ou undefined, comme par exemple : var arr = [1, “1”, undefined, true, “true”]).

Test de performance de l’inférence de type

Comme vous pouvez le constater, le meilleur résultat est obtenu par le tableau d’entiers.

Tableaux à clés consécutives ou non

Quand vous utilisez des tableaux aux clés non consécutives, soyez bien conscients qu’accéder à leurs éléments est bien plus lent que si les clés se suivaient dans leur ordre naturel. La raison est que s’il manque trop d’éléments le moteur V8 choisira de ne pas leur allouer d’espace mémoire. À la place, il préférera les gérer au sein d’un tableau associatif, ce qui est bien plus lent en terme de temps d’accès.

Test comparatifs entre tableaux à clés éparses et clé consécutives

Ce test montre que la somme des éléments d’un tableau aux clés consécutives est plus rapide. Le fait qu’il contienne ou non des zéros ne fait aucune différence.

Tableaux « troués » contre tableaux « pleins »

Évitez de trouer vos tableaux (en supprimant des éléments ou en faisant a[x] = foo (dans le cas où x > a.length). Il suffit qu’un seul élément manque dans un tableau pour ralentir le code.

Test entre tableaux « troués » et tableaux « pleins »

Allouer l’espace du tableau à l’initialisation ou à la volée

Ne pré-allouez pas les tableaux dont la taille excéderait 64 000 éléments. Faites-les plutôt grossir à la volée. Avant d’interpréter les tests sur ce point, rappelez-vous bien que leurs résultats sont fortement dépendants du moteur JavaScript testé.

Test des tableaux initialement vides par rapport aux tableaux pré-alloués.

Nitro (Safari) traite les tableaux pré-alloués plus favorablement. Cependant, c’est le contraire pour les autres moteurs (V8 et Spider Monkey) pour lesquels allouer l’espace à la volée est plus efficace.

Tester les tableaux pré-alloués

// Tableau vide
var arr = [];
for (var i = 0; i < 1000000; i++) { arr[i] = i;
} // Tableau pré-dimensionné
var arr = new Array(1000000);
for (var i = 0; i < 1000000; i++) { arr[i] = i;
}

Optimiser vos applications

Dans le monde des applications Web, la performance est primordiale. Aucun utilisateur ne souhaite qu’un tableur prenne plusieurs secondes pour faire la somme des cellules d’une colonne, ou attendre plusieurs minutes que s’affiche le résumé de leurs messages. C’est pourquoi rendre votre code aussi véloce que possible est parfois critique.

Crédits de l’image : Per Olof Forsberg

Bien qu’il soit utile de comprendre et d’améliorer les performances de vos applications, cela peut être difficile. Nous recommandons la démarche suivante pour venir à bout des points qui vous ralentissent :

  1. Mesurer : repérer les points les plus lents de votre application ( 45%)
  2. Comprendre : trouver ce qui provoque cette lenteur ( 45%)
  3. Corriger ! ( 10%)

Quelques-uns des outils suivants peuvent vous aider dans cette tâche.

Mesurer la performance

Il existe de nombreuses façons de tester les performances de vos bouts de code en JavaScript mais en règle générale on effectue une comparaison entre deux chronométrages. L’équipe de jsPerf a proposé un modèle qui a été ensuite repris par les suites de tests que sont SunSpider et Kraken.

var tempsTotal, depart = new Date, iterations = 1000;
while (iterations--) { // Placer ici le code a tester
}
// tempsTotal → Nombre de millisecondes necessaires // pour executer les instructions 1000 fois
tempsTotal = new Date - depart;

Dans cet exemple le code à tester est placé dans une boucle et exécuté un nombre déterminé de fois. Une fois terminé, la date de début d’exécution est soustraite à la date de fin déterminant le temps écoulé durant le test.

Néanmoins cette façon de faire des tests est très réductrice, surtout si vous voulez mesurer dans différents navigateurs et environnements. Le ramasse-miette lui-même peut avoir des effets sur vos résultats. Même en affinant la mesure en utilisant window.performance, vous pouvez être sûrs que des impondérables viendront fausser les mesures.

Que vous écriviez simplement des tests sur des parties de votre code, des suites de tests ou une librairie complète, il y a bien plus de facteurs à prendre en compte que vous ne pouvez l’imaginer. Pour un guide plus complet sur les tests de performance, je vous recommande fortement de lire Javascript Benchmarking de Mathias Bynens et John-David Dalton.

Le profilage

Les outils pour développeur de Chrome permettent de profiler aisément vos applications. Vous pouvez utiliser cette fonctionnalité pour identifier les fonctions les plus chronophages pour les optimiser en priorité. Cette démarche est importante car la moindre petite modification de votre code peut avoir des conséquences importantes en termes de performance.

L’onglet “profilage” des outils pour développeur de Chrome.

Pour commencer le profilage, il faut obtenir une mesure de base des performances actuelles de votre application. Cette dernière peut être obtenue grâce à l’onglet “timeline” (frise chronologique). Cela nous permettra de mesurer le temps effectif d’exécution de notre application.

L’onglet “profiles” nous donnera lui une vue plus détaillée de ce qui se passe vraiment dans notre application. Le profilage processeur (JavaScript CPU profile) nous permet de savoir combien de temps processeur est utilisé par notre application, le profilage des sélecteurs CSS (CSS selector profile) nous renseigne sur le temps nécessaire pour calculer les sélecteurs CSS, et les captures de pile de mémoire Heap (Heap snapshots) nous permet de savoir combien nos objets consomment de mémoire.

L’utilisation de ces outils nous permet d’ajuster et de profiler à nouveaux notre code afin de vérifier si les changements réalisés ont bien un impact positif sur les performances.

Pour une bonne introduction au profilage dans Chrome, lisez Javascript Profiling With The Chrome Developper Tools par Zack Grossbart.

Petit truc : dans l’idéal, il vaut mieux éviter que les extensions et applications installées dans Chrome n’influent sur vos résultats. Pour cela, exécutez Chrome avec l’option --user-data-dir <un_répertoire_vide>. Cela suffit la plupart du temps, mais si vous avez besoin d’aller plus loin les options de V8 vous seront d’une grande aide.

Eviter les fuites mémoire : trois techniques pour les déceler

Les équipes internes de Google, celle de Gmail par exemple, utilisent énormément les outils pour développeurs de Chrome pour traquer et éliminer les fuites mémoires.

Statistiques d’utilisation mémoire dans les outils pour développeurs.

Les statistiques utilisées par nos équipes sont par exemple : l’utilisation mémoire privée, la taille de la pile Heap de JavaScript, le nombre de nœuds DOM, l’effacement des données, le nombre de gestionnaires d’évènements et le comportement du ramasse-miette. Les habitués des architectures dirigées par les événements seront peut-être contents d’apprendre que la plupart de nos problèmes venaient de l’utilisation de listen() non suivi d’unlisten() (Closure) et par l’absence de dispose() pour les objets créant des gestionnaires d’évènements.

Par chance, les outils pour développeurs peuvent nous aider à localiser ces problèmes et Loreena Lee a créé une présentation fantastique, qui détaille la technique des trois captures pour détecter les fuites mémoires, que je ne vous recommenderai jamais assez de lire.

La base de la technique est d’enregistrer un certain nombre d’action utilisateur dans votre application, forcer l’éxecution du ramasse-miette, vérifier si le nombre de noeuds DOM reste supérieur à la normale puis comparer trois captures successives de la pile Heap pour détecter s’il y a une fuite de mémoire.

Gestion de la mémoire dans les applications sans rechargement de page

La gestion de la mémoire est très importante au sein des applications qui ne sont jamais rechargées (avec AngularJS, Backbone, Ember..). En effet, une fuite de mémoire devient rapidement handicapantes. C’est un énorme piège au sein des applications pour appareils mobiles (qui sont limités en mémoire) comme les clients mails ou les applications de réseaux sociaux qui ont une durée d’utilisation très importante. Comme on dit : de grands pouvoirs impliquent de grandes responsabilités.

Il y a plusieurs façon de se prémunir de cela. Dans Backbone, assurez-vous de toujours déréférencer vos vues et références en utilisant dispose() (actuellement disponible dans Backbone (edge)).

Cette fonction, ajoutée tout récemment, supprime tout gestionnaire associé aux évènements de la vue ainsi qu’à toute collection ou écouteur de modèle pour lesquels la vue a été passée en troisième argument (en tant que contexte de callback). dispose() est également appelé par la méthode remove() de la vue, et s’occupe de nettoyer la majorité de l’utilisation mémoire lorsque la vue est supprimée de l’écran. D’autres librairies, comme Ember, suppriment les observateurs quand ils détectent que les éléments ont étés supprimés de la vue pour éviter les fuites mémoires.

Voici les conseils avisés de Derick Bailey :

Plutôt que d’essayer de comprendre comment fonctionnent les évènements en terme de références, suivez simplement les règles standard de gestion de la mémoire en JavaScript et vous serez tranquilles. Si vous chargez des données dans une collection Backbone pleine d’objets Utilisateurs et voulez que cette collection soit nettoyée par la suite afin de ne plus utiliser de mémoire, vous devez supprimer toute référence à cette collection et aux objets qu’elle contient. Une fois toutes les références supprimées, la mémoire sera libérée. Ce n’est rien d’autre que le comportement standard du ramasse-miette de JavaScript.

Dans son article, Derick couvre la plupart des erreurs communes de gestion de mémoire liées à l’utilisation de Backbone et comment les corriger.

Il y a également un bon tutoriel disponible pour déboguer les fuites mémoires dans Node écrit par Felix Geisendörfer. Particulièrement intéressant si votre application Node est utilisée dans le contexte d’un application sans rechargement de page.

Eviter les réagencements

Quand un navigateur doit recalculer la position et la forme des éléments d’un document afin de les redessiner, il effectue ce qu’on appelle un reflow (réagencement). C’est une opération qui bloque l’interface utilisateur, il est donc important de savoir comment limiter le temps qu’elle dure.

Graphique montrant une succession de réagencements

Il vaut mieux regrouper les méthodes qui provoquent des réagencements ou un repaint (changement d’apparence d’un ou plusieurs éléments, sans changements de dimensions) et les éviter autant que possible. Si c’est nécessaire, effectuez de préférence vos modification en-dehors du DOM. Utilisez pour cela un DocumentFragment qui fonctionne à l’identique mais est bien plus léger. Voyez-le comme une façon d’extraire une portion de l’arbre du document ou de créer un nouveau « fragment » de document. Plutôt que de constamment ajouter des nœuds au document principal via le DOM, nous pouvons construire un fragment de document avec ce dont nous avons besoin et l’insérer en une seule fois dans le DOM, ce qui évite des reflows successifs et inutiles.

Par exemple, écrivons une fonction qui ajoute 20 éléments div à un autre. Le faire en ajoutant le nouveau div aussitôt qu’il est créé risque de déclencher 20 réagencements.

function ajouteDivs(element) { var div; for (var i = 0; i < 20; i ++) { div = document.createElement('div'); div.innerHTML = 'Coucou!'; element.appendChild(div); }
}

Pour contourner ce problème, nous pouvons utiliser un DocumentFragment auquel nous ajouterons chaque div. Quand nous intègrerons ce fragment au document principal, tous ses nœuds enfants seront ajoutés en une fois, ce qui ne provoque qu’un seul recalcul.

function ajouteDivs(element) { var div; // Crée un fragment de document vide var fragment = document.createDocumentFragment(); for (var i = 0; i < 20; i ++) { div = document.createElement('a'); div.innerHTML = 'Coucou!'; fragment.appendChild(div); } element.appendChild(fragment);
}

Vous pouvez en savoir plus sur ce thème avec les articles Make the Web Faster, JavaScript Memory Optimization et Finding Memory Leaks.

Détecter les fuites de mémoires dans JavaScript

Afin d’aider à la détection des fuites mémoires, deux de mes collègues Googlers (Marja Hölttä et Jochen Eisinger) ont développé un outil qui fonctionne avec les outils pour développeurs de Google Chrome (avec le protocole d’inspection à distance pour être précis). L’outil récupère plusieurs captures de la pile heap pour détecter les objets provoquant des fuites mémoire.

Un outil détectant les fuites mémoire dans Javascript

Il existe un billet complet sur la façon d’utiliser l’outil et je vous encourage à le lire ou à jeter un œil sur la page du projet Leak Finder.

Si vous vous demandez pourquoi un tel outil n’est pas directement intégré aux outils pour développeurs, sachez qu’il y a deux raisons. La première, c’est qu’à l’origine l’outil a été développé pour nous aider à capturer des scénarios spécifiques dans la Closure Library, et la deuxième c’est qu’il correspond plus à un outil externe (ou peut-être un jour en tant qu’extension, si nous mettons en place une API de profilage de la pile Heap).

Les options de V8 pour déboguer les optimisations et le ramasse-miette

Chrome supporte le passage d’options directement à V8 via l’option js-flags pour obtenir plus d’informations sur les optimisations effectuées par le moteur. Par exemple, cette commande trace les optimisations de V8 :

/Applications/Google Chrome/Google Chrome" --js-flags="--trace-opt --trace-deopt

Si vous êtes sur Windows, exécutez :

chrome.exe --js-flags="--trace-opt --trace-deopt"

Voici les options de débogage disponibles pour développer avec Chrome :

  1. trace-opt : enregistre dans un fichier le nom des fonctions optimisées et montre à quels endroits V8 ne peut optimiser le code faute de pouvoir le cerner correctement.
  2. trace-deopt : enregistre dans un fichier les portions de code qui ont été déoptimisées pendant l’exécution.
  3. trace-gc : enregistre dans un fichier chaque appel au ramasse-miette.

Dans ces fichiers, V8 indique les fonctions optimisées avec une astérisque (*) et celles qui ne le sont pas avec un tilde (~).

Si vous souhaitez en apprendre plus au sujet des options de V8 et de la façon dont il fonctionne je vous recommande fortement de jeter un œil à l’excellent billet de Vyacheslav Egorov qui résume les meilleurs ressources disponibles actuellement sur le sujet.

Mesures temporelles précises : HRT et Navigation Time API

High Resolution Time (HRT) est une interface JavaScript délivrant une mesure du temps avec une précision de l’ordre du millionième de microseconde, non sujette aux variations de l’horloge système et aux ajustements de cette dernière par l’utilisateur. Voyez cela comme une façon plus précise de faire des tests de performance que la méthode vue précédemment avec new Date() et Date.now(). C’est très pratique quand vous écrivez des tests de performance.

High Resolution Time (HRT) indique le temps avec une précision au millionième de milliseconde près.

HRT est disponible dans Chrome (version stable) via window.performance.webkitNow(), mais la version canary de Chrome propose déjà une version non-préfixée (window.performance.now()) Paul Irish a rédigé une présentation plus complète de window.performance sur HTML5Rocks.

Nous avons une mesure temporelle précise, mais quid de la mesure précise de performance sur le web ?

Eh bien, nous avons maintenant à notre disposition la Navigation Timing API. Cette API propose une façon simple d’obtenir des mesures précises et détaillées, récupérées durant le chargement de la page et sa présentation aux utilisateurs. Les mesures sont exposées via l’objet window.performance.timing que vous pouvez simplement obtenir par le biais de la console Javascript.

Mesure de performances affichées dans la console JavaScript.

On peut aisément extraire diverses informations très pratiques des données ci-dessus. Par exemple, la latence du réseau via responseEnd - fetchStart, le temps nécessaire au chargement de la page à partir de sa réception via loadEventEnd - responseEnd et le temps nécessaire pour passer du clic à l’affichage de la nouvelle page via loadEventEnd - navigationStart.

Comme vous pouvez le voir ci-dessus, une propriété performance.memory est disponible. Elle donne des informations sur l’usage de la mémoire par JavaScript comme par exemple la taille de la pile Heap.

Pour plus d’informations sur la Navigation Timing API, lisez le super billet de Sam Dutton : Measuring Page Load Speed With Navigation Timing.

About:memory et about:tracing

about:tracing dans Google Chrome affiche les performances du navigateur lui-même, et enregistre l’activité de chaque thread, de chaque onglet et de chaque processus.

about:tracing montre les performances du navigateur.

Ce qui est très pratique c’est que cet outile permet de capturer et profiler les mécanismes internes de Chrome de manière à pouvoir ajuster et optimiser votre JavaScript de manière appropriée.

Lili Thompson a écrit un excellent article destiné aux développeurs de jeux vidéos HTML5 sur la façon d’utiliser about:tracing pour le profilage de WebGL. Les autres développeurs y trouveront aussi des informations utiles.

Naviguer à l’intérieur de la page about:memory de Chrome est également d’une grande aide. Il montre l’utilisation exacte de chaque onglet ce qui peut aider à détecter facilement les applications causant des fuites de mémoire.

Conclusion

Comme nous l’avons vu, il y a nombre de subtilités à connaître dans le monde de la performance des moteurs JavaScript, et pas de solution miracle. Ce n’est qu’en confrontant vos optimisations à des tests grandeur nature que vous pourrez estimer les gains en performance les plus importants. De plus, savoir comment les moteurs JavaScript interprètent et optimisent votre code peut vous fournir des pistes pour le développement de vos applications.

Mesurez, comprenez, corrigez ! ...et recommencez.

Crédits image : Sally Hunter

Soyez conscients de l’importance de la performance, mais sans aller jusqu’aux micros optimisations qui pourraient nuire à la simplicité de votre code. Par exemple, certains développeurs préfèrent utiliser .forEach et Object.keys plutôt que les boucles for et for...in, malgré leur lenteur, pour pouvoir garder la main sur le contexte. Sachez distinguer les optimisations qui sont absolument indispensables à votre application de celles dont elle peut se passer.

Aussi, soyez bien conscient que bien que les moteurs Javascript continuent à améliorer leurs performances, la vraie bataille pour les performances se situe au niveau du DOM. Les réagencements et les recalculs graphiques (reflows et repaints) doivent être évités à tout prix, souvenez-vous donc de ne toucher au DOM que quand c’est absolument nécessaire. Et allez-y mollo sur le réseau : les requêtes HTTP sont précieuses, surtout dans un contexte de mobilité, vous devriez exploiter le maximum du potentiel du cache HTTP pour réduire le poids de vos ressources.

Garder tout cela à l’esprit vous assure de tirer le meilleur parti des informations contenues dans ce billet. J’espère que vous l’avez trouvé utile !

L'article original a été relu par Jakob Kummerow, Michael Starzinger; Sindre Sorhus, Mathias Bynens, John-David Dalton et Paul Irish.

]]> http://www.pompage.net/traduction/javascript-rapide-et-efficace http://www.pompage.net/traduction/javascript-rapide-et-efficace Tue, 26 Aug 2014 10:08:00 +0200 <![CDATA[Écrire du JavaScript véloce et à faible empreinte mémoire]]>

Par Addy Osmani

Qu’il s’agisse de V8, de Spider Monkey (Firefox), de Caracan (Opéra) ou de Chakra (IE), connaître le fonctionnement interne du moteur JavaScript vous permettra de mieux optimiser vos applications. Cela ne veut pas dire qu’il faut que vous optimisiez votre code pour un seul moteur ou navigateur : ne faites jamais cela !

Vous devriez plutôt vous poser ce type de questions :

  1. Que puis-je faire pour rendre mon code plus efficient ?
  2. Quelles optimisations communes sont faites par les moteurs JavaScript ?
  3. Quelles sont les limites de l’optimisation de ces moteurs ? Le ramasse-miette est-il bien capable de libérer la mémoire comme je m’y attend ?

Les sites véloces, comme les voitures de course, nécessitent des outils spécialisés. Crédti de l’image : dHybridcars

Nombreux sont les pièges quand on souhaite produire du code rapide et économe en mémoire. Cet article propose donc d’explorer plusieurs techniques testées et approuvées pour écrire du code qui s’exécute efficacement.

Comment fonctionne JavaScript au sein de V8 ?

Bien qu’il soit possible d’écrire des applications volumineuses sans comprendre le fonctionnement des moteurs JavaScript, n’importe quel conducteur vous dira qu’il a déjà jeté un œil sous le capot au moins une fois. Étant donné que Chrome est mon navigateur préféré, je vais vous parler quelque peu de son moteur Javascript. Le cœur de V8 est composé de différentes pièces :

  1. Un compilateur de base qui parcourt votre JavaScript et génère du code machine avant qu’il soit exécuté, plutôt que d’exécuter du bytecode ou simplement de l’interpréter. Ce code natif n’est pour le moment pas très optimisé.
  2. V8 représente vos objets dans un modèle objet. Les objets sont représentés au sein de tableaux associatifs en JavaScript, mais dans V8, ils sont représentés avec les classes cachées (hidden classes) qui sont un système de typage interne pour optimiser la recherche de références.
  3. Le profileur à l’exécution surveille le système en fonctionnement et identifie les fonctions « chaudes » (le code qui est fréquemment exécuté[a]).
  4. Un compilateur optimisé recompile et optimise les fonctions chaudes identifiées par le profileur à l’exécution et procède à des optimisations comme l’inlining (le remplacement des appels de fonction par le corps de la fonction appelée).
  5. V8 supporte le retour sur optimisation[b] ce qui signifie que le compilateur peut révoquer le code optimisé s’il découvre que les optimisations s’avèrent contre-productives.
  6. V8 a également un ramasse-miette. Comprendre son fonctionnement peut être tout aussi important qu’optimiser son JavaScript.

Le ramasse-miette

Le ramasse-miette est un système de gestion de la mémoire. Il introduit la notion de collecteur qui tente de libérer la mémoire occupée par des objets qui ne sont plus utilisés. Dans un langage à ramasse-miette tel que JavaScript les objets qui sont toujours référencés par votre application ne sont pas effacés.

Déréférencer manuellement les objets s’avère inutile la plupart du temps. En déclarant simplement les variables à l’endroit où elles sont nécessaires (idéalement le plus localement possible ; à l’intérieur de la fonction où elles sont utilisées plutôt que dans un contexte parent), cela devrait fonctionner tout seul.

Le ramasse-miette en train de libérer de la mémoire. Crédits de l’image : Valtteri Mäki.

Il est impossible de forcer l’intervention du ramasse-miette en Javascript. Ne pensez pas que c’est dommage, car le processus de libération de la mémoire est contrôlé par l’environnement d’exécution et il sait généralement mieux que vous quand un nettoyage s’impose.

Les mythes du déréférencement

Dans un bon nombre de discussions en ligne à propos de la libération de mémoire en JavaScript, le mot-clé delete a amené certains développeurs à penser qu’ils pouvaient forcer le déréférencement en l’utilisant, alors qu’il est seulement supposé retirer une clé d’un tableau de hachage. Évitez d’utiliser delete si vous le pouvez. Dans l’exemple ci-dessous, delete o.x fait plus de mal que de bien contrairement aux apparences. Il change la classe cachée de l’objet o et le transforme en objet générique plus lent.

var o = { x: 1 };
delete o.x; // true
o.x; // undefined

Cela dit, vous pouvez être certains de trouver delete dans la plupart des bibliothèques JavaScript populaires. Il a une utilité au sein du langage. Ce qu’il faut retenir, c’est qu’il modifie la structure des objets « chauds » à l’exécution. Les moteurs JavaScript repèrent ces objets chauds et tentent de les optimiser. C’est plus facile si la structure de ces objets évolue peu au cours de leur utilisation, or delete impose des changements.

Il y a également des erreurs d’interprétation sur le fonctionnement de null. Attribuer à la référence d’un objet la valeur null ne détruit pas l’objet associé. Cela détruit en réalité la référence à cet objet. Il vaut mieux utiliser o.x=null plutôt que le mot-clé delete, mais c’est rarement utile.

var o = { x: 1 };
o = null;
o; // null
o.x; // TypeError

Si cette référence est la dernière pointant sur cet objet, alors il devient éligible pour être libéré de la mémoire. Mais si ce n’était pas la dernière référence à ce dernier, cet objet reste atteignable et ne sera donc pas détruit.

Une autre chose importante est que les variables globales ne sont pas détruites par le ramasse-miette durant toute la durée de vie de votre page. Que celles-ci soient affichées une fraction de seconde ou plusieurs heures, les variables affectées au contexte global d’exécution du JavaScript resteront en mémoire.

var monEspaceDeNomGlobal = {};

Les variables globales ne sont détruites que lorsque vous rafraîchissez la page, naviguez vers une autre page, fermez l’onglet ou votre navigateur. Les variables rattachées au contexte d’une fonction sont détruites quand elles tombent en dehors du contexte courant. Cela signifie qu’elles sont détruites quand les fonctions sont retirées de la pile d’exécution et qu’il n’y a plus de références pointant vers elles.

Quelques règles générales

Pour donner l’opportunité au ramasse-miette de libérer la mémoire occupée par vos variables le plus tôt possible, ne gardez pas de référence à vos objets plus longtemps que nécessaire. La plupart du temps, cela se fait automatiquement. Mais voici quelques règles à garder en tête :

  1. Comme dit plus haut, déclarez vos variables dans un contexte approprié plutôt que de les déréférencer manuellement. En d’autres termes, au lieu de créer une référence globale que vous devrez déréférencer plus tard, optez pour une variable locale qui sera détruite lorsque son contexte sera sorti de la pile. Vous aurez alors un code plus propre, et moins de choses à gérer.
  2. Assurez-vous de bien supprimer vos écouteurs d’événements des nœuds DOM dès lors qu’ils deviennent inutiles, en particulier juste avant de retirer les nœuds du document.
  3. Si vous cachez localement certaines données, assurez-vous de les nettoyer quand elles ne sont plus utiles ou de programmer leur suppression pour éviter que de trop grands volumes de données ne soient stockées en mémoire.

Les fonctions

Maintenant, intéressons-nous aux fonctions. Comme dit précédemment, le ramasse-miette fonctionne par récupération de pages mémoires qui ne sont plus référencées par l’application. Pour mieux illustrer notre propos, voyons quelques exemples.

function foo() { var bar = new GrosObjet(); bar.appelQuelconque();
}

Quand le fil d’exécution sort de la fonction foo, l’objet vers lequel pointe bar est automatiquement éligible pour être libéré de la mémoire car il n’existe plus aucune référence à cet objet.

Comparons cet exemple au code suivant :

function foo() { var bar = new GrosObjet(); bar.appelQuelconque(); return bar;
} //somewhere else
var b = foo();

Nous avons maintenant une référence à l’objet qui survit à l’appel de la fonction foo et qui persistera tant qu’aucun autre objet ne sera assigné à la variable b (ou tant que b sera dans le contexte d’exécution courant).

Les closures

Quand vous trouvez une fonction qui contient la déclaration d’une autre fonction et retourne une référence vers cette fonction, cette dernière aura accès au contexte de sa fonction parente même si sa fonction parente est retirée de la pile d’exécution. C’est ce qu’on appelle une closure ; c’est une expression qui a accès aux variables situées dans un contexte particulier. Par exemple :

function somme(x) { function faitLaSomme(y) { return x + y; }; return faitLaSomme;
} // Usage
var sommeA = somme(4);
var sommeB = sommeA(3);
console.log(sommeB); // Renvoie 7

L’objet de type function créé lors de l’appel à somme() ne peut être détruit puisqu’il est toujours référencé au sein du contexte global. Il est donc toujours référencé et reste tout ce qu’il y a de plus accessible via sommeA(n).

Intéressons-nous à un autre exemple. Pouvons-nous accéder à longueChaine ?

var a = function () { var longueChaine = new Array(1000000).join('x'); return function () { return longueChaine; };
}();

Oui, bien sûr, via a(), donc elle n’a pas été détruite. Et dans l’exemple suivant ?

var a = function () { var petiteChaine = 'x'; var longueChaine = new Array(1000000).join('x'); return function (n) { return petiteChaine; };
}();

On ne peut plus y accéder et elle est éligible pour être détruite par le ramasse-miette.

Les timers

On trouve beaucoup de fuites de mémoires dans les boucles, mais setTimeout()/setInterval() ne sont pas mal non plus pour ça.

Considérons l’exemple suivant :

var monObjet = { callMeMaybe: function () { var maReference = this; var val = setTimeout(function () { console.log('Tu perds ton temps!'); maReference.callMeMaybe(); }, 1000); }
};

Si nous appelons monObjet.callMeMaybe(); pour mettre en route le timer, nous pourrons voir toutes les secondes dans la console le message suivant : « Tu perds ton temps ! » Si nous tentons :

monObjet = null;

Le timer sera toujours actif. monObjet ne sera pas détruit puisque la closure transmise à setTimeout doit être conservée pour rester accessible. Par effet d’entraînement, monObjet est conservé puisqu’il encapsule maReference. Il en irait de même si nous avions passé cette closure à n’importe quelle autre fonction conservant une référence à cet objet.

C’est également important de garder à l’esprit que les références à l’intérieur des appels à setTimeout/setInterval, comme pour les fonctions, ne pourront être détruites qu’après la complète exécution de ces dernières.

Soyez à l’écoute des problèmes de performance

On ne le répétera jamais assez : n’optimisez votre code que lorsque vous constatez des problèmes de performance. On trouve des tas de micro-benchmarks démontrant que « N » est plus rapide que « M » dans V8, mais confronté à la réalité d’un vrai module de code ou d’une application concrète, l’impact de ces optimisations pourrait être bien moins important que ce que vous pensiez obtenir.

En faire trop peut être aussi problématique que de ne rien faire du tout. Crédits image : Tim Sheerman-Chase

Imaginons que nous voulions créer un module qui :

  1. utilise une source de donnée locale contenant des éléments avec un identifiant numérique,
  2. affiche un tableau contenant ces données,
  3. assigne des gestionnaires d’événements qui commutent une classe quand un utilisateur clique sur une cellule.

Il y a plusieurs chose à prendre en compte dans ce problème, bien qu’il soit très simple à résoudre. Comment stockerons-nous les données ? Comment générer[e] le tableau de manière efficiente et l’insérer dans le DOM ? Comment pouvons-nous capturer les événements émis par le tableau de manière optimale ?

Une première méthode (naïve) serait de stocker chaque silo de données disponible dans des objets que nous regrouperions dans un tableau associatif. On pourrait utiliser jQuery pour parcourir ce tableau de données, générer le tableau et ensuite, l’insérer dans le DOM. Enfin, on pourrait utiliser les écouteurs d’événements pour programmer le comportement désiré au clic sur une cellule.

Ne faites SURTOUT PAS comme ça !

var moduleA = function () { return { data: dataArrayObject, init: function () { this.addTable(); this.addEvents(); }, addTable: function () { for (var i = 0; i < rows; i++) { $tr = $('<tr></tr>'); for (var j = 0; j < this.data.length; j++) { $tr.append('<td>' + this.data[j]['id'] + '</td>'); } $tr.appendTo($tbody); } }, addEvents: function () { $('table td').on('click', function () { $(this).toggleClass('active'); }); } };
}();

C’est basique, mais ça fait ce qui a été demandé.

Dans ce cas, cependant, nous ne faisons qu’utiliser la propriété ID de type numérique qui aurait été plus avantageusement stockée dans un simple tableau. Point intéressant, utiliser documentFragment et les méthodes natives du DOM est plus optimal que d’utiliser jQuery de cette manière pour générer notre tableau. Enfin, bien sûr, écouter les événements au niveau du tableau aurait été plus performant que d’écouter les clics sur chaque cellule.

Notez que jQuery fait appel à DocumentFragment en interne, mais dans notre exemple le code appelle la fonction append() à chaque itération de la boucle, cloisonnement qui empêche une bonne optimisation. Cela ne devrait pas être si catastrophique mais n’oubliez pas de passer votre code au banc d’essai pour vous en assurer.

Dans notre cas, procéder à ces améliorations engendrera de bons gains en performance comme nous pouvons nous y attendre. Écouter les événements au niveau du tableau[g] apporte une amélioration intéressante, quant à l’utilisation de DocumentFragment, elle dope véritablement les performances.

var moduleD = function () { return { data: dataArray, init: function () { this.addTable(); this.addEvents(); }, addTable: function () { var td, tr; var frag = document.createDocumentFragment(); var frag2 = document.createDocumentFragment(); for (var i = 0; i < rows; i++) { tr = document.createElement('tr'); for (var j = 0; j < this.data.length; j++) { td = document.createElement('td'); td.appendChild(document.createTextNode(this.data[j])); frag2.appendChild(td); } tr.appendChild(frag2); frag.appendChild(tr); } tbody.appendChild(frag); }, addEvents: function () { $('table').on('click', 'td', function () { $(this).toggleClass('active'); }); } };
}();

Nous pourrions également tenter d’autres approches pour améliorer les performances. Vous avez probablement lu quelque part qu’utiliser le prototypage est plus optimal que de créer un module (et nous l’avons confirmé au début de cet article), ou entendu que les moteurs de gabarits (templates) JavaScript sont très performants. Ils le sont parfois, mais utilisez-les pour clarifier votre code et précompilez vos gabarits. Testons et voyons si ces pratiques sont aussi intéressantes que ça.

var moduleG = function () {}; moduleG.prototype.data = dataArray;
moduleG.prototype.init = function () { this.addTable(); this.addEvents();
};
moduleG.prototype.addTable = function () { var template = _.template($('#template').text()); var html = template({'data' : this.data}); $tbody.append(html);
};
moduleG.prototype.addEvents = function () { $('table').on('click', 'td', function () { $(this).toggleClass('active'); });
}; var modG = new moduleG();

Comme on pouvait s’y attendre, les bénéfices en terme de performance sont négligeables ici. Les moteurs de template et le prototypage ne nous apportent rien de plus que ce que nous avions auparavant. Cela dit, ce n’est pas vraiment pour les performances que les développeurs modernes utilisent ces outils. C’est plutôt la clarté, le modèle d’héritage et la maintenabilité du code qui les motive.

Certains problèmes plus complexes concernent l’efficience du dessin avec canvas et la manipulation de pixels avec ou sans tableaux typés.

Jetez toujours un œil critique aux micro-benchmarks avant d’appliquer leurs conclusions à vos applications. Certains d’entre vous pourraient se souvenir de l’article Javascript templating shoot-off et la polémique qui s’en est suivie. Vous devez vous assurer que les résultats de vos tests ne sont pas influencés par des contraintes inexistantes dans une application concrète. Testez également ces optimisations dans leur contexte final.

Quelques astuces d’optimisation pour V8

Lister toutes les optimisations réalisables pour V8 s’éloignerait du sujet de cet article, mais voici cependant quelques astuces qui méritent d’être citées. En les gardant à l’esprit vous serez en mesure de limiter l’écriture de code non-performant.

  1. Certaines pratiques telles que l’utilisation de try...catch empêchent V8 de se lancer dans la moindre optimisation. Pour plus d’information sur les fonctions qui peuvent être optimisées et celles qui ne le peuvent pas, utilisez d8, un petit utilitaire en ligne de commande fourni avec V8, et l’option --trace-opt file.js.
  2. Si la vitesse d’exécution vous importe, essayez de garder vos fonctions monomorphes ; assurez-vous que les variables (tableaux, objets, paramètres de fonction) ne contiennent que des éléments du même type. Par exemple, évitez ce genre de code (NdT : en clair, faites comme si JavaScript était un langage typé) :
function ajoute(x, y) { return x+y;
} ajoute(1, 2); ajoute('a','b'); ajoute(mon_objet, undefined);
  1. Ne réutilisez pas des éléments désinitialisés ou supprimés. Le résultat sera identique, mais votre code sera bien plus lent.
  2. N’écrivez pas de fonctions gigantesques car elles sont plus difficiles à optimiser.

Pour plus de trucs et astuces, je vous recommande de visualiser la vidéo Breaking the Javascript speed limit with V8 de Daniel Clifford au Google IO. Je vous recommande également Optimizing For V8 - A Series dans la foulée.

Objets vs Tableaux : que dois-je utiliser ?

  1. Si vous souhaitez stocker un paquet de nombres ou une liste d’objets de même nature, utilisez les tableaux.
  2. Si ce dont vous avez besoin sémantiquement est un objet avec un lot de propriétés (de types différents), utilisez un objet avec des propriétés. C’est très efficient en terme de mémoire et assez rapide d’accès.
  3. Qu’elles soient stockées dans des objets ou des tableaux, les clés numériques sont plus rapides d’accès lors de vos itérations que les propriétés des objets.
  4. Les propriétés des objets sont très complexes : elle peuvent être crées avec des accesseurs (getters/setters) et utiliser différents type d’énumérabilité et d’accès en écriture. Les éléments d’un tableau sont au contraire peu personnalisables ; ils existent ou pas, point final. Au niveau du moteur JavaScript, cela permet plus d’optimisations en terme d’organisation de la mémoire pour représenter sa structure. C’est d’autant plus bénéfique quand ces tableaux contiennent des nombres. Par exemple, si vous avez besoin de stocker des vecteurs, ne définissez pas une classe avec des propriétés x, y et z ; utilisez plutôt un tableau.

Il existe une différence majeure entre les objets et les tableaux en JavaScript, c’est la propriété magique length. Si vous gérez cette propriété vous-même, vos objets seront tout aussi rapides que des tableaux dans V8.

Quelques astuces pour l’utilisation des objets

  1. Créez vos objets via leur fonction constructeur. Cela permet d’assigner à chaque objet la même classe cachée et évite de changer cette dernière par la suite. Un autre point qui plaide pour cela est que c’est légèrement plus rapide que son homologue Object.create().
  2. Il n’y a aucune restriction sur le nombre de types d’objets différents au sein d’une application ou sur leur complexité (tout en restant raisonnable : les longues chaînes de prototype tendent à ralentir l’application, et les objets avec un nombre limité de propriété bénéficient d’une représentation spéciale leur conférant une rapidité accrue). Pour les objets « chauds », essayez de garder une chaîne de prototypes courte et peu de propriétés.

Clonage d’objets

Le clonage d’objets est un problème que rencontrent tous les développeurs d’applications. Bien qu’il soit possible de tester ses différentes implémentations pour observer comment elles se comportent avec le moteur V8, soyez prudents quand vous copiez quoi que ce soit. Copier des gros lots de données est généralement lent, ne le faites pas. Les boucles for...in sont particulièrement inadaptées pour cela car elles ont une spécification démoniaque et ne seront jamais rapides pour des objets arbitraires, quel que soit le moteur JavaScript.

Si vous avez absolument besoin de copier des objets dans une partie critique de votre code en terme de performance (et que vous ne pouvez pas contourner le problème), utilisez un tableau ou un “constructeur de copie” personnalisé qui copie chaque propriété individuellement. C’est probablement la manière la plus rapide de le faire.

function clone(original) { this.foo = original.foo; this.bar = original.bar;
}
var copie = new clone(original);

Les fonctions en cache grâce aux modules

Mettre vos fonctions en cache grâce au patron de conception « module » peut améliorer les performances. Regardez l’exemple ci-dessous, vous constaterez que l’une ou l’autre méthodes que vous avez l’habitude de voir est plus lente car elle oblige à copier les fonctions membres sans arrêt.

Vous noterez également que cette approche peut se révéler significativement meilleure que de s’appuyer sur la technique du prototype (et un test jsPerf le confirme).

Mesure des gains de performance des techniques modules et prototypes.

Voici un test comparatif entre les patrons de conception module et prototype.

 // Technique "Prototype" Klass1 = function () {} Klass1.prototype.foo = function () { log('foo'); } Klass1.prototype.bar = function () { log('bar'); } // Technique "Module" Klass2 = function () { var foo = function () { log('foo'); }, bar = function () { log('bar'); }; return { foo: foo, bar: bar } } // Technique "Module avec fonctions mises en cache" var FooFunction = function () { log('foo'); }; var BarFunction = function () { log('bar'); }; Klass3 = function () { return { foo: FooFunction, bar: BarFunction } } // Tests comparatifs // Prototype var i = 1000, objs = []; while (i--) { var o = new Klass1() objs.push(new Klass1()); o.bar; o.foo; } // Module simple var i = 1000, objs = []; while (i--) { var o = Klass2() objs.push(Klass2()); o.bar; o.foo; } // Module avec fonctions mises en cache var i = 1000, objs = []; while (i--) { var o = Klass3() objs.push(Klass3()); o.bar; o.foo; }
// Le reste du code est sur jsPerf

Quelques astuces pour l’utilisation des tableaux

Maintenant, jetons un œil aux tableaux. En règle générale, ne supprimez pas d’éléments dans les tableaux. Cela oblige le moteur à basculer vers une représentation interne plus lente. Quand les clés d’un tableau deviennent éparpillées, le moteur est susceptible de le transformer en tableau associatif, qui est encore plus lent.

Représentation littérale des tableaux

L’initialisation littérale d’un tableau est préférable puisque cela donne un aperçu à la machine virtuelle de ce que vous souhaitez y stocker (taille, type de valeurs). Ils sont typiquement souhaitables pour des tableaux de taille petite à moyenne.

// Ici, le moteur JS voit que vous souhaitez un tableau contenant 4 nombres
var a = [1, 2, 3, 4]; // Ne faites pas ça :
a = []; // Ici, le moteur n'a aucune idée de ce qui ira dans le tableau
for(var i = 1; i <= 4; i++) { a.push(i);
}

Stocker un seul type de données versus données mixtes

Il n’est jamais bon de mélanger différents types de valeurs dans un même tableau (des nombres, chaînes, objets, booléens ou undefined, comme par exemple : var arr = [1, “1”, undefined, true, “true”]).

Test de performance de l’inférence de type

Comme vous pouvez le constater, le meilleur résultat est obtenu par le tableau d’entiers.

Tableaux à clés consécutives ou non

Quand vous utilisez des tableaux aux clés non consécutives, soyez bien conscients qu’accéder à leurs éléments est bien plus lent que si les clés se suivaient dans leur ordre naturel. La raison est que s’il manque trop d’éléments le moteur V8 choisira de ne pas leur allouer d’espace mémoire. À la place, il préférera les gérer au sein d’un tableau associatif, ce qui est bien plus lent en terme de temps d’accès.

Test comparatifs entre tableaux à clés éparses et clé consécutives

Ce test montre que la somme des éléments d’un tableau aux clés consécutives est plus rapide. Le fait qu’il contienne ou non des zéros ne fait aucune différence.

Tableaux « troués » contre tableaux « pleins »

Évitez de trouer vos tableaux (en supprimant des éléments ou en faisant a[x] = foo (dans le cas où x > a.length). Il suffit qu’un seul élément manque dans un tableau pour ralentir le code.

Test entre tableaux « troués » et tableaux « pleins »

Allouer l’espace du tableau à l’initialisation ou à la volée

Ne pré-allouez pas les tableaux dont la taille excéderait 64 000 éléments. Faites-les plutôt grossir à la volée. Avant d’interpréter les tests sur ce point, rappelez-vous bien que leurs résultats sont fortement dépendants du moteur JavaScript testé.

Test des tableaux initialement vides par rapport aux tableaux pré-alloués.

Nitro (Safari) traite les tableaux pré-alloués plus favorablement. Cependant, c’est le contraire pour les autres moteurs (V8 et Spider Monkey) pour lesquels allouer l’espace à la volée est plus efficace.

Tester les tableaux pré-alloués

// Tableau vide
var arr = [];
for (var i = 0; i < 1000000; i++) { arr[i] = i;
} // Tableau pré-dimensionné
var arr = new Array(1000000);
for (var i = 0; i < 1000000; i++) { arr[i] = i;
}

Optimiser vos applications

Dans le monde des applications Web, la performance est primordiale. Aucun utilisateur ne souhaite qu’un tableur prenne plusieurs secondes pour faire la somme des cellules d’une colonne, ou attendre plusieurs minutes que s’affiche le résumé de leurs messages. C’est pourquoi rendre votre code aussi véloce que possible est parfois critique.

Crédits de l’image : Per Olof Forsberg

Bien qu’il soit utile de comprendre et d’améliorer les performances de vos applications, cela peut être difficile. Nous recommandons la démarche suivante pour venir à bout des points qui vous ralentissent :

  1. Mesurer : repérer les points les plus lents de votre application ( 45%)
  2. Comprendre : trouver ce qui provoque cette lenteur ( 45%)
  3. Corriger ! ( 10%)

Quelques-uns des outils suivants peuvent vous aider dans cette tâche.

Mesurer la performance

Il existe de nombreuses façons de tester les performances de vos bouts de code en JavaScript mais en règle générale on effectue une comparaison entre deux chronométrages. L’équipe de jsPerf a proposé un modèle qui a été ensuite repris par les suites de tests que sont SunSpider et Kraken.

var tempsTotal, depart = new Date, iterations = 1000;
while (iterations--) { // Placer ici le code a tester
}
// tempsTotal → Nombre de millisecondes necessaires // pour executer les instructions 1000 fois
tempsTotal = new Date - depart;

Dans cet exemple le code à tester est placé dans une boucle et exécuté un nombre déterminé de fois. Une fois terminé, la date de début d’exécution est soustraite à la date de fin déterminant le temps écoulé durant le test.

Néanmoins cette façon de faire des tests est très réductrice, surtout si vous voulez mesurer dans différents navigateurs et environnements. Le ramasse-miette lui-même peut avoir des effets sur vos résultats. Même en affinant la mesure en utilisant window.performance, vous pouvez être sûrs que des impondérables viendront fausser les mesures.

Que vous écriviez simplement des tests sur des parties de votre code, des suites de tests ou une librairie complète, il y a bien plus de facteurs à prendre en compte que vous ne pouvez l’imaginer. Pour un guide plus complet sur les tests de performance, je vous recommande fortement de lire Javascript Benchmarking de Mathias Bynens et John-David Dalton.

Le profilage

Les outils pour développeur de Chrome permettent de profiler aisément vos applications. Vous pouvez utiliser cette fonctionnalité pour identifier les fonctions les plus chronophages pour les optimiser en priorité. Cette démarche est importante car la moindre petite modification de votre code peut avoir des conséquences importantes en termes de performance.

L’onglet “profilage” des outils pour développeur de Chrome.

Pour commencer le profilage, il faut obtenir une mesure de base des performances actuelles de votre application. Cette dernière peut être obtenue grâce à l’onglet “timeline” (frise chronologique). Cela nous permettra de mesurer le temps effectif d’exécution de notre application.

L’onglet “profiles” nous donnera lui une vue plus détaillée de ce qui se passe vraiment dans notre application. Le profilage processeur (JavaScript CPU profile) nous permet de savoir combien de temps processeur est utilisé par notre application, le profilage des sélecteurs CSS (CSS selector profile) nous renseigne sur le temps nécessaire pour calculer les sélecteurs CSS, et les captures de pile de mémoire Heap (Heap snapshots) nous permet de savoir combien nos objets consomment de mémoire.

L’utilisation de ces outils nous permet d’ajuster et de profiler à nouveaux notre code afin de vérifier si les changements réalisés ont bien un impact positif sur les performances.

Pour une bonne introduction au profilage dans Chrome, lisez Javascript Profiling With The Chrome Developper Tools par Zack Grossbart.

Petit truc : dans l’idéal, il vaut mieux éviter que les extensions et applications installées dans Chrome n’influent sur vos résultats. Pour cela, exécutez Chrome avec l’option --user-data-dir <un_répertoire_vide>. Cela suffit la plupart du temps, mais si vous avez besoin d’aller plus loin les options de V8 vous seront d’une grande aide.

Eviter les fuites mémoire : trois techniques pour les déceler

Les équipes internes de Google, celle de Gmail par exemple, utilisent énormément les outils pour développeurs de Chrome pour traquer et éliminer les fuites mémoires.

Statistiques d’utilisation mémoire dans les outils pour développeurs.

Les statistiques utilisées par nos équipes sont par exemple : l’utilisation mémoire privée, la taille de la pile Heap de JavaScript, le nombre de nœuds DOM, l’effacement des données, le nombre de gestionnaires d’évènements et le comportement du ramasse-miette. Les habitués des architectures dirigées par les événements seront peut-être contents d’apprendre que la plupart de nos problèmes venaient de l’utilisation de listen() non suivi d’unlisten() (Closure) et par l’absence de dispose() pour les objets créant des gestionnaires d’évènements.

Par chance, les outils pour développeurs peuvent nous aider à localiser ces problèmes et Loreena Lee a créé une présentation fantastique, qui détaille la technique des trois captures pour détecter les fuites mémoires, que je ne vous recommenderai jamais assez de lire.

La base de la technique est d’enregistrer un certain nombre d’action utilisateur dans votre application, forcer l’éxecution du ramasse-miette, vérifier si le nombre de noeuds DOM reste supérieur à la normale puis comparer trois captures successives de la pile Heap pour détecter s’il y a une fuite de mémoire.

Gestion de la mémoire dans les applications sans rechargement de page

La gestion de la mémoire est très importante au sein des applications qui ne sont jamais rechargées (avec AngularJS, Backbone, Ember..). En effet, une fuite de mémoire devient rapidement handicapantes. C’est un énorme piège au sein des applications pour appareils mobiles (qui sont limités en mémoire) comme les clients mails ou les applications de réseaux sociaux qui ont une durée d’utilisation très importante. Comme on dit : de grands pouvoirs impliquent de grandes responsabilités.

Il y a plusieurs façon de se prémunir de cela. Dans Backbone, assurez-vous de toujours déréférencer vos vues et références en utilisant dispose() (actuellement disponible dans Backbone (edge)).

Cette fonction, ajoutée tout récemment, supprime tout gestionnaire associé aux évènements de la vue ainsi qu’à toute collection ou écouteur de modèle pour lesquels la vue a été passée en troisième argument (en tant que contexte de callback). dispose() est également appelé par la méthode remove() de la vue, et s’occupe de nettoyer la majorité de l’utilisation mémoire lorsque la vue est supprimée de l’écran. D’autres librairies, comme Ember, suppriment les observateurs quand ils détectent que les éléments ont étés supprimés de la vue pour éviter les fuites mémoires.

Voici les conseils avisés de Derick Bailey :

Plutôt que d’essayer de comprendre comment fonctionnent les évènements en terme de références, suivez simplement les règles standard de gestion de la mémoire en JavaScript et vous serez tranquilles. Si vous chargez des données dans une collection Backbone pleine d’objets Utilisateurs et voulez que cette collection soit nettoyée par la suite afin de ne plus utiliser de mémoire, vous devez supprimer toute référence à cette collection et aux objets qu’elle contient. Une fois toutes les références supprimées, la mémoire sera libérée. Ce n’est rien d’autre que le comportement standard du ramasse-miette de JavaScript.

Dans son article, Derick couvre la plupart des erreurs communes de gestion de mémoire liées à l’utilisation de Backbone et comment les corriger.

Il y a également un bon tutoriel disponible pour déboguer les fuites mémoires dans Node écrit par Felix Geisendörfer. Particulièrement intéressant si votre application Node est utilisée dans le contexte d’un application sans rechargement de page.

Eviter les réagencements

Quand un navigateur doit recalculer la position et la forme des éléments d’un document afin de les redessiner, il effectue ce qu’on appelle un reflow (réagencement). C’est une opération qui bloque l’interface utilisateur, il est donc important de savoir comment limiter le temps qu’elle dure.

Graphique montrant une succession de réagencements

Il vaut mieux regrouper les méthodes qui provoquent des réagencements ou un repaint (changement d’apparence d’un ou plusieurs éléments, sans changements de dimensions) et les éviter autant que possible. Si c’est nécessaire, effectuez de préférence vos modification en-dehors du DOM. Utilisez pour cela un DocumentFragment qui fonctionne à l’identique mais est bien plus léger. Voyez-le comme une façon d’extraire une portion de l’arbre du document ou de créer un nouveau « fragment » de document. Plutôt que de constamment ajouter des nœuds au document principal via le DOM, nous pouvons construire un fragment de document avec ce dont nous avons besoin et l’insérer en une seule fois dans le DOM, ce qui évite des reflows successifs et inutiles.

Par exemple, écrivons une fonction qui ajoute 20 éléments div à un autre. Le faire en ajoutant le nouveau div aussitôt qu’il est créé risque de déclencher 20 réagencements.

function ajouteDivs(element) { var div; for (var i = 0; i < 20; i ++) { div = document.createElement('div'); div.innerHTML = 'Coucou!'; element.appendChild(div); }
}

Pour contourner ce problème, nous pouvons utiliser un DocumentFragment auquel nous ajouterons chaque div. Quand nous intègrerons ce fragment au document principal, tous ses nœuds enfants seront ajoutés en une fois, ce qui ne provoque qu’un seul recalcul.

function ajouteDivs(element) { var div; // Crée un fragment de document vide var fragment = document.createDocumentFragment(); for (var i = 0; i < 20; i ++) { div = document.createElement('a'); div.innerHTML = 'Coucou!'; fragment.appendChild(div); } element.appendChild(fragment);
}

Vous pouvez en savoir plus sur ce thème avec les articles Make the Web Faster, JavaScript Memory Optimization et Finding Memory Leaks.

Détecter les fuites de mémoires dans JavaScript

Afin d’aider à la détection des fuites mémoires, deux de mes collègues Googlers (Marja Hölttä et Jochen Eisinger) ont développé un outil qui fonctionne avec les outils pour développeurs de Google Chrome (avec le protocole d’inspection à distance pour être précis). L’outil récupère plusieurs captures de la pile heap pour détecter les objets provoquant des fuites mémoire.

Un outil détectant les fuites mémoire dans Javascript

Il existe un billet complet sur la façon d’utiliser l’outil et je vous encourage à le lire ou à jeter un œil sur la page du projet Leak Finder.

Si vous vous demandez pourquoi un tel outil n’est pas directement intégré aux outils pour développeurs, sachez qu’il y a deux raisons. La première, c’est qu’à l’origine l’outil a été développé pour nous aider à capturer des scénarios spécifiques dans la Closure Library, et la deuxième c’est qu’il correspond plus à un outil externe (ou peut-être un jour en tant qu’extension, si nous mettons en place une API de profilage de la pile Heap).

Les options de V8 pour déboguer les optimisations et le ramasse-miette

Chrome supporte le passage d’options directement à V8 via l’option js-flags pour obtenir plus d’informations sur les optimisations effectuées par le moteur. Par exemple, cette commande trace les optimisations de V8 :

/Applications/Google Chrome/Google Chrome" --js-flags="--trace-opt --trace-deopt

Si vous êtes sur Windows, exécutez :

chrome.exe --js-flags="--trace-opt --trace-deopt"

Voici les options de débogage disponibles pour développer avec Chrome :

  1. trace-opt : enregistre dans un fichier le nom des fonctions optimisées et montre à quels endroits V8 ne peut optimiser le code faute de pouvoir le cerner correctement.
  2. trace-deopt : enregistre dans un fichier les portions de code qui ont été déoptimisées pendant l’exécution.
  3. trace-gc : enregistre dans un fichier chaque appel au ramasse-miette.

Dans ces fichiers, V8 indique les fonctions optimisées avec une astérisque (*) et celles qui ne le sont pas avec un tilde (~).

Si vous souhaitez en apprendre plus au sujet des options de V8 et de la façon dont il fonctionne je vous recommande fortement de jeter un œil à l’excellent billet de Vyacheslav Egorov qui résume les meilleurs ressources disponibles actuellement sur le sujet.

Mesures temporelles précises : HRT et Navigation Time API

High Resolution Time (HRT) est une interface JavaScript délivrant une mesure du temps avec une précision de l’ordre du millionième de microseconde, non sujette aux variations de l’horloge système et aux ajustements de cette dernière par l’utilisateur. Voyez cela comme une façon plus précise de faire des tests de performance que la méthode vue précédemment avec new Date() et Date.now(). C’est très pratique quand vous écrivez des tests de performance.

High Resolution Time (HRT) indique le temps avec une précision au millionième de milliseconde près.

HRT est disponible dans Chrome (version stable) via window.performance.webkitNow(), mais la version canary de Chrome propose déjà une version non-préfixée (window.performance.now()) Paul Irish a rédigé une présentation plus complète de window.performance sur HTML5Rocks.

Nous avons une mesure temporelle précise, mais quid de la mesure précise de performance sur le web ?

Eh bien, nous avons maintenant à notre disposition la Navigation Timing API. Cette API propose une façon simple d’obtenir des mesures précises et détaillées, récupérées durant le chargement de la page et sa présentation aux utilisateurs. Les mesures sont exposées via l’objet window.performance.timing que vous pouvez simplement obtenir par le biais de la console Javascript.

Mesure de performances affichées dans la console JavaScript.

On peut aisément extraire diverses informations très pratiques des données ci-dessus. Par exemple, la latence du réseau via responseEnd - fetchStart, le temps nécessaire au chargement de la page à partir de sa réception via loadEventEnd - responseEnd et le temps nécessaire pour passer du clic à l’affichage de la nouvelle page via loadEventEnd - navigationStart.

Comme vous pouvez le voir ci-dessus, une propriété performance.memory est disponible. Elle donne des informations sur l’usage de la mémoire par JavaScript comme par exemple la taille de la pile Heap.

Pour plus d’informations sur la Navigation Timing API, lisez le super billet de Sam Dutton : Measuring Page Load Speed With Navigation Timing.

About:memory et about:tracing

about:tracing dans Google Chrome affiche les performances du navigateur lui-même, et enregistre l’activité de chaque thread, de chaque onglet et de chaque processus.

about:tracing montre les performances du navigateur.

Ce qui est très pratique c’est que cet outile permet de capturer et profiler les mécanismes internes de Chrome de manière à pouvoir ajuster et optimiser votre JavaScript de manière appropriée.

Lili Thompson a écrit un excellent article destiné aux développeurs de jeux vidéos HTML5 sur la façon d’utiliser about:tracing pour le profilage de WebGL. Les autres développeurs y trouveront aussi des informations utiles.

Naviguer à l’intérieur de la page about:memory de Chrome est également d’une grande aide. Il montre l’utilisation exacte de chaque onglet ce qui peut aider à détecter facilement les applications causant des fuites de mémoire.

Conclusion

Comme nous l’avons vu, il y a nombre de subtilités à connaître dans le monde de la performance des moteurs JavaScript, et pas de solution miracle. Ce n’est qu’en confrontant vos optimisations à des tests grandeur nature que vous pourrez estimer les gains en performance les plus importants. De plus, savoir comment les moteurs JavaScript interprètent et optimisent votre code peut vous fournir des pistes pour le développement de vos applications.

Mesurez, comprenez, corrigez ! ...et recommencez.

Crédits image : Sally Hunter

Soyez conscients de l’importance de la performance, mais sans aller jusqu’aux micros optimisations qui pourraient nuire à la simplicité de votre code. Par exemple, certains développeurs préfèrent utiliser .forEach et Object.keys plutôt que les boucles for et for...in, malgré leur lenteur, pour pouvoir garder la main sur le contexte. Sachez distinguer les optimisations qui sont absolument indispensables à votre application de celles dont elle peut se passer.

Aussi, soyez bien conscient que bien que les moteurs Javascript continuent à améliorer leurs performances, la vraie bataille pour les performances se situe au niveau du DOM. Les réagencements et les recalculs graphiques (reflows et repaints) doivent être évités à tout prix, souvenez-vous donc de ne toucher au DOM que quand c’est absolument nécessaire. Et allez-y mollo sur le réseau : les requêtes HTTP sont précieuses, surtout dans un contexte de mobilité, vous devriez exploiter le maximum du potentiel du cache HTTP pour réduire le poids de vos ressources.

Garder tout cela à l’esprit vous assure de tirer le meilleur parti des informations contenues dans ce billet. J’espère que vous l’avez trouvé utile !

L'article original a été relu par Jakob Kummerow, Michael Starzinger; Sindre Sorhus, Mathias Bynens, John-David Dalton et Paul Irish.

]]> https://www.pompage.net/traduction/javascript-rapide-et-efficace https://www.pompage.net/traduction/javascript-rapide-et-efficace Tue, 26 Aug 2014 10:08:00 +0200 <![CDATA[Inline-block est-il un substitut aux floats ?]]>

Par Steven Bradley

Quand vient le moment de développer la mise en page avec CSS, float fait le plus gros du travail. Nous utilisons les éléments flottants pour les blocs importants comme une zone de contenu principale ou une colonne latérale ; nous y avons aussi recours pour les blocs de moindre taille à l’intérieur de ces blocs principaux. Mais les floats sont-ils toujours le meilleur choix?

Si les floats fonctionnent généralement sans problème, il peut parfois être délicat de les manipuler. C’est tout particulièrement compliqué quand il s’agit de blocs imbriqués, comme par exemple lorsqu’on veut organiser une grille d’images, mais qu’elles refusent de bien s’aligner. Une alternative existe : les blocs en lignes. Ils bénéficient de certains avantages des floats sans en présenter les inconvénients.

Les inline-block n’ont rien d’une nouveauté et il est possible que vous les utilisiez déjà. Ce n’était pas mon cas jusqu’à récemment. Il se trouve que les derniers sites que j’ai réalisés étaient destinés à des photographes. Naturellement, ce genre de site présente des grilles d’image. Pour les mettre en forme, j’ai privilégié inline-block à float.

Qu’est ce qu’un inline-block ?

Inline-block est l’une des valeurs possibles pouvant être assignées à la propriété display d’un élément. Cette valeur tient son nom du fait qu’elle regroupe certaines caractéristiques des éléments de type bloc et en ligne.

  • Les éléments de type bloc génèrent des boîtes selon le modèle de boîtes CSS. Ils peuvent avoir une largeur (width), une hauteur (height), des bordures et des marges intérieures et extérieures (padding et margin). Ils s’organisent verticalement les uns au-dessus des autres.
  • Les éléments en-ligne ne forment pas de boîtes. Ils se suivent horizontalement. (NdT : Ils génèrent en fait des boîtes de ligne : voir indications du W3C.)
  • Les éléments de type blocs-en-ligne, de l’intérieur, se comportent comme des éléments de type bloc : ils forment des boîtes. Vus de l’extérieur, ils se comportent tels des éléments en-ligne, se suivent horizontalement au lieu de s’empiler.

Lorsqu’on y pense, ce comportement n’est pas si éloigné de celui des éléments flottants. Les flottants forment des boîtes et se tiennent eux aussi côte à côte au lieu de s’organiser verticalement. L’un et l’autre ne sont bien sûr pas identiques, mais leur positionnement en ligne à l’extérieur et leur comportement en bloc à l’intérieur sont parfois les seules caractéristiques recherchées. Dans ce cas, un float ou un inline-block pourra être utilisé indifféremment.

La différence entre float et inline-block

Même si float et inline-block partagent quelques similitudes, il existe des différences bien précises entre les deux.

  • Flux du document – Les flottants sont retirés du flux normal, permettant ainsi aux éléments qui les suivent de flotter autour d’eux ; les blocs en ligne restent dans le flux du document. Ainsi, il n’est pas nécessaire d’avoir recours à des techniques telles que clearfix ou overflow:hidden. Ainsi, les éléments suivant un « inline-block » ne peuvent pas habiller ce dernier, et on ne peut pas forcer un élément à passer sous un « inline-block » avec la propriété clear.
  • Positionnement horizontal – Un exemple concret serait des floats qui ne peuvent être centrés avec un text-align: center placé sur leur parent. De plus, aucun style de positionnement appliqué au parent d’un flottant n’aura d’influence sur ce dernier. À l’inverse, le parent d’un inline-block peut affecter sa position.
  • Alignement vertical – Les inline-blocks s’alignent par défaut sur la ligne de base du texte. Les floats s’alignent en haut de leur parent. Il est possible de changer ce comportement par défaut pour les inline-blocks et ainsi contrôler où ils seront alignés verticalement, ce qui n’est pas le cas pour les floats. C’est principalement pour cette raison que j’ai eu davantage recours aux inline-blocks.
  • Espaces blancs – Les inline-blocks obéissent aux espaces présents dans le HTML (NdT : que ce soit une espace simple, une tabulation ou un retour chariot). Si plusieurs éléments inline-block sont chacun déclarés sur une nouvelle ligne dans le code HTML, ils s’afficheront de chaque côté d’un espace horizontal. Les éléments flottants se tiendront eux les uns à côté des autres indépendamment des espaces présents dans le balisage.
  • IE6 et IE7 – Les blocs en ligne ne sont pas supportés ou n’ont qu’un support partiel dans Internet Explorer 6 et 7. Si vous avez besoin de prendre en charge ces versions du navigateur, vous aurez besoin d’une alternative.


Tous les blocs ci-dessus ont une déclaration display: inline-block. À gauche, une espace est présente entre eux dans le code. À droite, l’espace a été retirée du HTML. Aucune autre différence.

Régler le problème de l’espace blanc

Cela est possible. Il est probable que vous voudrez utiliser plusieurs inline-block sans pour autant souhaiter l’espace entre eux. Il existe quelques méthodes pour le supprimer.

  • Supprimez tout espace dans le balisage (NDT  : tabulations et retours à la ligne compris) – Affranchissez-vous des retours chariot entre les éléments de type inline-block. Il ne s’agit pas de la solution la plus élégante, mais elle est efficace, surtout si vous n’avez que quelques éléments.
  • Utilisez des marges négatives – Il vous faudra prendre en compte la taille de la fonte car les espaces sont calculées en fonction de cette valeur. J’aime à penser qu’il s’agit de 0,25em, mais n’étant pas sûr, laissez un commentaire si vous en savez plus sur le sujet.
  • Appliquer une taille de police de 0 au parent – Qu’importe la taille de l’espace, une taille de texte nulle implique que l’espace sera lui aussi nul. Il sera alors évidemment nécessaire d’attribuer une nouvelle taille pour tous les enfants qui en auraient besoin.

Quand utiliser les inline-blocks et quand utiliser les floats ?

Quand utiliser l’un ou l’autre dépend des spécificités de votre design, et de ce que vous tentez de réaliser. Si vous voulez que le texte s’écoule autour d’un élément, alors float est la réponse la plus évidente. Si vous voulez centrer un élément, inline-block est la meilleure option.
En définitive, votre choix découlera des différences entre inline-block et float, et des particularités de chacun qui vous sont nécessaires.

  • Utilisez inline-block… lorsque vous avez besoin d’un plus grand contrôle sur l’alignement vertical et le positionnement horizontal des éléments.
  • Utilisez float… lorsque vous attendez des autres éléments qu’ils s’agencent autour d’un élément spécifique, lorsque vous désirez un support pour les versions plus anciennes d’Internet Explorer ou souhaitez éviter la problématique de l’espace entre éléments.


Les blocs ci-dessus flottent à gauche pour composer une grille. Le cinquième bloc [five] se retrouve coincé par le second [two] car ce dernier est le plus haut de sa rangée. C’est un problème récurrent lors de la création de grilles d’images.

Les floats, les inline-blocks et les grilles d’images

Dans mon cas, l’utilisation des inline-blocks m’est utile face au souci de l’alignement vertical. Je crois que cela doit être la même chose pour beaucoup de personnes qui commencent à les utiliser. J’ai dernièrement construit plusieurs sites pour des photographes et, bien entendu, ces sites sont inévitablement chargés de grilles d’images.

Les flottants sont plus efficaces si les images de la grille ont toutes la même hauteur. Dès que ce n’est plus le cas, c’est-à-dire la plupart du temps, les floats se retrouvent comme suspendus à côté de l’image la plus haute de la rangée supérieure. Ceci est dû au fait que les floats sont exclus du flux normal du document.

Les blocs en ligne n’ont pas ce problème puisqu’ils restent dans le flux. Quand une nouvelle rangée d’images doit être créée, la nouvelle rangée se positionne naturellement sous la précédente, de manière rectiligne. Pour avoir ce même comportement avec des éléments flottants, nous aurions besoin de savoir précisément sur quel flottant positionner la propriété clear (NDT : pour forcer un vrai retour à la ligne). Ceci peut poser problème dans le cas où les éléments sont générés dynamiquement. Dans ce cas précis, utiliser des blocs en ligne est bien plus naturel.
Voici une démonstration qui illustre le problème abordé plus haut et les différents résultats obtenus suivant la technique utilisée.


display: inline-block est appliqué aux blocs du dessus. Étant donné qu’ils ne sont pas exclus du flux du document, aucun des blocs ne se retrouve prisonnier des blocs de la ligne supérieure.

Les inline-blocks pour la navigation

Une autre application possible pour inline-block se trouve dans les barres horizontales de navigation. On y fait généralement flotter les liens pour ensuite les déclarer comme des éléments de type bloc. Je me vois également déclarer des items de liste comme inline. S’il vous faut jongler avec des valeurs inline et block pour utiliser float, inline-block représente alors peut‑être une meilleure solution.

Partout où vous avez besoin de ranger vos éléments en une ou plusieurs lignes, vous devriez songer à utiliser inline-block plutôt que float. Évidemment, des tableaux feraient eux aussi l’affaire dans ces circonstances. Après tout, ils sont faits pour aligner du contenu en lignes et colonnes.

Si vous construisez quelque chose de plus complexe nécessitant lignes et colonnes, alors un tableau HTML ou CSS peut être votre meilleure option, même si les inline-blocks restent à privilégier pour les constructions plus simples.

Conclusion

Les inline-blocks puisent parmi les caractéristiques des éléments en ligne vus de l’extérieur ; et des éléments de type block vus de l’intérieur. Cela les rend très similaires aux flottants à quelques différences près.

Ces différences vous aideront à choisir l’utilisation la mieux adaptée. Si vous rencontrez des problèmes avec l’alignement vertical ou le positionnement horizontal, vous serez plus enclin à utiliser un inline-block. Si vous avez besoin de plus de contrôle sur un seul élément et son interaction avec le contenu qui l’entoure, vous serez plus enclin à utiliser un float.
Bien entendu, un tableau peut s’avérer comme étant la meilleure option en fonction de ce que vous tentez d’accomplir.

Tout ceci n’est rien de nouveau, mais j’ai pensé qu’un article et une démonstration seraient utiles à quiconque n’aurait pas utilisé les blocs en ligne là où il aurait dû.

Voici la liste des dix articles les plus récents en rapport avec cet article :

]]> http://www.pompage.net/traduction/inline-block-vs-float http://www.pompage.net/traduction/inline-block-vs-float Tue, 05 Aug 2014 10:08:00 +0200 <![CDATA[Inline-block est-il un substitut aux floats ?]]>

Par Steven Bradley

Quand vient le moment de développer la mise en page avec CSS, float fait le plus gros du travail. Nous utilisons les éléments flottants pour les blocs importants comme une zone de contenu principale ou une colonne latérale ; nous y avons aussi recours pour les blocs de moindre taille à l’intérieur de ces blocs principaux. Mais les floats sont-ils toujours le meilleur choix?

Si les floats fonctionnent généralement sans problème, il peut parfois être délicat de les manipuler. C’est tout particulièrement compliqué quand il s’agit de blocs imbriqués, comme par exemple lorsqu’on veut organiser une grille d’images, mais qu’elles refusent de bien s’aligner. Une alternative existe : les blocs en lignes. Ils bénéficient de certains avantages des floats sans en présenter les inconvénients.

Les inline-block n’ont rien d’une nouveauté et il est possible que vous les utilisiez déjà. Ce n’était pas mon cas jusqu’à récemment. Il se trouve que les derniers sites que j’ai réalisés étaient destinés à des photographes. Naturellement, ce genre de site présente des grilles d’image. Pour les mettre en forme, j’ai privilégié inline-block à float.

Qu’est ce qu’un inline-block ?

Inline-block est l’une des valeurs possibles pouvant être assignées à la propriété display d’un élément. Cette valeur tient son nom du fait qu’elle regroupe certaines caractéristiques des éléments de type bloc et en ligne.

  • Les éléments de type bloc génèrent des boîtes selon le modèle de boîtes CSS. Ils peuvent avoir une largeur (width), une hauteur (height), des bordures et des marges intérieures et extérieures (padding et margin). Ils s’organisent verticalement les uns au-dessus des autres.
  • Les éléments en-ligne ne forment pas de boîtes. Ils se suivent horizontalement. (NdT : Ils génèrent en fait des boîtes de ligne : voir indications du W3C.)
  • Les éléments de type blocs-en-ligne, de l’intérieur, se comportent comme des éléments de type bloc : ils forment des boîtes. Vus de l’extérieur, ils se comportent tels des éléments en-ligne, se suivent horizontalement au lieu de s’empiler.

Lorsqu’on y pense, ce comportement n’est pas si éloigné de celui des éléments flottants. Les flottants forment des boîtes et se tiennent eux aussi côte à côte au lieu de s’organiser verticalement. L’un et l’autre ne sont bien sûr pas identiques, mais leur positionnement en ligne à l’extérieur et leur comportement en bloc à l’intérieur sont parfois les seules caractéristiques recherchées. Dans ce cas, un float ou un inline-block pourra être utilisé indifféremment.

La différence entre float et inline-block

Même si float et inline-block partagent quelques similitudes, il existe des différences bien précises entre les deux.

  • Flux du document – Les flottants sont retirés du flux normal, permettant ainsi aux éléments qui les suivent de flotter autour d’eux ; les blocs en ligne restent dans le flux du document. Ainsi, il n’est pas nécessaire d’avoir recours à des techniques telles que clearfix ou overflow:hidden. Ainsi, les éléments suivant un « inline-block » ne peuvent pas habiller ce dernier, et on ne peut pas forcer un élément à passer sous un « inline-block » avec la propriété clear.
  • Positionnement horizontal – Un exemple concret serait des floats qui ne peuvent être centrés avec un text-align: center placé sur leur parent. De plus, aucun style de positionnement appliqué au parent d’un flottant n’aura d’influence sur ce dernier. À l’inverse, le parent d’un inline-block peut affecter sa position.
  • Alignement vertical – Les inline-blocks s’alignent par défaut sur la ligne de base du texte. Les floats s’alignent en haut de leur parent. Il est possible de changer ce comportement par défaut pour les inline-blocks et ainsi contrôler où ils seront alignés verticalement, ce qui n’est pas le cas pour les floats. C’est principalement pour cette raison que j’ai eu davantage recours aux inline-blocks.
  • Espaces blancs – Les inline-blocks obéissent aux espaces présents dans le HTML (NdT : que ce soit une espace simple, une tabulation ou un retour chariot). Si plusieurs éléments inline-block sont chacun déclarés sur une nouvelle ligne dans le code HTML, ils s’afficheront de chaque côté d’un espace horizontal. Les éléments flottants se tiendront eux les uns à côté des autres indépendamment des espaces présents dans le balisage.
  • IE6 et IE7 – Les blocs en ligne ne sont pas supportés ou n’ont qu’un support partiel dans Internet Explorer 6 et 7. Si vous avez besoin de prendre en charge ces versions du navigateur, vous aurez besoin d’une alternative.


Tous les blocs ci-dessus ont une déclaration display: inline-block. À gauche, une espace est présente entre eux dans le code. À droite, l’espace a été retirée du HTML. Aucune autre différence.

Régler le problème de l’espace blanc

Cela est possible. Il est probable que vous voudrez utiliser plusieurs inline-block sans pour autant souhaiter l’espace entre eux. Il existe quelques méthodes pour le supprimer.

  • Supprimez tout espace dans le balisage (NDT  : tabulations et retours à la ligne compris) – Affranchissez-vous des retours chariot entre les éléments de type inline-block. Il ne s’agit pas de la solution la plus élégante, mais elle est efficace, surtout si vous n’avez que quelques éléments.
  • Utilisez des marges négatives – Il vous faudra prendre en compte la taille de la fonte car les espaces sont calculées en fonction de cette valeur. J’aime à penser qu’il s’agit de 0,25em, mais n’étant pas sûr, laissez un commentaire si vous en savez plus sur le sujet.
  • Appliquer une taille de police de 0 au parent – Qu’importe la taille de l’espace, une taille de texte nulle implique que l’espace sera lui aussi nul. Il sera alors évidemment nécessaire d’attribuer une nouvelle taille pour tous les enfants qui en auraient besoin.

Quand utiliser les inline-blocks et quand utiliser les floats ?

Quand utiliser l’un ou l’autre dépend des spécificités de votre design, et de ce que vous tentez de réaliser. Si vous voulez que le texte s’écoule autour d’un élément, alors float est la réponse la plus évidente. Si vous voulez centrer un élément, inline-block est la meilleure option.
En définitive, votre choix découlera des différences entre inline-block et float, et des particularités de chacun qui vous sont nécessaires.

  • Utilisez inline-block… lorsque vous avez besoin d’un plus grand contrôle sur l’alignement vertical et le positionnement horizontal des éléments.
  • Utilisez float… lorsque vous attendez des autres éléments qu’ils s’agencent autour d’un élément spécifique, lorsque vous désirez un support pour les versions plus anciennes d’Internet Explorer ou souhaitez éviter la problématique de l’espace entre éléments.


Les blocs ci-dessus flottent à gauche pour composer une grille. Le cinquième bloc [five] se retrouve coincé par le second [two] car ce dernier est le plus haut de sa rangée. C’est un problème récurrent lors de la création de grilles d’images.

Les floats, les inline-blocks et les grilles d’images

Dans mon cas, l’utilisation des inline-blocks m’est utile face au souci de l’alignement vertical. Je crois que cela doit être la même chose pour beaucoup de personnes qui commencent à les utiliser. J’ai dernièrement construit plusieurs sites pour des photographes et, bien entendu, ces sites sont inévitablement chargés de grilles d’images.

Les flottants sont plus efficaces si les images de la grille ont toutes la même hauteur. Dès que ce n’est plus le cas, c’est-à-dire la plupart du temps, les floats se retrouvent comme suspendus à côté de l’image la plus haute de la rangée supérieure. Ceci est dû au fait que les floats sont exclus du flux normal du document.

Les blocs en ligne n’ont pas ce problème puisqu’ils restent dans le flux. Quand une nouvelle rangée d’images doit être créée, la nouvelle rangée se positionne naturellement sous la précédente, de manière rectiligne. Pour avoir ce même comportement avec des éléments flottants, nous aurions besoin de savoir précisément sur quel flottant positionner la propriété clear (NDT : pour forcer un vrai retour à la ligne). Ceci peut poser problème dans le cas où les éléments sont générés dynamiquement. Dans ce cas précis, utiliser des blocs en ligne est bien plus naturel.
Voici une démonstration qui illustre le problème abordé plus haut et les différents résultats obtenus suivant la technique utilisée.


display: inline-block est appliqué aux blocs du dessus. Étant donné qu’ils ne sont pas exclus du flux du document, aucun des blocs ne se retrouve prisonnier des blocs de la ligne supérieure.

Les inline-blocks pour la navigation

Une autre application possible pour inline-block se trouve dans les barres horizontales de navigation. On y fait généralement flotter les liens pour ensuite les déclarer comme des éléments de type bloc. Je me vois également déclarer des items de liste comme inline. S’il vous faut jongler avec des valeurs inline et block pour utiliser float, inline-block représente alors peut‑être une meilleure solution.

Partout où vous avez besoin de ranger vos éléments en une ou plusieurs lignes, vous devriez songer à utiliser inline-block plutôt que float. Évidemment, des tableaux feraient eux aussi l’affaire dans ces circonstances. Après tout, ils sont faits pour aligner du contenu en lignes et colonnes.

Si vous construisez quelque chose de plus complexe nécessitant lignes et colonnes, alors un tableau HTML ou CSS peut être votre meilleure option, même si les inline-blocks restent à privilégier pour les constructions plus simples.

Conclusion

Les inline-blocks puisent parmi les caractéristiques des éléments en ligne vus de l’extérieur ; et des éléments de type block vus de l’intérieur. Cela les rend très similaires aux flottants à quelques différences près.

Ces différences vous aideront à choisir l’utilisation la mieux adaptée. Si vous rencontrez des problèmes avec l’alignement vertical ou le positionnement horizontal, vous serez plus enclin à utiliser un inline-block. Si vous avez besoin de plus de contrôle sur un seul élément et son interaction avec le contenu qui l’entoure, vous serez plus enclin à utiliser un float.
Bien entendu, un tableau peut s’avérer comme étant la meilleure option en fonction de ce que vous tentez d’accomplir.

Tout ceci n’est rien de nouveau, mais j’ai pensé qu’un article et une démonstration seraient utiles à quiconque n’aurait pas utilisé les blocs en ligne là où il aurait dû.

Voici la liste des dix articles les plus récents en rapport avec cet article :

]]> http://www.pompage.net/traduction/inline-block-vs-float http://www.pompage.net/traduction/inline-block-vs-float Tue, 05 Aug 2014 10:08:00 +0200 <![CDATA[Inline-block est-il un substitut aux floats ?]]>

Par Steven Bradley

Quand vient le moment de développer la mise en page avec CSS, float fait le plus gros du travail. Nous utilisons les éléments flottants pour les blocs importants comme une zone de contenu principale ou une colonne latérale ; nous y avons aussi recours pour les blocs de moindre taille à l’intérieur de ces blocs principaux. Mais les floats sont-ils toujours le meilleur choix?

Si les floats fonctionnent généralement sans problème, il peut parfois être délicat de les manipuler. C’est tout particulièrement compliqué quand il s’agit de blocs imbriqués, comme par exemple lorsqu’on veut organiser une grille d’images, mais qu’elles refusent de bien s’aligner. Une alternative existe : les blocs en lignes. Ils bénéficient de certains avantages des floats sans en présenter les inconvénients.

Les inline-block n’ont rien d’une nouveauté et il est possible que vous les utilisiez déjà. Ce n’était pas mon cas jusqu’à récemment. Il se trouve que les derniers sites que j’ai réalisés étaient destinés à des photographes. Naturellement, ce genre de site présente des grilles d’image. Pour les mettre en forme, j’ai privilégié inline-block à float.

Qu’est ce qu’un inline-block ?

Inline-block est l’une des valeurs possibles pouvant être assignées à la propriété display d’un élément. Cette valeur tient son nom du fait qu’elle regroupe certaines caractéristiques des éléments de type bloc et en ligne.

  • Les éléments de type bloc génèrent des boîtes selon le modèle de boîtes CSS. Ils peuvent avoir une largeur (width), une hauteur (height), des bordures et des marges intérieures et extérieures (padding et margin). Ils s’organisent verticalement les uns au-dessus des autres.
  • Les éléments en-ligne ne forment pas de boîtes. Ils se suivent horizontalement. (NdT : Ils génèrent en fait des boîtes de ligne : voir indications du W3C.)
  • Les éléments de type blocs-en-ligne, de l’intérieur, se comportent comme des éléments de type bloc : ils forment des boîtes. Vus de l’extérieur, ils se comportent tels des éléments en-ligne, se suivent horizontalement au lieu de s’empiler.

Lorsqu’on y pense, ce comportement n’est pas si éloigné de celui des éléments flottants. Les flottants forment des boîtes et se tiennent eux aussi côte à côte au lieu de s’organiser verticalement. L’un et l’autre ne sont bien sûr pas identiques, mais leur positionnement en ligne à l’extérieur et leur comportement en bloc à l’intérieur sont parfois les seules caractéristiques recherchées. Dans ce cas, un float ou un inline-block pourra être utilisé indifféremment.

La différence entre float et inline-block

Même si float et inline-block partagent quelques similitudes, il existe des différences bien précises entre les deux.

  • Flux du document – Les flottants sont retirés du flux normal, permettant ainsi aux éléments qui les suivent de flotter autour d’eux ; les blocs en ligne restent dans le flux du document. Ainsi, il n’est pas nécessaire d’avoir recours à des techniques telles que clearfix ou overflow:hidden. Ainsi, les éléments suivant un « inline-block » ne peuvent pas habiller ce dernier, et on ne peut pas forcer un élément à passer sous un « inline-block » avec la propriété clear.
  • Positionnement horizontal – Un exemple concret serait des floats qui ne peuvent être centrés avec un text-align: center placé sur leur parent. De plus, aucun style de positionnement appliqué au parent d’un flottant n’aura d’influence sur ce dernier. À l’inverse, le parent d’un inline-block peut affecter sa position.
  • Alignement vertical – Les inline-blocks s’alignent par défaut sur la ligne de base du texte. Les floats s’alignent en haut de leur parent. Il est possible de changer ce comportement par défaut pour les inline-blocks et ainsi contrôler où ils seront alignés verticalement, ce qui n’est pas le cas pour les floats. C’est principalement pour cette raison que j’ai eu davantage recours aux inline-blocks.
  • Espaces blancs – Les inline-blocks obéissent aux espaces présents dans le HTML (NdT : que ce soit une espace simple, une tabulation ou un retour chariot). Si plusieurs éléments inline-block sont chacun déclarés sur une nouvelle ligne dans le code HTML, ils s’afficheront de chaque côté d’un espace horizontal. Les éléments flottants se tiendront eux les uns à côté des autres indépendamment des espaces présents dans le balisage.
  • IE6 et IE7 – Les blocs en ligne ne sont pas supportés ou n’ont qu’un support partiel dans Internet Explorer 6 et 7. Si vous avez besoin de prendre en charge ces versions du navigateur, vous aurez besoin d’une alternative.


Tous les blocs ci-dessus ont une déclaration display: inline-block. À gauche, une espace est présente entre eux dans le code. À droite, l’espace a été retirée du HTML. Aucune autre différence.

Régler le problème de l’espace blanc

Cela est possible. Il est probable que vous voudrez utiliser plusieurs inline-block sans pour autant souhaiter l’espace entre eux. Il existe quelques méthodes pour le supprimer.

  • Supprimez tout espace dans le balisage (NDT  : tabulations et retours à la ligne compris) – Affranchissez-vous des retours chariot entre les éléments de type inline-block. Il ne s’agit pas de la solution la plus élégante, mais elle est efficace, surtout si vous n’avez que quelques éléments.
  • Utilisez des marges négatives – Il vous faudra prendre en compte la taille de la fonte car les espaces sont calculées en fonction de cette valeur. J’aime à penser qu’il s’agit de 0,25em, mais n’étant pas sûr, laissez un commentaire si vous en savez plus sur le sujet.
  • Appliquer une taille de police de 0 au parent – Qu’importe la taille de l’espace, une taille de texte nulle implique que l’espace sera lui aussi nul. Il sera alors évidemment nécessaire d’attribuer une nouvelle taille pour tous les enfants qui en auraient besoin.

Quand utiliser les inline-blocks et quand utiliser les floats ?

Quand utiliser l’un ou l’autre dépend des spécificités de votre design, et de ce que vous tentez de réaliser. Si vous voulez que le texte s’écoule autour d’un élément, alors float est la réponse la plus évidente. Si vous voulez centrer un élément, inline-block est la meilleure option.
En définitive, votre choix découlera des différences entre inline-block et float, et des particularités de chacun qui vous sont nécessaires.

  • Utilisez inline-block… lorsque vous avez besoin d’un plus grand contrôle sur l’alignement vertical et le positionnement horizontal des éléments.
  • Utilisez float… lorsque vous attendez des autres éléments qu’ils s’agencent autour d’un élément spécifique, lorsque vous désirez un support pour les versions plus anciennes d’Internet Explorer ou souhaitez éviter la problématique de l’espace entre éléments.


Les blocs ci-dessus flottent à gauche pour composer une grille. Le cinquième bloc [five] se retrouve coincé par le second [two] car ce dernier est le plus haut de sa rangée. C’est un problème récurrent lors de la création de grilles d’images.

Les floats, les inline-blocks et les grilles d’images

Dans mon cas, l’utilisation des inline-blocks m’est utile face au souci de l’alignement vertical. Je crois que cela doit être la même chose pour beaucoup de personnes qui commencent à les utiliser. J’ai dernièrement construit plusieurs sites pour des photographes et, bien entendu, ces sites sont inévitablement chargés de grilles d’images.

Les flottants sont plus efficaces si les images de la grille ont toutes la même hauteur. Dès que ce n’est plus le cas, c’est-à-dire la plupart du temps, les floats se retrouvent comme suspendus à côté de l’image la plus haute de la rangée supérieure. Ceci est dû au fait que les floats sont exclus du flux normal du document.

Les blocs en ligne n’ont pas ce problème puisqu’ils restent dans le flux. Quand une nouvelle rangée d’images doit être créée, la nouvelle rangée se positionne naturellement sous la précédente, de manière rectiligne. Pour avoir ce même comportement avec des éléments flottants, nous aurions besoin de savoir précisément sur quel flottant positionner la propriété clear (NDT : pour forcer un vrai retour à la ligne). Ceci peut poser problème dans le cas où les éléments sont générés dynamiquement. Dans ce cas précis, utiliser des blocs en ligne est bien plus naturel.
Voici une démonstration qui illustre le problème abordé plus haut et les différents résultats obtenus suivant la technique utilisée.


display: inline-block est appliqué aux blocs du dessus. Étant donné qu’ils ne sont pas exclus du flux du document, aucun des blocs ne se retrouve prisonnier des blocs de la ligne supérieure.

Les inline-blocks pour la navigation

Une autre application possible pour inline-block se trouve dans les barres horizontales de navigation. On y fait généralement flotter les liens pour ensuite les déclarer comme des éléments de type bloc. Je me vois également déclarer des items de liste comme inline. S’il vous faut jongler avec des valeurs inline et block pour utiliser float, inline-block représente alors peut‑être une meilleure solution.

Partout où vous avez besoin de ranger vos éléments en une ou plusieurs lignes, vous devriez songer à utiliser inline-block plutôt que float. Évidemment, des tableaux feraient eux aussi l’affaire dans ces circonstances. Après tout, ils sont faits pour aligner du contenu en lignes et colonnes.

Si vous construisez quelque chose de plus complexe nécessitant lignes et colonnes, alors un tableau HTML ou CSS peut être votre meilleure option, même si les inline-blocks restent à privilégier pour les constructions plus simples.

Conclusion

Les inline-blocks puisent parmi les caractéristiques des éléments en ligne vus de l’extérieur ; et des éléments de type block vus de l’intérieur. Cela les rend très similaires aux flottants à quelques différences près.

Ces différences vous aideront à choisir l’utilisation la mieux adaptée. Si vous rencontrez des problèmes avec l’alignement vertical ou le positionnement horizontal, vous serez plus enclin à utiliser un inline-block. Si vous avez besoin de plus de contrôle sur un seul élément et son interaction avec le contenu qui l’entoure, vous serez plus enclin à utiliser un float.
Bien entendu, un tableau peut s’avérer comme étant la meilleure option en fonction de ce que vous tentez d’accomplir.

Tout ceci n’est rien de nouveau, mais j’ai pensé qu’un article et une démonstration seraient utiles à quiconque n’aurait pas utilisé les blocs en ligne là où il aurait dû.

Voici la liste des dix articles les plus récents en rapport avec cet article :

]]> https://www.pompage.net/traduction/inline-block-vs-float https://www.pompage.net/traduction/inline-block-vs-float Tue, 05 Aug 2014 10:08:00 +0200 <![CDATA[Introduction à l'accessibilité de JavaScript]]> Par James Edwards

Il fut un temps où l’accessibilité de JavaScript signifiait simplement assurer une dégradation élégante lorsque JavaScript n’était pas disponible. Mais, avec la percée d’Ajax et des Applications Internet Riches (RIA), JavaScript n’est plus seulement utilisé pour améliorer l’utilisabilité à la marge, il constitue désormais la base des applications web. De nos jours, parler de l’accessibilité de JavaScript c’est s’assurer que le code JavaScript est accessible en lui-même.

Ce que nous réserve l’avenir

Le protocole d’accessibilité des applications Internet riches (NdT : ARIA en anglais, pour Accessible Rich Internet Applications) est une des évolutions les plus importantes de ces dernières années dans l’accessibilité web. Il a été conçu par le groupe Initiative pour l’Accessibilité du Web (WAI) et définit une sémantique permettant de rendre le contenu interactif accessible aux technologies d’assistance telles que les lecteurs d’écran. WAI-ARIA est apparu par nécessité, l’explosion du Web 2.0 s’étant faite presque sans aucune considération d’accessibilité. JavaScript est désormais utilisé dans le code d’applications web critiques et les technologies d’assistance doivent donc impérativement pouvoir interpréter le contenu dynamique.

Aujourd’hui

Malheureusement, ARIA n’est pas encore très bien pris en charge. Seules les dernières versions des (très coûteux) lecteurs d’écran offrent un début de prise en charge, et aucun d’entre eux ne l’offre intégralement. De plus, ce qui est supporté n’est pas forcément bien implémenté. Et même quand ARIA sera largement pris en charge, ce ne sera pas pour autant la réponse à tout car l’accessibilité de JavaScript ne se résume pas à ce qui est défini par ARIA. Pour que les fondations de ce protocole soient solides, elles doivent associer une véritable compréhension du besoin utilisateur et des développements basés sur les standards.

Sitepoint va consacrer plusieurs articles à l’accessibilité de JavaScript. Nous commençons par un aperçu des choses simples que vous pouvez faire dès à présent pour rendre votre JavaScript plus accessible. Plus tard, nous entrerons plus en détails dans le monde d’ARIA. Mais avant toute chose, nous devons revoir quelques concepts théoriques

Le cœur de l’accessibilité

L’accessibilité de JavaScript peut être divisée en trois grands groupes de besoins utilisateurs. Ce chapitre décrit ces groupes de manière détaillée.

Les utilisateurs de technologies d’assistance

Le premier groupe comprend les personnes qui utilisent des lecteurs d’écran, plages Braille ou d’autres aides techniques de ce genre. Les aveugles sont majoritaires dans ce groupe, mais il inclut également les personnes souffrant de handicaps visuels ou cognitifs, pour qui les lecteurs d’écran facilitent la lecture et la compréhension.

Les technologies d’assistance présentent toutes les informations sous forme de texte structuré. Par conséquent, toutes les fonctionnalités JavaScript doivent adopter une forme qui puisse être présentée textuellement. Une barre de progression scriptée telle qu’illustrée ci-dessous fournit des informations visuelles, elle devrait donc être complétée par un texte fournissant les mêmes informations.

Une barre de progressions dont la position, 76%, est indiquée visuellement et à l’aide d’un nombre en pourcentage. Sitepoint, http://dab1nmslvvntp.cloudfront.net/wp-content/uploads/2012/11/javascript-accessibility-progress.png

Le texte en lui-même ne suffit pas, s’il ne possède pas de structure ou de liaisons interprétables par les technologies d’assistance. Un texte est souvent structuré de façon très simple, sous forme de listes et de tableaux. Les technologies d’assistance comprennent aisément ce type de structure, il ne nous reste donc qu’à les utiliser correctement.

En utilisant par exemple des listes non ordonnées et des libellés de structure comme base d’un menu déroulant, les technologies d’assistance peuvent interpréter le sens à partir de la sémantique et de la hiérarchie de ces éléments. Nous pouvons également construire des widgets de calendrier où chaque mois est représenté par un tableau HTML. Il suffit alors de déclencher son affichage par un bouton et de le décrire à l’aide d’une légende. Une sémantique solide des éléments doit constituer la base de tout contenu interactif.

Les utilisateurs qui naviguent au clavier

Le deuxième groupe est formé par les personnes qui utilisent uniquement le clavier. Ce groupe comprend les non-voyants utilisant un lecteur d’écran, mais également les personnes voyantes qui ne peuvent pas utiliser la souris en raison d’un handicap moteur, ainsi que les personnes ayant une déficience cognitive et pour suivre les éléments qui possèdent le focus aide à se concentrer. Pour s’adapter aux besoins de ce groupe, toutes les fonctionnalités JavaScript doit être accessibles au clavier. Les interactions par exemple doivent être limitées aux touches les plus intuitives : tabulation, les flèches, la touche Entrée et la touche d’échappement.

La prise en charge du clavier se fait souvent à moindre coût, pour peu que vous partiez du principe que le meilleur événement est toujours celui qui est le plus indépendant du périphérique. Ainsi, la validation du formulaire doit être liée à l’événement submit du formulaire, tandis que les événements d’activation primaires devraient être liés à l’événement clic universel, plutôt que des événements spécifiques comme mousedown, touchstart ou KeyDown.

Pour les interactions plus complexes, il est souvent nécessaire de combiner les événements. Les Règles d’Accessibilité pour les Contenus Web (NdT : Web Content Accessibility Guidelines, ou WCAG en anglais) parlent d’association d’événements : il s’agit de coupler les événements souris avec leur équivalent clavier le plus similaire. Un exemple est le couplage des événements mousedown et keydown. Ce n’est toutefois pas la bonne façon de voir les choses car on se concentre ici sur la technique plutôt que sur la finalité d’une action. Tant que l’objectif est atteint, peu importe que les modalités au clavier soient totalement différentes de l’action à la souris.

Pour le glisser-déposer par exemple, il n’y a pas d’équivalent à l’événement mousemove, mais nous pouvons quand même rendre cette fonctionnalité accessible au clavier. Il s’agit en fait de deux interactions distinctes. La première permet de déplacer des éléments vers le haut ou le bas pour les réorganiser, ce qui peut tout simplement se faire grâce aux flèches haut et bas. La seconde interaction concerne l’action d’attraper et de déplacer, pour déplacer des fichiers d’un dossier à un autre par exemple. Cela peut se faire par exemple avec la touche Espace pour sélectionner l’élément, la touche Tabulation pour sélectionner la destination, et la touche Entrée pour déposer.

Lorsque des touches non-standard sont utilisées, un texte d’accompagnement devrait figurer pour l’expliquer. Dans les faits, certaines interactions seront immanquablement plus compliquées que leur équivalent à la souris. Mais ce n’est pas bien grave, du moment que le résultat est atteignable. L’accessibilité c’est l’équivalence, pas l’égalité.

Une autre considération importante concernant l’accessibilité au clavier est de garder un ordre logique du contenu. Des bulles d’aide enrichies, par exemple, doivent être insérées immédiatement après l’élément qu’elles concernent pour qu’on y accède directement en tabulant une seule fois, et afin que les lecteurs d’écran puissent les lire dans la foulée.

Les utilisateurs sensibles au clignotement ou aux limites de temps

Le dernier groupe comprend les personnes sensibles aux clignotements ou aux brusques changements de luminosité, ou qui ne peuvent pas réagir aux événements en temps réel comme les autres. Le contenu clignotant affecte les personnes souffrant d’une épilepsie photosensible, chez qui cela peut provoquer une crise, ainsi que les personnes souffrant de déficience cognitive, qui ont du mal à se concentrer lorsque les choses bougent dans leur vision périphérique. Les limitations sur les contenus qui clignotent sont assez bien formulées par les règles d’accessibilité pour les contenus web et synthétisées par le seuil de trois clignotements maximum.

Les limites temporelles peuvent également s’avérer problématiques car écouter un contenu vocalisé prend plus de temps que de le lire. Naviguer au clavier prend également plus de temps qu’à la souris. De ce fait, les actions JavaScript basées sur le temps doivent être contrôlables par l’utilisateur. Les limites sur des activités temporelles ne sont pas trop spécifiques, car il y a différents cas de figure à prendre en considération.

Le grand principe pour les limites temporelles est que si une activité doit être effectuée dans un certain laps de temps, l’utilisateur est prévenu quand la limite est sur le point d’expirer et se voit proposer une façon de la rallonger. Par exemple, un site de banque en ligne peut avoir des limites de temps strictes sur l’inactivité de session, mais l’utilisateur doit pouvoir l’allonger à l’aide d’un simple dialogue de confirmation (comme ceux qu’on peut voir sur les guichets automatiques qui vous demandent si vous avez besoin de davantage de temps).

Lorsque du contenu est animé, l’animation ne devrait pas durer plus de cinq secondes, à moins que l’utilisateur ait un moyen de la contrôler. Une animation peut être purement décorative, la limite de temps est donc utile pour les personnes qui souffrent de déficience cognitive et pour qui une animation continue en périphérie rend plus difficile le fait de se concentrer sur le contenu principal.

Pour une animation telle que le défilement ou le déplacement d’un contenu, la restriction impose de permettre aux utilisateurs de terminer leur tâche sans changements de contexte inattendus. Un lecteur d’actualités qui défile automatiquement par exemple devrait avoir un bouton pause, pour laisser l’utilisateur lire chaque actualité à son propre rythme et en étant assuré que les choses ne bougeront pas pendant qu’il la lira ! Cela est également valable lorsque de grands blocs de contenus ou des pages entières sont automatiquement rechargés. C’est très courant sur les sites de bourse en ligne ou de résultats sportifs. Vous ne devriez jamais faire cela, à moins de fournir des contrôles spécifiques à l’utilisateur sur la fréquence de rafraîchissement (qui devrait être à never (jamais) par défaut).

Mais les limites temporelles font souvent partie intégrante des activités pour lesquelles elles sont utilisées. Beaucoup de jeux comportent intrinsèquement des limites de temps et les supprimer nuirait au principe même du jeu. Dans de tels cas, on peut dire que le contenu ne peut être rendu accessible sans changer sa signification. Les règles d’accessibilité autorisent cette possibilité, du moment que le contenu est clairement décrit comme tel.

Conclusion

Nous venons de voir que l’accessibilité de JavaScript peut se résumer à trois principes fondamentaux.

  • Toute fonctionnalité JavaScript doit prendre une forme qui peut être interprétée comme du texte.
  • Toute fonctionnalité JavaScript doit être accessible au clavier.
  • Les activités temporelles en JavaScript doivent pouvoir être contrôlées par l’utilisateur, à moins que cela ne change leur sens.

La prochaine fois, nous nous éloignerons de la théorie, pour voir quelques petites choses simples mais pratiques que vous pouvez mettre en œuvre dès à présent pour rendre une fonctionnalité JavaScript plus accessible. Et nous ne parlons pas de techniques à peine prises en charge, non testées ou avant-gardistes mais bien de ce que nous faisons déjà depuis des années.

http://www.sitepoint.com/javascript-accessibility-101/]]> http://www.pompage.net/traduction/introduction-a-l-accessibilite-de-javascript http://www.pompage.net/traduction/introduction-a-l-accessibilite-de-javascript Mon, 04 Aug 2014 10:00:00 +0200 <![CDATA[Introduction à l'accessibilité de JavaScript]]>

Par James Edwards

Il fut un temps où l’accessibilité de JavaScript signifiait simplement assurer une dégradation élégante lorsque JavaScript n’était pas disponible. Mais, avec la percée d’Ajax et des Applications Internet Riches (RIA), JavaScript n’est plus seulement utilisé pour améliorer l’utilisabilité à la marge, il constitue désormais la base des applications web. De nos jours, parler de l’accessibilité de JavaScript c’est s’assurer que le code JavaScript est accessible en lui-même.

Ce que nous réserve l’avenir

Le protocole d’accessibilité des applications Internet riches (NdT : ARIA en anglais, pour Accessible Rich Internet Applications) est une des évolutions les plus importantes de ces dernières années dans l’accessibilité web. Il a été conçu par le groupe Initiative pour l’Accessibilité du Web (WAI) et définit une sémantique permettant de rendre le contenu interactif accessible aux technologies d’assistance telles que les lecteurs d’écran. WAI-ARIA est apparu par nécessité, l’explosion du Web 2.0 s’étant faite presque sans aucune considération d’accessibilité. JavaScript est désormais utilisé dans le code d’applications web critiques et les technologies d’assistance doivent donc impérativement pouvoir interpréter le contenu dynamique.

Aujourd’hui

Malheureusement, ARIA n’est pas encore très bien pris en charge. Seules les dernières versions des (très coûteux) lecteurs d’écran offrent un début de prise en charge, et aucun d’entre eux ne l’offre intégralement. De plus, ce qui est supporté n’est pas forcément bien implémenté. Et même quand ARIA sera largement pris en charge, ce ne sera pas pour autant la réponse à tout car l’accessibilité de JavaScript ne se résume pas à ce qui est défini par ARIA. Pour que les fondations de ce protocole soient solides, elles doivent associer une véritable compréhension du besoin utilisateur et des développements basés sur les standards.

Sitepoint va consacrer plusieurs articles à l’accessibilité de JavaScript. Nous commençons par un aperçu des choses simples que vous pouvez faire dès à présent pour rendre votre JavaScript plus accessible. Plus tard, nous entrerons plus en détails dans le monde d’ARIA. Mais avant toute chose, nous devons revoir quelques concepts théoriques

Le cœur de l’accessibilité

L’accessibilité de JavaScript peut être divisée en trois grands groupes de besoins utilisateurs. Ce chapitre décrit ces groupes de manière détaillée.

Les utilisateurs de technologies d’assistance

Le premier groupe comprend les personnes qui utilisent des lecteurs d’écran, plages Braille ou d’autres aides techniques de ce genre. Les aveugles sont majoritaires dans ce groupe, mais il inclut également les personnes souffrant de handicaps visuels ou cognitifs, pour qui les lecteurs d’écran facilitent la lecture et la compréhension.

Les technologies d’assistance présentent toutes les informations sous forme de texte structuré. Par conséquent, toutes les fonctionnalités JavaScript doivent adopter une forme qui puisse être présentée textuellement. Une barre de progression scriptée telle qu’illustrée ci-dessous fournit des informations visuelles, elle devrait donc être complétée par un texte fournissant les mêmes informations.

PNG - 3.4 ko
Une barre de progressions dont la position, 76%, est indiquée visuellement et à l’aide d’un nombre en pourcentage.

Le texte en lui-même ne suffit pas, s’il ne possède pas de structure ou de liaisons interprétables par les technologies d’assistance. Un texte est souvent structuré de façon très simple, sous forme de listes et de tableaux. Les technologies d’assistance comprennent aisément ce type de structure, il ne nous reste donc qu’à les utiliser correctement.

En utilisant par exemple des listes non ordonnées et des libellés de structure comme base d’un menu déroulant, les technologies d’assistance peuvent interpréter le sens à partir de la sémantique et de la hiérarchie de ces éléments. Nous pouvons également construire des widgets de calendrier où chaque mois est représenté par un tableau HTML. Il suffit alors de déclencher son affichage par un bouton et de le décrire à l’aide d’une légende. Une sémantique solide des éléments doit constituer la base de tout contenu interactif.

Les utilisateurs qui naviguent au clavier

Le deuxième groupe est formé par les personnes qui utilisent uniquement le clavier. Ce groupe comprend les non-voyants utilisant un lecteur d’écran, mais également les personnes voyantes qui ne peuvent pas utiliser la souris en raison d’un handicap moteur, ainsi que les personnes ayant une déficience cognitive et pour suivre les éléments qui possèdent le focus aide à se concentrer. Pour s’adapter aux besoins de ce groupe, toutes les fonctionnalités JavaScript doit être accessibles au clavier. Les interactions par exemple doivent être limitées aux touches les plus intuitives : tabulation, les flèches, la touche Entrée et la touche d’échappement.

La prise en charge du clavier se fait souvent à moindre coût, pour peu que vous partiez du principe que le meilleur événement est toujours celui qui est le plus indépendant du périphérique. Ainsi, la validation du formulaire doit être liée à l’événement submit du formulaire, tandis que les événements d’activation primaires devraient être liés à l’événement clic universel, plutôt que des événements spécifiques comme mousedown, touchstart ou KeyDown.

Pour les interactions plus complexes, il est souvent nécessaire de combiner les événements. Les Règles d’Accessibilité pour les Contenus Web (NdT : Web Content Accessibility Guidelines, ou WCAG en anglais) parlent d’association d’événements : il s’agit de coupler les événements souris avec leur équivalent clavier le plus similaire. Un exemple est le couplage des événements mousedown et keydown. Ce n’est toutefois pas la bonne façon de voir les choses car on se concentre ici sur la technique plutôt que sur la finalité d’une action. Tant que l’objectif est atteint, peu importe que les modalités au clavier soient totalement différentes de l’action à la souris.

Pour le glisser-déposer par exemple, il n’y a pas d’équivalent à l’événement mousemove, mais nous pouvons quand même rendre cette fonctionnalité accessible au clavier. Il s’agit en fait de deux interactions distinctes. La première permet de déplacer des éléments vers le haut ou le bas pour les réorganiser, ce qui peut tout simplement se faire grâce aux flèches haut et bas. La seconde interaction concerne l’action d’attraper et de déplacer, pour déplacer des fichiers d’un dossier à un autre par exemple. Cela peut se faire par exemple avec la touche Espace pour sélectionner l’élément, la touche Tabulation pour sélectionner la destination, et la touche Entrée pour déposer.

Lorsque des touches non-standard sont utilisées, un texte d’accompagnement devrait figurer pour l’expliquer. Dans les faits, certaines interactions seront immanquablement plus compliquées que leur équivalent à la souris. Mais ce n’est pas bien grave, du moment que le résultat est atteignable. L’accessibilité c’est l’équivalence, pas l’égalité.

Une autre considération importante concernant l’accessibilité au clavier est de garder un ordre logique du contenu. Des bulles d’aide enrichies, par exemple, doivent être insérées immédiatement après l’élément qu’elles concernent pour qu’on y accède directement en tabulant une seule fois, et afin que les lecteurs d’écran puissent les lire dans la foulée.

Les utilisateurs sensibles au clignotement ou aux limites de temps

Le dernier groupe comprend les personnes sensibles aux clignotements ou aux brusques changements de luminosité, ou qui ne peuvent pas réagir aux événements en temps réel comme les autres. Le contenu clignotant affecte les personnes souffrant d’une épilepsie photosensible, chez qui cela peut provoquer une crise, ainsi que les personnes souffrant de déficience cognitive, qui ont du mal à se concentrer lorsque les choses bougent dans leur vision périphérique. Les limitations sur les contenus qui clignotent sont assez bien formulées par les règles d’accessibilité pour les contenus web et synthétisées par le seuil de trois clignotements maximum.

Les limites temporelles peuvent également s’avérer problématiques car écouter un contenu vocalisé prend plus de temps que de le lire. Naviguer au clavier prend également plus de temps qu’à la souris. De ce fait, les actions JavaScript basées sur le temps doivent être contrôlables par l’utilisateur. Les limites sur des activités temporelles ne sont pas trop spécifiques, car il y a différents cas de figure à prendre en considération.

Le grand principe pour les limites temporelles est que si une activité doit être effectuée dans un certain laps de temps, l’utilisateur est prévenu quand la limite est sur le point d’expirer et se voit proposer une façon de la rallonger. Par exemple, un site de banque en ligne peut avoir des limites de temps strictes sur l’inactivité de session, mais l’utilisateur doit pouvoir l’allonger à l’aide d’un simple dialogue de confirmation (comme ceux qu’on peut voir sur les guichets automatiques qui vous demandent si vous avez besoin de davantage de temps).

Lorsque du contenu est animé, l’animation ne devrait pas durer plus de cinq secondes, à moins que l’utilisateur ait un moyen de la contrôler. Une animation peut être purement décorative, la limite de temps est donc utile pour les personnes qui souffrent de déficience cognitive et pour qui une animation continue en périphérie rend plus difficile le fait de se concentrer sur le contenu principal.

Pour une animation telle que le défilement ou le déplacement d’un contenu, la restriction impose de permettre aux utilisateurs de terminer leur tâche sans changements de contexte inattendus. Un lecteur d’actualités qui défile automatiquement par exemple devrait avoir un bouton pause, pour laisser l’utilisateur lire chaque actualité à son propre rythme et en étant assuré que les choses ne bougeront pas pendant qu’il la lira ! Cela est également valable lorsque de grands blocs de contenus ou des pages entières sont automatiquement rechargés. C’est très courant sur les sites de bourse en ligne ou de résultats sportifs. Vous ne devriez jamais faire cela, à moins de fournir des contrôles spécifiques à l’utilisateur sur la fréquence de rafraîchissement (qui devrait être à never (jamais) par défaut).

Mais les limites temporelles font souvent partie intégrante des activités pour lesquelles elles sont utilisées. Beaucoup de jeux comportent intrinsèquement des limites de temps et les supprimer nuirait au principe même du jeu. Dans de tels cas, on peut dire que le contenu ne peut être rendu accessible sans changer sa signification. Les règles d’accessibilité autorisent cette possibilité, du moment que le contenu est clairement décrit comme tel.

Conclusion

Nous venons de voir que l’accessibilité de JavaScript peut se résumer à trois principes fondamentaux.

  • Toute fonctionnalité JavaScript doit prendre une forme qui peut être interprétée comme du texte.
  • Toute fonctionnalité JavaScript doit être accessible au clavier.
  • Les activités temporelles en JavaScript doivent pouvoir être contrôlées par l’utilisateur, à moins que cela ne change leur sens.

La prochaine fois, nous nous éloignerons de la théorie, pour voir quelques petites choses simples mais pratiques que vous pouvez mettre en œuvre dès à présent pour rendre une fonctionnalité JavaScript plus accessible. Et nous ne parlons pas de techniques à peine prises en charge, non testées ou avant-gardistes mais bien de ce que nous faisons déjà depuis des années.

]]> http://www.pompage.net/traduction/introduction-a-l-accessibilite-de http://www.pompage.net/traduction/introduction-a-l-accessibilite-de Mon, 04 Aug 2014 08:08:00 +0200 <![CDATA[]]>

Par James Edwards

Il fut un temps où l’accessibilité de JavaScript signifiait simplement assurer une dégradation élégante lorsque JavaScript n’était pas disponible. Mais, avec la percée d’Ajax et des Applications Internet Riches (RIA), JavaScript n’est plus seulement utilisé pour améliorer l’utilisabilité à la marge, il constitue désormais la base des applications web. De nos jours, parler de l’accessibilité de JavaScript c’est s’assurer que le code JavaScript est accessible en lui-même.

Ce que nous réserve l’avenir

Le protocole d’accessibilité des applications Internet riches (NdT : ARIA en anglais, pour Accessible Rich Internet Applications) est une des évolutions les plus importantes de ces dernières années dans l’accessibilité web. Il a été conçu par le groupe Initiative pour l’Accessibilité du Web (WAI) et définit une sémantique permettant de rendre le contenu interactif accessible aux technologies d’assistance telles que les lecteurs d’écran. WAI-ARIA est apparu par nécessité, l’explosion du Web 2.0 s’étant faite presque sans aucune considération d’accessibilité. JavaScript est désormais utilisé dans le code d’applications web critiques et les technologies d’assistance doivent donc impérativement pouvoir interpréter le contenu dynamique.

Aujourd’hui

Malheureusement, ARIA n’est pas encore très bien pris en charge. Seules les dernières versions des (très coûteux) lecteurs d’écran offrent un début de prise en charge, et aucun d’entre eux ne l’offre intégralement. De plus, ce qui est supporté n’est pas forcément bien implémenté. Et même quand ARIA sera largement pris en charge, ce ne sera pas pour autant la réponse à tout car l’accessibilité de JavaScript ne se résume pas à ce qui est défini par ARIA. Pour que les fondations de ce protocole soient solides, elles doivent associer une véritable compréhension du besoin utilisateur et des développements basés sur les standards.

Sitepoint va consacrer plusieurs articles à l’accessibilité de JavaScript. Nous commençons par un aperçu des choses simples que vous pouvez faire dès à présent pour rendre votre JavaScript plus accessible. Plus tard, nous entrerons plus en détails dans le monde d’ARIA. Mais avant toute chose, nous devons revoir quelques concepts théoriques

Le cœur de l’accessibilité

L’accessibilité de JavaScript peut être divisée en trois grands groupes de besoins utilisateurs. Ce chapitre décrit ces groupes de manière détaillée.

Les utilisateurs de technologies d’assistance

Le premier groupe comprend les personnes qui utilisent des lecteurs d’écran, plages Braille ou d’autres aides techniques de ce genre. Les aveugles sont majoritaires dans ce groupe, mais il inclut également les personnes souffrant de handicaps visuels ou cognitifs, pour qui les lecteurs d’écran facilitent la lecture et la compréhension.

Les technologies d’assistance présentent toutes les informations sous forme de texte structuré. Par conséquent, toutes les fonctionnalités JavaScript doivent adopter une forme qui puisse être présentée textuellement. Une barre de progression scriptée telle qu’illustrée ci-dessous fournit des informations visuelles, elle devrait donc être complétée par un texte fournissant les mêmes informations.

Une barre de progressions dont la position, 76%, est indiquée visuellement et à l’aide d’un nombre en pourcentage.

Le texte en lui-même ne suffit pas, s’il ne possède pas de structure ou de liaisons interprétables par les technologies d’assistance. Un texte est souvent structuré de façon très simple, sous forme de listes et de tableaux. Les technologies d’assistance comprennent aisément ce type de structure, il ne nous reste donc qu’à les utiliser correctement.

En utilisant par exemple des listes non ordonnées et des libellés de structure comme base d’un menu déroulant, les technologies d’assistance peuvent interpréter le sens à partir de la sémantique et de la hiérarchie de ces éléments. Nous pouvons également construire des widgets de calendrier où chaque mois est représenté par un tableau HTML. Il suffit alors de déclencher son affichage par un bouton et de le décrire à l’aide d’une légende. Une sémantique solide des éléments doit constituer la base de tout contenu interactif.

Les utilisateurs qui naviguent au clavier

Le deuxième groupe est formé par les personnes qui utilisent uniquement le clavier. Ce groupe comprend les non-voyants utilisant un lecteur d’écran, mais également les personnes voyantes qui ne peuvent pas utiliser la souris en raison d’un handicap moteur, ainsi que les personnes ayant une déficience cognitive et pour suivre les éléments qui possèdent le focus aide à se concentrer. Pour s’adapter aux besoins de ce groupe, toutes les fonctionnalités JavaScript doit être accessibles au clavier. Les interactions par exemple doivent être limitées aux touches les plus intuitives : tabulation, les flèches, la touche Entrée et la touche d’échappement.

La prise en charge du clavier se fait souvent à moindre coût, pour peu que vous partiez du principe que le meilleur événement est toujours celui qui est le plus indépendant du périphérique. Ainsi, la validation du formulaire doit être liée à l’événement submit du formulaire, tandis que les événements d’activation primaires devraient être liés à l’événement clic universel, plutôt que des événements spécifiques comme mousedown, touchstart ou KeyDown.

Pour les interactions plus complexes, il est souvent nécessaire de combiner les événements. Les Règles d’Accessibilité pour les Contenus Web (NdT : Web Content Accessibility Guidelines, ou WCAG en anglais) parlent d’association d’événements : il s’agit de coupler les événements souris avec leur équivalent clavier le plus similaire. Un exemple est le couplage des événements mousedown et keydown. Ce n’est toutefois pas la bonne façon de voir les choses car on se concentre ici sur la technique plutôt que sur la finalité d’une action. Tant que l’objectif est atteint, peu importe que les modalités au clavier soient totalement différentes de l’action à la souris.

Pour le glisser-déposer par exemple, il n’y a pas d’équivalent à l’événement mousemove, mais nous pouvons quand même rendre cette fonctionnalité accessible au clavier. Il s’agit en fait de deux interactions distinctes. La première permet de déplacer des éléments vers le haut ou le bas pour les réorganiser, ce qui peut tout simplement se faire grâce aux flèches haut et bas. La seconde interaction concerne l’action d’attraper et de déplacer, pour déplacer des fichiers d’un dossier à un autre par exemple. Cela peut se faire par exemple avec la touche Espace pour sélectionner l’élément, la touche Tabulation pour sélectionner la destination, et la touche Entrée pour déposer.

Lorsque des touches non-standard sont utilisées, un texte d’accompagnement devrait figurer pour l’expliquer. Dans les faits, certaines interactions seront immanquablement plus compliquées que leur équivalent à la souris. Mais ce n’est pas bien grave, du moment que le résultat est atteignable. L’accessibilité c’est l’équivalence, pas l’égalité.

Une autre considération importante concernant l’accessibilité au clavier est de garder un ordre logique du contenu. Des bulles d’aide enrichies, par exemple, doivent être insérées immédiatement après l’élément qu’elles concernent pour qu’on y accède directement en tabulant une seule fois, et afin que les lecteurs d’écran puissent les lire dans la foulée.

Les utilisateurs sensibles au clignotement ou aux limites de temps

Le dernier groupe comprend les personnes sensibles aux clignotements ou aux brusques changements de luminosité, ou qui ne peuvent pas réagir aux événements en temps réel comme les autres. Le contenu clignotant affecte les personnes souffrant d’une épilepsie photosensible, chez qui cela peut provoquer une crise, ainsi que les personnes souffrant de déficience cognitive, qui ont du mal à se concentrer lorsque les choses bougent dans leur vision périphérique. Les limitations sur les contenus qui clignotent sont assez bien formulées par les règles d’accessibilité pour les contenus web et synthétisées par le seuil de trois clignotements maximum.

Les limites temporelles peuvent également s’avérer problématiques car écouter un contenu vocalisé prend plus de temps que de le lire. Naviguer au clavier prend également plus de temps qu’à la souris. De ce fait, les actions JavaScript basées sur le temps doivent être contrôlables par l’utilisateur. Les limites sur des activités temporelles ne sont pas trop spécifiques, car il y a différents cas de figure à prendre en considération.

Le grand principe pour les limites temporelles est que si une activité doit être effectuée dans un certain laps de temps, l’utilisateur est prévenu quand la limite est sur le point d’expirer et se voit proposer une façon de la rallonger. Par exemple, un site de banque en ligne peut avoir des limites de temps strictes sur l’inactivité de session, mais l’utilisateur doit pouvoir l’allonger à l’aide d’un simple dialogue de confirmation (comme ceux qu’on peut voir sur les guichets automatiques qui vous demandent si vous avez besoin de davantage de temps).

Lorsque du contenu est animé, l’animation ne devrait pas durer plus de cinq secondes, à moins que l’utilisateur ait un moyen de la contrôler. Une animation peut être purement décorative, la limite de temps est donc utile pour les personnes qui souffrent de déficience cognitive et pour qui une animation continue en périphérie rend plus difficile le fait de se concentrer sur le contenu principal.

Pour une animation telle que le défilement ou le déplacement d’un contenu, la restriction impose de permettre aux utilisateurs de terminer leur tâche sans changements de contexte inattendus. Un lecteur d’actualités qui défile automatiquement par exemple devrait avoir un bouton pause, pour laisser l’utilisateur lire chaque actualité à son propre rythme et en étant assuré que les choses ne bougeront pas pendant qu’il la lira ! Cela est également valable lorsque de grands blocs de contenus ou des pages entières sont automatiquement rechargés. C’est très courant sur les sites de bourse en ligne ou de résultats sportifs. Vous ne devriez jamais faire cela, à moins de fournir des contrôles spécifiques à l’utilisateur sur la fréquence de rafraîchissement (qui devrait être à never (jamais) par défaut).

Mais les limites temporelles font souvent partie intégrante des activités pour lesquelles elles sont utilisées. Beaucoup de jeux comportent intrinsèquement des limites de temps et les supprimer nuirait au principe même du jeu. Dans de tels cas, on peut dire que le contenu ne peut être rendu accessible sans changer sa signification. Les règles d’accessibilité autorisent cette possibilité, du moment que le contenu est clairement décrit comme tel.

Conclusion

Nous venons de voir que l’accessibilité de JavaScript peut se résumer à trois principes fondamentaux.

  • Toute fonctionnalité JavaScript doit prendre une forme qui peut être interprétée comme du texte.
  • Toute fonctionnalité JavaScript doit être accessible au clavier.
  • Les activités temporelles en JavaScript doivent pouvoir être contrôlées par l’utilisateur, à moins que cela ne change leur sens.

La prochaine fois, nous nous éloignerons de la théorie, pour voir quelques petites choses simples mais pratiques que vous pouvez mettre en œuvre dès à présent pour rendre une fonctionnalité JavaScript plus accessible. Et nous ne parlons pas de techniques à peine prises en charge, non testées ou avant-gardistes mais bien de ce que nous faisons déjà depuis des années.

]]> http://www.pompage.net/traduction/introduction-a-l-accessibilite-de http://www.pompage.net/traduction/introduction-a-l-accessibilite-de Mon, 04 Aug 2014 08:08:00 +0200 <![CDATA[Introduction à l'accessibilité de JavaScript]]>

Par James Edwards

Il fut un temps où l’accessibilité de JavaScript signifiait simplement assurer une dégradation élégante lorsque JavaScript n’était pas disponible. Mais, avec la percée d’Ajax et des Applications Internet Riches (RIA), JavaScript n’est plus seulement utilisé pour améliorer l’utilisabilité à la marge, il constitue désormais la base des applications web. De nos jours, parler de l’accessibilité de JavaScript c’est s’assurer que le code JavaScript est accessible en lui-même.

Ce que nous réserve l’avenir

Le protocole d’accessibilité des applications Internet riches (NdT : ARIA en anglais, pour Accessible Rich Internet Applications) est une des évolutions les plus importantes de ces dernières années dans l’accessibilité web. Il a été conçu par le groupe Initiative pour l’Accessibilité du Web (WAI) et définit une sémantique permettant de rendre le contenu interactif accessible aux technologies d’assistance telles que les lecteurs d’écran. WAI-ARIA est apparu par nécessité, l’explosion du Web 2.0 s’étant faite presque sans aucune considération d’accessibilité. JavaScript est désormais utilisé dans le code d’applications web critiques et les technologies d’assistance doivent donc impérativement pouvoir interpréter le contenu dynamique.

Aujourd’hui

Malheureusement, ARIA n’est pas encore très bien pris en charge. Seules les dernières versions des (très coûteux) lecteurs d’écran offrent un début de prise en charge, et aucun d’entre eux ne l’offre intégralement. De plus, ce qui est supporté n’est pas forcément bien implémenté. Et même quand ARIA sera largement pris en charge, ce ne sera pas pour autant la réponse à tout car l’accessibilité de JavaScript ne se résume pas à ce qui est défini par ARIA. Pour que les fondations de ce protocole soient solides, elles doivent associer une véritable compréhension du besoin utilisateur et des développements basés sur les standards.

Sitepoint va consacrer plusieurs articles à l’accessibilité de JavaScript. Nous commençons par un aperçu des choses simples que vous pouvez faire dès à présent pour rendre votre JavaScript plus accessible. Plus tard, nous entrerons plus en détails dans le monde d’ARIA. Mais avant toute chose, nous devons revoir quelques concepts théoriques

Le cœur de l’accessibilité

L’accessibilité de JavaScript peut être divisée en trois grands groupes de besoins utilisateurs. Ce chapitre décrit ces groupes de manière détaillée.

Les utilisateurs de technologies d’assistance

Le premier groupe comprend les personnes qui utilisent des lecteurs d’écran, plages Braille ou d’autres aides techniques de ce genre. Les aveugles sont majoritaires dans ce groupe, mais il inclut également les personnes souffrant de handicaps visuels ou cognitifs, pour qui les lecteurs d’écran facilitent la lecture et la compréhension.

Les technologies d’assistance présentent toutes les informations sous forme de texte structuré. Par conséquent, toutes les fonctionnalités JavaScript doivent adopter une forme qui puisse être présentée textuellement. Une barre de progression scriptée telle qu’illustrée ci-dessous fournit des informations visuelles, elle devrait donc être complétée par un texte fournissant les mêmes informations.

Une barre de progressions dont la position, 76%, est indiquée visuellement et à l’aide d’un nombre en pourcentage.

Le texte en lui-même ne suffit pas, s’il ne possède pas de structure ou de liaisons interprétables par les technologies d’assistance. Un texte est souvent structuré de façon très simple, sous forme de listes et de tableaux. Les technologies d’assistance comprennent aisément ce type de structure, il ne nous reste donc qu’à les utiliser correctement.

En utilisant par exemple des listes non ordonnées et des libellés de structure comme base d’un menu déroulant, les technologies d’assistance peuvent interpréter le sens à partir de la sémantique et de la hiérarchie de ces éléments. Nous pouvons également construire des widgets de calendrier où chaque mois est représenté par un tableau HTML. Il suffit alors de déclencher son affichage par un bouton et de le décrire à l’aide d’une légende. Une sémantique solide des éléments doit constituer la base de tout contenu interactif.

Les utilisateurs qui naviguent au clavier

Le deuxième groupe est formé par les personnes qui utilisent uniquement le clavier. Ce groupe comprend les non-voyants utilisant un lecteur d’écran, mais également les personnes voyantes qui ne peuvent pas utiliser la souris en raison d’un handicap moteur, ainsi que les personnes ayant une déficience cognitive et pour suivre les éléments qui possèdent le focus aide à se concentrer. Pour s’adapter aux besoins de ce groupe, toutes les fonctionnalités JavaScript doit être accessibles au clavier. Les interactions par exemple doivent être limitées aux touches les plus intuitives : tabulation, les flèches, la touche Entrée et la touche d’échappement.

La prise en charge du clavier se fait souvent à moindre coût, pour peu que vous partiez du principe que le meilleur événement est toujours celui qui est le plus indépendant du périphérique. Ainsi, la validation du formulaire doit être liée à l’événement submit du formulaire, tandis que les événements d’activation primaires devraient être liés à l’événement clic universel, plutôt que des événements spécifiques comme mousedown, touchstart ou KeyDown.

Pour les interactions plus complexes, il est souvent nécessaire de combiner les événements. Les Règles d’Accessibilité pour les Contenus Web (NdT : Web Content Accessibility Guidelines, ou WCAG en anglais) parlent d’association d’événements : il s’agit de coupler les événements souris avec leur équivalent clavier le plus similaire. Un exemple est le couplage des événements mousedown et keydown. Ce n’est toutefois pas la bonne façon de voir les choses car on se concentre ici sur la technique plutôt que sur la finalité d’une action. Tant que l’objectif est atteint, peu importe que les modalités au clavier soient totalement différentes de l’action à la souris.

Pour le glisser-déposer par exemple, il n’y a pas d’équivalent à l’événement mousemove, mais nous pouvons quand même rendre cette fonctionnalité accessible au clavier. Il s’agit en fait de deux interactions distinctes. La première permet de déplacer des éléments vers le haut ou le bas pour les réorganiser, ce qui peut tout simplement se faire grâce aux flèches haut et bas. La seconde interaction concerne l’action d’attraper et de déplacer, pour déplacer des fichiers d’un dossier à un autre par exemple. Cela peut se faire par exemple avec la touche Espace pour sélectionner l’élément, la touche Tabulation pour sélectionner la destination, et la touche Entrée pour déposer.

Lorsque des touches non-standard sont utilisées, un texte d’accompagnement devrait figurer pour l’expliquer. Dans les faits, certaines interactions seront immanquablement plus compliquées que leur équivalent à la souris. Mais ce n’est pas bien grave, du moment que le résultat est atteignable. L’accessibilité c’est l’équivalence, pas l’égalité.

Une autre considération importante concernant l’accessibilité au clavier est de garder un ordre logique du contenu. Des bulles d’aide enrichies, par exemple, doivent être insérées immédiatement après l’élément qu’elles concernent pour qu’on y accède directement en tabulant une seule fois, et afin que les lecteurs d’écran puissent les lire dans la foulée.

Les utilisateurs sensibles au clignotement ou aux limites de temps

Le dernier groupe comprend les personnes sensibles aux clignotements ou aux brusques changements de luminosité, ou qui ne peuvent pas réagir aux événements en temps réel comme les autres. Le contenu clignotant affecte les personnes souffrant d’une épilepsie photosensible, chez qui cela peut provoquer une crise, ainsi que les personnes souffrant de déficience cognitive, qui ont du mal à se concentrer lorsque les choses bougent dans leur vision périphérique. Les limitations sur les contenus qui clignotent sont assez bien formulées par les règles d’accessibilité pour les contenus web et synthétisées par le seuil de trois clignotements maximum.

Les limites temporelles peuvent également s’avérer problématiques car écouter un contenu vocalisé prend plus de temps que de le lire. Naviguer au clavier prend également plus de temps qu’à la souris. De ce fait, les actions JavaScript basées sur le temps doivent être contrôlables par l’utilisateur. Les limites sur des activités temporelles ne sont pas trop spécifiques, car il y a différents cas de figure à prendre en considération.

Le grand principe pour les limites temporelles est que si une activité doit être effectuée dans un certain laps de temps, l’utilisateur est prévenu quand la limite est sur le point d’expirer et se voit proposer une façon de la rallonger. Par exemple, un site de banque en ligne peut avoir des limites de temps strictes sur l’inactivité de session, mais l’utilisateur doit pouvoir l’allonger à l’aide d’un simple dialogue de confirmation (comme ceux qu’on peut voir sur les guichets automatiques qui vous demandent si vous avez besoin de davantage de temps).

Lorsque du contenu est animé, l’animation ne devrait pas durer plus de cinq secondes, à moins que l’utilisateur ait un moyen de la contrôler. Une animation peut être purement décorative, la limite de temps est donc utile pour les personnes qui souffrent de déficience cognitive et pour qui une animation continue en périphérie rend plus difficile le fait de se concentrer sur le contenu principal.

Pour une animation telle que le défilement ou le déplacement d’un contenu, la restriction impose de permettre aux utilisateurs de terminer leur tâche sans changements de contexte inattendus. Un lecteur d’actualités qui défile automatiquement par exemple devrait avoir un bouton pause, pour laisser l’utilisateur lire chaque actualité à son propre rythme et en étant assuré que les choses ne bougeront pas pendant qu’il la lira ! Cela est également valable lorsque de grands blocs de contenus ou des pages entières sont automatiquement rechargés. C’est très courant sur les sites de bourse en ligne ou de résultats sportifs. Vous ne devriez jamais faire cela, à moins de fournir des contrôles spécifiques à l’utilisateur sur la fréquence de rafraîchissement (qui devrait être à never (jamais) par défaut).

Mais les limites temporelles font souvent partie intégrante des activités pour lesquelles elles sont utilisées. Beaucoup de jeux comportent intrinsèquement des limites de temps et les supprimer nuirait au principe même du jeu. Dans de tels cas, on peut dire que le contenu ne peut être rendu accessible sans changer sa signification. Les règles d’accessibilité autorisent cette possibilité, du moment que le contenu est clairement décrit comme tel.

Conclusion

Nous venons de voir que l’accessibilité de JavaScript peut se résumer à trois principes fondamentaux.

  • Toute fonctionnalité JavaScript doit prendre une forme qui peut être interprétée comme du texte.
  • Toute fonctionnalité JavaScript doit être accessible au clavier.
  • Les activités temporelles en JavaScript doivent pouvoir être contrôlées par l’utilisateur, à moins que cela ne change leur sens.

La prochaine fois, nous nous éloignerons de la théorie, pour voir quelques petites choses simples mais pratiques que vous pouvez mettre en œuvre dès à présent pour rendre une fonctionnalité JavaScript plus accessible. Et nous ne parlons pas de techniques à peine prises en charge, non testées ou avant-gardistes mais bien de ce que nous faisons déjà depuis des années.

]]> https://www.pompage.net/traduction/introduction-a-l-accessibilite-de https://www.pompage.net/traduction/introduction-a-l-accessibilite-de Mon, 04 Aug 2014 08:08:00 +0200 <![CDATA[Votre application me fait grossir]]>

Par Kathy Sierra

L'expérience utilisateur vue à travers le prisme de la psychologie comportementale... attention à ne pas épuiser les ressources cognitives de vos visiteurs!

En 1999, le professeur Baba Shiv (qui enseigne aujourd’hui à Stanford) et son co-auteur Alex Fedorikhin ont mené une expérience simple sur 165 étudiants. Ils ont demandé à la moitié d’entre eux de mémoriser un nombre de sept chiffres, et à l’autre moitié de mémoriser un nombre de deux chiffres. Après cette tâche de mémorisation, on a dit aux participants que la tâche était terminée, et qu’ils pouvaient prendre un en-cas : au choix, du gâteau au chocolat ou de la salade de fruits.

Résultat ? Les participants qui devaient mémoriser le nombre de sept chiffres étaient 50 % plus attirés par le gâteau au chocolat que ne l’étaient les membres de l’autre groupe.

Les chercheurs, sidérés par les résultats convergents d’un grand nombre d’expériences, sont parvenus à cette étrange conclusion : le contrôle de soi et les processus cognitifs sont alimentés par la même réserve de ressources.

Vous passez des heures au boulot concentré sur un problème de design ? Vous aurez plus de chance de faire une petite halte chez McDo en rentrant chez vous. Vous vous retenez de dire ce que vous pensez vraiment pendant une réunion pénible et interminable ? Vous aurez plus de mal à coder plus tard dans la journée.

Car la volonté, le contrôle de soi et les tâches cognitives puisent dans les mêmes réserves. Si vous épuisez ces réserves à un moment donné, vous en paierez forcément le prix un peu plus tard. Il n’y a qu’une seule réserve. Une réserve de ressources rares, précieuses et très volatiles. Si vous passez votre journée à vous contrôler (face à des clients mécontents ou à des collègues incapables), vous rentrez chez vous le soir avec la jauge à zéro.

Le réservoir est vide. Et même si vous adorez vous frotter à des problèmes compliqués quand vous êtes au travail, cela n’empêche pas du tout que vos ressources soient diminuées. Il n’y a qu’une seule réserve. Qu’elle soit consommée par des activités que vous aimez ou que vous détestez n’y change rien. Le réservoir de ressources cognitives s’en fiche. Du coup, la moindre petite chose vous fait râler contre vos enfants ou votre chien. Ou bien c’est le chien qui vous grogne dessus.


Au cours d’une expérience, un premier groupe de chiens devait rester assis pendant quelques minutes sans rien faire, avant d’être autorisés à jouer avec leur jouet à croquettes « intelligent » (le genre de jouet où le chien doit fournir des efforts pour en extraire des croquettes). Les chiens de l’autre groupe restaient tranquilles dans leurs cages avant de recevoir leur jouet.

Vous imaginez peut-être déjà la suite : les chiens qu’on avait obligés à rester assis (et donc à être dans le contrôle de soi) ont abandonné beaucoup plus tôt leur jouet que ceux qui étaient restés tranquilles dans leurs cages. Les chiens qui n’avaient PAS dépensé de ressources cognitives en s’efforçant d’obéir montraient davantage de détermination et d’énergie mentale et émotionnelle pour résoudre le problème. Pensez-y la prochaine fois que vous demanderez à Youki de patienter un peu. Car ses ressources cognitives à lui s’épuisent tout aussi vite.

Réfléchissons maintenant à ce que nous faisons subir à nos utilisateurs. Si l’expérience utilisateur les oblige à faire des choix, et même si ces choix sont à la fois clairs et utiles, cet acte de décision diminue leurs ressources cognitives. Et pas uniquement au moment du choix… même après ce moment, ils continuent à consommer inconsciemment leurs ressources : « Ai-je fait le bon choix ? »

Si votre application est compliquée et si votre FAQ ou votre aide en ligne ne répond pas à mes besoins, vous faites baisser mon maigre niveau de ressources cognitives. Si votre application se comporte de façon contre-intuitive (même si ça n’arrive qu’une seule fois), je perdrai une partie de mes ressources à chaque nouvelle utilisation, parce que je me demanderai toujours : « Attends, est-ce que ça fait bien ce que je pensais ? »

Ou bien, imaginons que votre application soit vraiment hyper-facile à utiliser mais que dans son design et dans son fonctionnement elle soit remplie d’éléments motivateurs (des « clins d’œil », des aspects ludiques, des astuces de fonctionnement, etc.) qui ont été pensés pour me garder « accroché » dans votre intérêt, pas dans le mien (oui Zynga, c’est à toi que je pense)... Eh bien, là aussi vous épuisez mes ressources cognitives. Et que se passe-t-il quand je lâche l’écran pour aller dans la cuisine ?...

Votre application me fait grossir.

Si notre travail fait perdre à l’utilisateur ses ressources cognitives, qu’est-ce qu’il perd ? Qu’est-ce qu’il aurait pu faire d’autre avec ces ressources si rares, si précieuses, si vite disparues ? Peut-être qu’il avait dans l’idée de suivre bien sagement son régime. Ou de faire de la guitare. Ou de jouer avec ses enfants.

Dites-moi, ce nouvel élément que vous venez d’ajouter… Cet élément bling-bling, super-techno, ultra-cool… est-ce qu’il ne risque pas de coûter très cher à votre utilisateur ? Car si le résultat de votre travail appauvrit ses ressources cognitives, on ne peut plus employer ces ressources à d’autres usages beaucoup plus importants. Le problème ne réside pas dans le fait que vous accaparez le temps et l’attention de vos utilisateurs pendant qu’ils utilisent votre application. Il réside dans l’épuisement de leurs capacités de pensée logique, de résolution de problème et de maîtrise de soi après avoir cliqué, balayé ou touché un écran.

Bien entendu, ce n’est pas un mal en soi si votre travail épuise le réservoir de ressources d’un utilisateur. C’est peut-être justement dans votre application que votre utilisateur veut dépenser ces ressources. Mais dès lors que vous savez ce que coûte une interaction avec votre produit, vous allez peut-être faire des choix différents.

Vous allez peut-être réfléchir davantage à ce qui motive vraiment vos utilisateurs. Vous allez peut-être vous demander, à chaque réunion de design : « est-ce que cet élément nous pousse à choisir les fruits ou bien le gâteau ? » afin de limiter les éléments qui mènent au gâteau — ceux qui coûtent le plus — à ce pour quoi vos utilisateurs sont venus : utiliser votre application.

(Il est vrai que vous pouvez recharger vos ressources cognitives pendant la journée en fournissant des glucides à votre cerveau, mais allez-y doucement. Il vaut mieux prendre un en-cas protéiné avec de temps en temps quelques petites gorgées de boisson énergisante).

Mais quand bien même vous parvenez à justifier l’épuisement des ressources cognitives de vos utilisateurs pendant qu’ils utilisent votre produit, que dire alors de votre politique de marketing ? Croyez-vous sincèrement que votre « marketing de contenu » constitue un bon usage de leurs ressources ? « Oui, parce qu’on obtient de la valeur ajoutée », direz-vous. Mais qu’est-ce que ça veut vraiment dire ? Pouvez-vous honnêtement affirmer que « l’engagement envers une marque » constitue un usage sain et éthique de leurs maigres et précieuses ressources cognitives ? « Oui, parce que notre contenu est utile ».

Tout ça est bien beau, très « réseaux sociaux », très « 3.0 », tout ça, mais il y a quand même un petit problème : on est dans un jeu à somme nulle. Ce que je consommerai au point A, je ne l’aurai plus au point B. Et je n’aurai pas juste perdu de l’attention ou du temps, mais une capacité à être au meilleur de moi-même. C’est-à-dire lorsque je dispose de généreuses ressources cognitives. Lorsque je peux penser, résoudre des problèmes, et maintenir un bon contrôle de moi-même. Lorsque je sais créer, établir des liens et rester concentré.

Ce « contenu » en vaut-il la peine ? C’est possible. Mais au lieu de nous demander « est-ce que c’est vraiment utile ? », nous devrions sans doute aller plus loin et nous demander « est-ce qu’ils vont vraiment l’utiliser ? » (au fait, en écrivant ceci je suis bien conscient que je suis en train de puiser dans vos ressources cognitives. Mais après tout, je ne me suis pas lancé dans Serious Pony pour préserver vos ressources cognitives : je voudrais plutôt contribuer à épargner celles de vos utilisateurs).

Je n’ai rien contre le « marketing de contenu ». Bien au contraire, c’est pratiquement la seule forme de marketing-épuiseur-de-ressources qui puisse valoir le détour. C’est typiquement le genre de marketing qui peut pousser les gens à devenir plus compétents dans un domaine qui les intéresse. C’est le genre de marketing qui a la capacité de fournir aux utilisateurs un apprentissage — ce que la plupart des entreprises ignorent royalement. Le marketing de contenu peut (et doit) être « le guide qui vous manquait ». Il peut (et doit) représenter une source d’inspiration qui pousse nos utilisateurs à apprendre, à progresser (dans ce qui les intéresse) et à se connecter à d’autres utilisateurs.

Mais si on parle de « contenu » qui vise uniquement à attirer les passants (« Découvrez les 7 voies du succès ! ») en espérant les « convertir », on leur fait du mal. Si l’alibi pour leur balancer du « contenu », c’est la courbe de fréquence des visites, on leur fait du mal. Là, en ce moment, je vous fais du mal. Mea culpa. C’est pour ça que j’essaie d’utiliser des images pour souligner l’essentiel, pour vous éviter d’avoir à lire l’article (et aussi parce que j’ai un côté verbeux, oui je sais, j’y travaille…).

J’ai perdu mon père brutalement la semaine dernière ; et comme c’est souvent le cas quand un proche vient de mourir, je me suis dit : « Quand on est sur sur son lit de mort, on relativise beaucoup de choses. » Dans mon travail de ces 20 dernières années, j’ai créé des jeux de marketing interactif, des sites gamifiés (= conçus selon une approche plus ludique, NdT) et des dizaines d’autres projets qui étaient soigneusement, finement et scientifiquement conçus pour aspirer goulûment des ressources cognitives, mais… pour pas grand-chose d’important en fin de compte. Est-ce que mes visiteurs s’y laissaient attirer de façon volontaire ? Bien sûr que oui. Sauf que quand j’écris « bien sûr », je me dis : « pas si sûr... » Car c’est ce que nous apprend la recherche en psychologie, en neurosciences ou en économie comportementale de ces 50 dernières années. Mes visiteurs se faisaient aguicher, séduire, et finalement prendre au piège. Et j’étais très fort à ce petit jeu-là. Je suis vraiment, vraiment sincèrement désolé.

Avec Serious Pony, mon objectif est de donner à tous des pistes pour prendre mieux soin des utilisateurs. Pas seulement pendant qu’ils utilisent nos applications, nos sites ou nos produits, mais aussi après. Et pas seulement parce que ce sont nos utilisateurs, mais parce que ce sont d’abord des personnes.

Parce que quand ils seront sur leur lit de mort, nos utilisateurs ne vont certainement pas se dire : « Ah, si seulement j’avais consacré plus de temps à leurs marques !... »

Aidez-les à économiser et à bien gérer leurs ressources cognitives si maigres, si précieuses et si volatiles, pour qu’elles soient consacrées à ce qui est vraiment important. Important pour eux. Et puis, pensez à vos propres ressources. Pensez aux enfants. Pensez à Youki.

]]> http://www.pompage.net/traduction/votre-application-me-fait-grossir http://www.pompage.net/traduction/votre-application-me-fait-grossir Thu, 24 Jul 2014 10:07:00 +0200 <![CDATA[Votre application me fait grossir]]>

Par Kathy Sierra

L'expérience utilisateur vue à travers le prisme de la psychologie comportementale... attention à ne pas épuiser les ressources cognitives de vos visiteurs!

En 1999, le professeur Baba Shiv (qui enseigne aujourd’hui à Stanford) et son co-auteur Alex Fedorikhin ont mené une expérience simple sur 165 étudiants. Ils ont demandé à la moitié d’entre eux de mémoriser un nombre de sept chiffres, et à l’autre moitié de mémoriser un nombre de deux chiffres. Après cette tâche de mémorisation, on a dit aux participants que la tâche était terminée, et qu’ils pouvaient prendre un en-cas : au choix, du gâteau au chocolat ou de la salade de fruits.

Résultat ? Les participants qui devaient mémoriser le nombre de sept chiffres étaient 50 % plus attirés par le gâteau au chocolat que ne l’étaient les membres de l’autre groupe.

Les chercheurs, sidérés par les résultats convergents d’un grand nombre d’expériences, sont parvenus à cette étrange conclusion : le contrôle de soi et les processus cognitifs sont alimentés par la même réserve de ressources.

Vous passez des heures au boulot concentré sur un problème de design ? Vous aurez plus de chance de faire une petite halte chez McDo en rentrant chez vous. Vous vous retenez de dire ce que vous pensez vraiment pendant une réunion pénible et interminable ? Vous aurez plus de mal à coder plus tard dans la journée.

Car la volonté, le contrôle de soi et les tâches cognitives puisent dans les mêmes réserves. Si vous épuisez ces réserves à un moment donné, vous en paierez forcément le prix un peu plus tard. Il n’y a qu’une seule réserve. Une réserve de ressources rares, précieuses et très volatiles. Si vous passez votre journée à vous contrôler (face à des clients mécontents ou à des collègues incapables), vous rentrez chez vous le soir avec la jauge à zéro.

Le réservoir est vide. Et même si vous adorez vous frotter à des problèmes compliqués quand vous êtes au travail, cela n’empêche pas du tout que vos ressources soient diminuées. Il n’y a qu’une seule réserve. Qu’elle soit consommée par des activités que vous aimez ou que vous détestez n’y change rien. Le réservoir de ressources cognitives s’en fiche. Du coup, la moindre petite chose vous fait râler contre vos enfants ou votre chien. Ou bien c’est le chien qui vous grogne dessus.


Au cours d’une expérience, un premier groupe de chiens devait rester assis pendant quelques minutes sans rien faire, avant d’être autorisés à jouer avec leur jouet à croquettes « intelligent » (le genre de jouet où le chien doit fournir des efforts pour en extraire des croquettes). Les chiens de l’autre groupe restaient tranquilles dans leurs cages avant de recevoir leur jouet.

Vous imaginez peut-être déjà la suite : les chiens qu’on avait obligés à rester assis (et donc à être dans le contrôle de soi) ont abandonné beaucoup plus tôt leur jouet que ceux qui étaient restés tranquilles dans leurs cages. Les chiens qui n’avaient PAS dépensé de ressources cognitives en s’efforçant d’obéir montraient davantage de détermination et d’énergie mentale et émotionnelle pour résoudre le problème. Pensez-y la prochaine fois que vous demanderez à Youki de patienter un peu. Car ses ressources cognitives à lui s’épuisent tout aussi vite.

Réfléchissons maintenant à ce que nous faisons subir à nos utilisateurs. Si l’expérience utilisateur les oblige à faire des choix, et même si ces choix sont à la fois clairs et utiles, cet acte de décision diminue leurs ressources cognitives. Et pas uniquement au moment du choix… même après ce moment, ils continuent à consommer inconsciemment leurs ressources : « Ai-je fait le bon choix ? »

Si votre application est compliquée et si votre FAQ ou votre aide en ligne ne répond pas à mes besoins, vous faites baisser mon maigre niveau de ressources cognitives. Si votre application se comporte de façon contre-intuitive (même si ça n’arrive qu’une seule fois), je perdrai une partie de mes ressources à chaque nouvelle utilisation, parce que je me demanderai toujours : « Attends, est-ce que ça fait bien ce que je pensais ? »

Ou bien, imaginons que votre application soit vraiment hyper-facile à utiliser mais que dans son design et dans son fonctionnement elle soit remplie d’éléments motivateurs (des « clins d’œil », des aspects ludiques, des astuces de fonctionnement, etc.) qui ont été pensés pour me garder « accroché » dans votre intérêt, pas dans le mien (oui Zynga, c’est à toi que je pense)... Eh bien, là aussi vous épuisez mes ressources cognitives. Et que se passe-t-il quand je lâche l’écran pour aller dans la cuisine ?...

Votre application me fait grossir.

Si notre travail fait perdre à l’utilisateur ses ressources cognitives, qu’est-ce qu’il perd ? Qu’est-ce qu’il aurait pu faire d’autre avec ces ressources si rares, si précieuses, si vite disparues ? Peut-être qu’il avait dans l’idée de suivre bien sagement son régime. Ou de faire de la guitare. Ou de jouer avec ses enfants.

Dites-moi, ce nouvel élément que vous venez d’ajouter… Cet élément bling-bling, super-techno, ultra-cool… est-ce qu’il ne risque pas de coûter très cher à votre utilisateur ? Car si le résultat de votre travail appauvrit ses ressources cognitives, on ne peut plus employer ces ressources à d’autres usages beaucoup plus importants. Le problème ne réside pas dans le fait que vous accaparez le temps et l’attention de vos utilisateurs pendant qu’ils utilisent votre application. Il réside dans l’épuisement de leurs capacités de pensée logique, de résolution de problème et de maîtrise de soi après avoir cliqué, balayé ou touché un écran.

Bien entendu, ce n’est pas un mal en soi si votre travail épuise le réservoir de ressources d’un utilisateur. C’est peut-être justement dans votre application que votre utilisateur veut dépenser ces ressources. Mais dès lors que vous savez ce que coûte une interaction avec votre produit, vous allez peut-être faire des choix différents.

Vous allez peut-être réfléchir davantage à ce qui motive vraiment vos utilisateurs. Vous allez peut-être vous demander, à chaque réunion de design : « est-ce que cet élément nous pousse à choisir les fruits ou bien le gâteau ? » afin de limiter les éléments qui mènent au gâteau — ceux qui coûtent le plus — à ce pour quoi vos utilisateurs sont venus : utiliser votre application.

(Il est vrai que vous pouvez recharger vos ressources cognitives pendant la journée en fournissant des glucides à votre cerveau, mais allez-y doucement. Il vaut mieux prendre un en-cas protéiné avec de temps en temps quelques petites gorgées de boisson énergisante).

Mais quand bien même vous parvenez à justifier l’épuisement des ressources cognitives de vos utilisateurs pendant qu’ils utilisent votre produit, que dire alors de votre politique de marketing ? Croyez-vous sincèrement que votre « marketing de contenu » constitue un bon usage de leurs ressources ? « Oui, parce qu’on obtient de la valeur ajoutée », direz-vous. Mais qu’est-ce que ça veut vraiment dire ? Pouvez-vous honnêtement affirmer que « l’engagement envers une marque » constitue un usage sain et éthique de leurs maigres et précieuses ressources cognitives ? « Oui, parce que notre contenu est utile ».

Tout ça est bien beau, très « réseaux sociaux », très « 3.0 », tout ça, mais il y a quand même un petit problème : on est dans un jeu à somme nulle. Ce que je consommerai au point A, je ne l’aurai plus au point B. Et je n’aurai pas juste perdu de l’attention ou du temps, mais une capacité à être au meilleur de moi-même. C’est-à-dire lorsque je dispose de généreuses ressources cognitives. Lorsque je peux penser, résoudre des problèmes, et maintenir un bon contrôle de moi-même. Lorsque je sais créer, établir des liens et rester concentré.

Ce « contenu » en vaut-il la peine ? C’est possible. Mais au lieu de nous demander « est-ce que c’est vraiment utile ? », nous devrions sans doute aller plus loin et nous demander « est-ce qu’ils vont vraiment l’utiliser ? » (au fait, en écrivant ceci je suis bien conscient que je suis en train de puiser dans vos ressources cognitives. Mais après tout, je ne me suis pas lancé dans Serious Pony pour préserver vos ressources cognitives : je voudrais plutôt contribuer à épargner celles de vos utilisateurs).

Je n’ai rien contre le « marketing de contenu ». Bien au contraire, c’est pratiquement la seule forme de marketing-épuiseur-de-ressources qui puisse valoir le détour. C’est typiquement le genre de marketing qui peut pousser les gens à devenir plus compétents dans un domaine qui les intéresse. C’est le genre de marketing qui a la capacité de fournir aux utilisateurs un apprentissage — ce que la plupart des entreprises ignorent royalement. Le marketing de contenu peut (et doit) être « le guide qui vous manquait ». Il peut (et doit) représenter une source d’inspiration qui pousse nos utilisateurs à apprendre, à progresser (dans ce qui les intéresse) et à se connecter à d’autres utilisateurs.

Mais si on parle de « contenu » qui vise uniquement à attirer les passants (« Découvrez les 7 voies du succès ! ») en espérant les « convertir », on leur fait du mal. Si l’alibi pour leur balancer du « contenu », c’est la courbe de fréquence des visites, on leur fait du mal. Là, en ce moment, je vous fais du mal. Mea culpa. C’est pour ça que j’essaie d’utiliser des images pour souligner l’essentiel, pour vous éviter d’avoir à lire l’article (et aussi parce que j’ai un côté verbeux, oui je sais, j’y travaille…).

J’ai perdu mon père brutalement la semaine dernière ; et comme c’est souvent le cas quand un proche vient de mourir, je me suis dit : « Quand on est sur sur son lit de mort, on relativise beaucoup de choses. » Dans mon travail de ces 20 dernières années, j’ai créé des jeux de marketing interactif, des sites gamifiés (= conçus selon une approche plus ludique, NdT) et des dizaines d’autres projets qui étaient soigneusement, finement et scientifiquement conçus pour aspirer goulûment des ressources cognitives, mais… pour pas grand-chose d’important en fin de compte. Est-ce que mes visiteurs s’y laissaient attirer de façon volontaire ? Bien sûr que oui. Sauf que quand j’écris « bien sûr », je me dis : « pas si sûr... » Car c’est ce que nous apprend la recherche en psychologie, en neurosciences ou en économie comportementale de ces 50 dernières années. Mes visiteurs se faisaient aguicher, séduire, et finalement prendre au piège. Et j’étais très fort à ce petit jeu-là. Je suis vraiment, vraiment sincèrement désolé.

Avec Serious Pony, mon objectif est de donner à tous des pistes pour prendre mieux soin des utilisateurs. Pas seulement pendant qu’ils utilisent nos applications, nos sites ou nos produits, mais aussi après. Et pas seulement parce que ce sont nos utilisateurs, mais parce que ce sont d’abord des personnes.

Parce que quand ils seront sur leur lit de mort, nos utilisateurs ne vont certainement pas se dire : « Ah, si seulement j’avais consacré plus de temps à leurs marques !... »

Aidez-les à économiser et à bien gérer leurs ressources cognitives si maigres, si précieuses et si volatiles, pour qu’elles soient consacrées à ce qui est vraiment important. Important pour eux. Et puis, pensez à vos propres ressources. Pensez aux enfants. Pensez à Youki.

]]> http://www.pompage.net/traduction/votre-application-me-fait-grossir http://www.pompage.net/traduction/votre-application-me-fait-grossir Thu, 24 Jul 2014 10:07:00 +0200 <![CDATA[Votre application me fait grossir]]>

Par Kathy Sierra

L'expérience utilisateur vue à travers le prisme de la psychologie comportementale... attention à ne pas épuiser les ressources cognitives de vos visiteurs!

En 1999, le professeur Baba Shiv (qui enseigne aujourd’hui à Stanford) et son co-auteur Alex Fedorikhin ont mené une expérience simple sur 165 étudiants. Ils ont demandé à la moitié d’entre eux de mémoriser un nombre de sept chiffres, et à l’autre moitié de mémoriser un nombre de deux chiffres. Après cette tâche de mémorisation, on a dit aux participants que la tâche était terminée, et qu’ils pouvaient prendre un en-cas : au choix, du gâteau au chocolat ou de la salade de fruits.

Résultat ? Les participants qui devaient mémoriser le nombre de sept chiffres étaient 50 % plus attirés par le gâteau au chocolat que ne l’étaient les membres de l’autre groupe.

Les chercheurs, sidérés par les résultats convergents d’un grand nombre d’expériences, sont parvenus à cette étrange conclusion : le contrôle de soi et les processus cognitifs sont alimentés par la même réserve de ressources.

Vous passez des heures au boulot concentré sur un problème de design ? Vous aurez plus de chance de faire une petite halte chez McDo en rentrant chez vous. Vous vous retenez de dire ce que vous pensez vraiment pendant une réunion pénible et interminable ? Vous aurez plus de mal à coder plus tard dans la journée.

Car la volonté, le contrôle de soi et les tâches cognitives puisent dans les mêmes réserves. Si vous épuisez ces réserves à un moment donné, vous en paierez forcément le prix un peu plus tard. Il n’y a qu’une seule réserve. Une réserve de ressources rares, précieuses et très volatiles. Si vous passez votre journée à vous contrôler (face à des clients mécontents ou à des collègues incapables), vous rentrez chez vous le soir avec la jauge à zéro.

Le réservoir est vide. Et même si vous adorez vous frotter à des problèmes compliqués quand vous êtes au travail, cela n’empêche pas du tout que vos ressources soient diminuées. Il n’y a qu’une seule réserve. Qu’elle soit consommée par des activités que vous aimez ou que vous détestez n’y change rien. Le réservoir de ressources cognitives s’en fiche. Du coup, la moindre petite chose vous fait râler contre vos enfants ou votre chien. Ou bien c’est le chien qui vous grogne dessus.


Au cours d’une expérience, un premier groupe de chiens devait rester assis pendant quelques minutes sans rien faire, avant d’être autorisés à jouer avec leur jouet à croquettes « intelligent » (le genre de jouet où le chien doit fournir des efforts pour en extraire des croquettes). Les chiens de l’autre groupe restaient tranquilles dans leurs cages avant de recevoir leur jouet.

Vous imaginez peut-être déjà la suite : les chiens qu’on avait obligés à rester assis (et donc à être dans le contrôle de soi) ont abandonné beaucoup plus tôt leur jouet que ceux qui étaient restés tranquilles dans leurs cages. Les chiens qui n’avaient PAS dépensé de ressources cognitives en s’efforçant d’obéir montraient davantage de détermination et d’énergie mentale et émotionnelle pour résoudre le problème. Pensez-y la prochaine fois que vous demanderez à Youki de patienter un peu. Car ses ressources cognitives à lui s’épuisent tout aussi vite.

Réfléchissons maintenant à ce que nous faisons subir à nos utilisateurs. Si l’expérience utilisateur les oblige à faire des choix, et même si ces choix sont à la fois clairs et utiles, cet acte de décision diminue leurs ressources cognitives. Et pas uniquement au moment du choix… même après ce moment, ils continuent à consommer inconsciemment leurs ressources : « Ai-je fait le bon choix ? »

Si votre application est compliquée et si votre FAQ ou votre aide en ligne ne répond pas à mes besoins, vous faites baisser mon maigre niveau de ressources cognitives. Si votre application se comporte de façon contre-intuitive (même si ça n’arrive qu’une seule fois), je perdrai une partie de mes ressources à chaque nouvelle utilisation, parce que je me demanderai toujours : « Attends, est-ce que ça fait bien ce que je pensais ? »

Ou bien, imaginons que votre application soit vraiment hyper-facile à utiliser mais que dans son design et dans son fonctionnement elle soit remplie d’éléments motivateurs (des « clins d’œil », des aspects ludiques, des astuces de fonctionnement, etc.) qui ont été pensés pour me garder « accroché » dans votre intérêt, pas dans le mien (oui Zynga, c’est à toi que je pense)... Eh bien, là aussi vous épuisez mes ressources cognitives. Et que se passe-t-il quand je lâche l’écran pour aller dans la cuisine ?...

Votre application me fait grossir.

Si notre travail fait perdre à l’utilisateur ses ressources cognitives, qu’est-ce qu’il perd ? Qu’est-ce qu’il aurait pu faire d’autre avec ces ressources si rares, si précieuses, si vite disparues ? Peut-être qu’il avait dans l’idée de suivre bien sagement son régime. Ou de faire de la guitare. Ou de jouer avec ses enfants.

Dites-moi, ce nouvel élément que vous venez d’ajouter… Cet élément bling-bling, super-techno, ultra-cool… est-ce qu’il ne risque pas de coûter très cher à votre utilisateur ? Car si le résultat de votre travail appauvrit ses ressources cognitives, on ne peut plus employer ces ressources à d’autres usages beaucoup plus importants. Le problème ne réside pas dans le fait que vous accaparez le temps et l’attention de vos utilisateurs pendant qu’ils utilisent votre application. Il réside dans l’épuisement de leurs capacités de pensée logique, de résolution de problème et de maîtrise de soi après avoir cliqué, balayé ou touché un écran.

Bien entendu, ce n’est pas un mal en soi si votre travail épuise le réservoir de ressources d’un utilisateur. C’est peut-être justement dans votre application que votre utilisateur veut dépenser ces ressources. Mais dès lors que vous savez ce que coûte une interaction avec votre produit, vous allez peut-être faire des choix différents.

Vous allez peut-être réfléchir davantage à ce qui motive vraiment vos utilisateurs. Vous allez peut-être vous demander, à chaque réunion de design : « est-ce que cet élément nous pousse à choisir les fruits ou bien le gâteau ? » afin de limiter les éléments qui mènent au gâteau — ceux qui coûtent le plus — à ce pour quoi vos utilisateurs sont venus : utiliser votre application.

(Il est vrai que vous pouvez recharger vos ressources cognitives pendant la journée en fournissant des glucides à votre cerveau, mais allez-y doucement. Il vaut mieux prendre un en-cas protéiné avec de temps en temps quelques petites gorgées de boisson énergisante).

Mais quand bien même vous parvenez à justifier l’épuisement des ressources cognitives de vos utilisateurs pendant qu’ils utilisent votre produit, que dire alors de votre politique de marketing ? Croyez-vous sincèrement que votre « marketing de contenu » constitue un bon usage de leurs ressources ? « Oui, parce qu’on obtient de la valeur ajoutée », direz-vous. Mais qu’est-ce que ça veut vraiment dire ? Pouvez-vous honnêtement affirmer que « l’engagement envers une marque » constitue un usage sain et éthique de leurs maigres et précieuses ressources cognitives ? « Oui, parce que notre contenu est utile ».

Tout ça est bien beau, très « réseaux sociaux », très « 3.0 », tout ça, mais il y a quand même un petit problème : on est dans un jeu à somme nulle. Ce que je consommerai au point A, je ne l’aurai plus au point B. Et je n’aurai pas juste perdu de l’attention ou du temps, mais une capacité à être au meilleur de moi-même. C’est-à-dire lorsque je dispose de généreuses ressources cognitives. Lorsque je peux penser, résoudre des problèmes, et maintenir un bon contrôle de moi-même. Lorsque je sais créer, établir des liens et rester concentré.

Ce « contenu » en vaut-il la peine ? C’est possible. Mais au lieu de nous demander « est-ce que c’est vraiment utile ? », nous devrions sans doute aller plus loin et nous demander « est-ce qu’ils vont vraiment l’utiliser ? » (au fait, en écrivant ceci je suis bien conscient que je suis en train de puiser dans vos ressources cognitives. Mais après tout, je ne me suis pas lancé dans Serious Pony pour préserver vos ressources cognitives : je voudrais plutôt contribuer à épargner celles de vos utilisateurs).

Je n’ai rien contre le « marketing de contenu ». Bien au contraire, c’est pratiquement la seule forme de marketing-épuiseur-de-ressources qui puisse valoir le détour. C’est typiquement le genre de marketing qui peut pousser les gens à devenir plus compétents dans un domaine qui les intéresse. C’est le genre de marketing qui a la capacité de fournir aux utilisateurs un apprentissage — ce que la plupart des entreprises ignorent royalement. Le marketing de contenu peut (et doit) être « le guide qui vous manquait ». Il peut (et doit) représenter une source d’inspiration qui pousse nos utilisateurs à apprendre, à progresser (dans ce qui les intéresse) et à se connecter à d’autres utilisateurs.

Mais si on parle de « contenu » qui vise uniquement à attirer les passants (« Découvrez les 7 voies du succès ! ») en espérant les « convertir », on leur fait du mal. Si l’alibi pour leur balancer du « contenu », c’est la courbe de fréquence des visites, on leur fait du mal. Là, en ce moment, je vous fais du mal. Mea culpa. C’est pour ça que j’essaie d’utiliser des images pour souligner l’essentiel, pour vous éviter d’avoir à lire l’article (et aussi parce que j’ai un côté verbeux, oui je sais, j’y travaille…).

J’ai perdu mon père brutalement la semaine dernière ; et comme c’est souvent le cas quand un proche vient de mourir, je me suis dit : « Quand on est sur sur son lit de mort, on relativise beaucoup de choses. » Dans mon travail de ces 20 dernières années, j’ai créé des jeux de marketing interactif, des sites gamifiés (= conçus selon une approche plus ludique, NdT) et des dizaines d’autres projets qui étaient soigneusement, finement et scientifiquement conçus pour aspirer goulûment des ressources cognitives, mais… pour pas grand-chose d’important en fin de compte. Est-ce que mes visiteurs s’y laissaient attirer de façon volontaire ? Bien sûr que oui. Sauf que quand j’écris « bien sûr », je me dis : « pas si sûr... » Car c’est ce que nous apprend la recherche en psychologie, en neurosciences ou en économie comportementale de ces 50 dernières années. Mes visiteurs se faisaient aguicher, séduire, et finalement prendre au piège. Et j’étais très fort à ce petit jeu-là. Je suis vraiment, vraiment sincèrement désolé.

Avec Serious Pony, mon objectif est de donner à tous des pistes pour prendre mieux soin des utilisateurs. Pas seulement pendant qu’ils utilisent nos applications, nos sites ou nos produits, mais aussi après. Et pas seulement parce que ce sont nos utilisateurs, mais parce que ce sont d’abord des personnes.

Parce que quand ils seront sur leur lit de mort, nos utilisateurs ne vont certainement pas se dire : « Ah, si seulement j’avais consacré plus de temps à leurs marques !... »

Aidez-les à économiser et à bien gérer leurs ressources cognitives si maigres, si précieuses et si volatiles, pour qu’elles soient consacrées à ce qui est vraiment important. Important pour eux. Et puis, pensez à vos propres ressources. Pensez aux enfants. Pensez à Youki.

]]> https://www.pompage.net/traduction/votre-application-me-fait-grossir https://www.pompage.net/traduction/votre-application-me-fait-grossir Thu, 24 Jul 2014 10:07:00 +0200 <![CDATA[Traduit ailleurs : Continuum]]>

Jeremy Keith, dans la continuité du célèbre Tao du Webdesign, défend l'idée du web comme un continuum - un espace ouvert à l'expérimentation, soucieux d'accessibilité au contenu. Engagé, constructif, définitif.

Par Jeremy Keith

Arrêtez-moi si vous l’avez déjà entendue : vous lisez un article sur Smashing Magazine ou A List Apart ou autre, l’article traite d’une fonctionnalité spécifique de CSS, ou peut-être de JavaScript, ou explore une nouveauté de HTML. L’article est bon. Il explique comment utiliser cette nouvelle fonctionnalité dans votre travail. Puis vous lisez les commentaires. Le premier d’entre eux est invariablement écrit par un lecteur qui se plaint de ne pouvoir utiliser cette fonction à cause des problèmes d’incompatibilité navigateurs. Plus précisément, sur de vieilles versions d’Internet Explorer, qu’il est obligé de servir. En conséquence de quoi, l’article est déclaré nul et non avenu.

Cette attitude m’irrite et me déprime au plus haut point. Elle me semble démontrer un décalage fondamental entre la façon dont cette personne considère le métier de développeur web et la réalité du web.

Il est tout à fait possible — non : souhaitable — d’utiliser ces fonctionnalités bien avant qu’elles ne soient supportées par tous les navigateurs. C’est ainsi que nous faisons avancer le web. Si nous avions attendu une compatibilité universelle, nous en serions encore à CSS 1.0 et HTML 2.0.

Si vous utilisez une fonctionnalité CSS qui n’est pas compatible avec tel ou tel navigateur —  par exemple avec une version ancienne d’IE — ce navigateur ignorera purement et simplement cette règle CSS. Donc vous n’aurez pas ce coin arrondi, cette ombre sous le texte... Les navigateurs traitent les erreurs de la même façon pour HTML : s’ils voient quelque chose qu’ils ne comprennent pas, ils l’ignorent. Le navigateur n’enverra pas d’erreur, il n’arrêtera pas le processus de rendu de page. Les navigateurs sont très souples.

C’est un peu plus compliqué avec JavaScript : les navigateurs retourneront une erreur, ils bloqueront le script. C’est pourquoi il est important d’utiliser la détection de fonctionnalité. C’est pourquoi aussi il est si important de ne pas s’en remettre à JavaScript pour le rendu de votre contenu — c’est la couche la plus fragile dans l’empilement front-end. Bon, je n’ai pas dit qu’il ne fallait pas utiliser JavaScript, je dis juste qu’il ne faut pas trop s’appuyer sur lui, sinon vous pourriez avoir affaire à un SPOF (Single Point of Failure, un point individuel de défaillance).

Ce qu’il est important de garder à l’esprit — et j’ai du mal à croire qu’on doive encore le répéter après tant d’années — c’est que les sites web n’ont pas besoin d’être identiques d’un navigateur à l’autre.

“Mais mon client !” crie le commentateur de Smashing Magazine, “Mais mon patron !” dit un autre...

Si votre client ou votre patron s’attend à ce qu’un site web ait le même look et le même comportement sur chaque terminal, d’où lui viennent ces idées ? Plutôt que de perdre votre temps à tenter de satisfaire ces attentes, vous l’utiliseriez mieux à expliquer à vos interlocuteurs pourquoi ces choses-là sont impossibles dans la réalité du web actuel.

Comme le dit Mike Monteiro à propos des clients : S’ils ne comprennent pas quelque chose dans votre design, ce n’est pas leur faute, c’est la vôtre. Expliquer votre design fait partie intégrante de votre métier de designer. Idem pour le développement web, c’est notre métier d’expliquer comment ça marche... et comment la répartition déséquilibrée des capacités des navigateurs n’est pas un bug, c’est une caractéristique objective et incontournable.

Il y a déjà 14 ans que John Allsopp a écrit le Tao du webdesign, et son texte est toujours actuel. À l’époque, les designers et les développeurs comparaient le web au monde de l’imprimerie, et pensaient qu’il lui était inférieur. Aujourd’hui, ils le comparent au monde des applications natives et lui trouvent encore des manques. Dans les deux cas, mon sentiment est qu’ils passent à côté du point fondamental du web : vous pouvez fournir un accès universel au contenu et aux tâches sans nécessairement fournir la même expérience à chaque navigateur ou à chaque terminal.

Paul Kinlan a publié un article intitulé “Ce qu’est la plateforme web” dans lequel il met sous forme de tableau l’état actuel des compatibilités navigateurs pour un certain nombre de fonctionnalités. “Assez accablant” selon lui :

la compatibilité omniprésente sur le web est en réalité assez restreinte dès lors qu’on doit supporter IE8.

C’est vrai... d’un certain point de vue. Mais cela dépend de votre définition de la “compatibilité”. Si elle signifie “avoir le même look et les mêmes fonctions que dans la dernière version de Chrome”, alors oui, vous aurez un ensemble de fonctionnalités plus réduit (et vous aurez également une existence plus misérable). Mais si votre définition de la compatibilité est “être capable d’accéder au contenu et d’accomplir les tâches”, alors tant que vous faites appel à l’amélioration progressive vous pourrez utiliser toutes les fonctionnalités que vous voulez et supporter IE 8, 7, 6, 5... vous pouvez supporter n’importe quel navigateur capable de se connecter à internet.

Comme le dit Brad Frost :

Il y a une différence entre la compatibilité et l’optimisation.

Une partie du problème vient probablement d’incompréhensions langagières. Nous parlons “du navigateur” quand nous devrions dire “les navigateurs”. Je suis coupable moi-même. J’utilise des expressions telles que “design dans le navigateur”, je parle de “ce qu’il est possible de faire dans le navigateur”...

C’est une petite subtilité Lakoffienne, mais lorsque nous parlons “du navigateur” comme s’il s’agissait d’une entité unique, nous sommes peut-être en train de renforcer cette attente d’un idéal platonicien de rendu navigateur unique pour lequel nous voulons réaliser nos designs.

Il y a encore une phrase qui me gêne, c’est celle que Paul utilise dans son article précédemment cité. J’en ai parlé en novembre dernier dans ma présentation sur le pouvoir de la simplicité :

Cette idée du web comme une plateforme, je la comprends bien d’un point de vue marketing, et nous pourrions vouloir utiliser cette phrase pour mettre sur un pied d’égalité le web et les plateformes véritables. Je dirais que Flash est une plateforme, et le monde natif : iOS, Android et toutes ces sortes de choses. Ce sont des plateformes, en ce sens que ce sont des suites logicielles, mais le web n’est pas comme cela. Si vous utilisez la plateforme Flash, toute personne qui a le plug-in Flash peut accéder à votre contenu. C’est on/off, un ou zéro, binaire. Ou bien ils ont la plateforme, ou bien ils ne l’ont pas. Ou bien ils peuvent accéder à votre contenu ou bien ils ne peuvent pas. Même chose avec les applis natives. Si vous avez le bon téléphone, vous pouvez avoir mon appli. Toute mon appli. Pas juste une partie, non, mon appli tout entière. Ou rien du tout parce que vous n’avez pas le téléphone compatible.

Mais le web n’est pas ainsi. Le web n’est pas binaire, un ou zéro, on/off. Ce n’est pas une plateforme où vous avez 100% ou 0%. C’est un continuum.

]]> https://la-cascade.io/continuum/ https://la-cascade.io/continuum/ Fri, 11 Jul 2014 06:07:00 +0200 <![CDATA[D'abord la structure. Le contenu suivra.]]>

Par Mark Boulton

Il faut bien commencer quelque part. On ne peut pas partir de rien.

En 2001, j’ai commencé à travailler pour la BBC à Cardiff. Quatre années durant j’ai travaillé aux côtés de journalistes et de chefs de projets sur toutes sortes de sites web et applications, du petit site de contenu de niche sur le surf jusqu’à la refonte de la page d’accueil. Tout ces projets furent abordés selon l’approche "Contenu en premier" (mais pas tel que défini par Jeremy Keith), mais nous n’avons jamais eu le contenu en premier.

J’ai travaillé avec de nombreux médias ces dix dernières années. J’ai beaucoup appris sur de nombreux processus éditoriaux à travers trois médias : la télévision, les journaux, et le web (et même un petit peu de radio). Je me réjouis des points communs entre eux et me tords de douleur en constatant les différentes manières de faire pour chacun d’eux, tant dans les organisations elles-mêmes que dans ce qu’elles produisent. Certaines choses ont été directement transposées sur le web avec succès ; d’autres ont été des échecs. Comme de fabriquer des sites web en singeant les CD-Roms, par exemple. Vous vous souvenez de cette époque ?

Le modèle que nous avons emprunté à l’impression papier pour l’appliquer aux premiers temps du Web — le modèle de page et le système de publication — est maintenant en danger. Il est menacé par le postulat qu’il faudrait avoir connaissance du contenu avant de lancer la conception. Quiconque a déjà travaillé dans l’édition, créé un concept de marque à grande échelle ou un système d’orientation sait parfaitement que c’est un non-sens. Nous n’avons pas besoin de donner la priorité au contenu, mais à la structure. Le contenu quand à lui est toujours essentiel.

Soyons clair à ce propos. Il est illusoire de vouloir écrire votre contenu — ou de demander à votre client de l’écrire — avant de concevoir la structure. Du moins en général. Le contenu a besoin d’être structuré et la structure modifie votre contenu, tout comme concevoir modifie le contenu. Ce n’est donc pas « contenu puis conception », ou « contenu ou conception » ; c’est « contenu et conception ».

Concevoir la maquette d’un magazine ou d’un journal papier nécessite d’imposer des contraintes rigoureuses aux multiples types de contenu. Vous devez définir, en étroite collaboration avec l’équipe éditoriale, les catégories de contenu que vous devrez accommoder. Le gabarit d’un article d’information, d’un éditorial ou d’un dossier nécessite un traitement visuel différent pour indiquer aux lecteurs que le contenu n’est pas de même type. Les variations de mise en forme doivent être assez limitées, d’ailleurs. Pourquoi ? Eh bien, surtout à cause du facteur temps. Journaux et magazines subissent d’énormes contraintes de temps, et le contenu est littéralement déversé dans un moule préfabriqué — on peut retoucher ou ajuster à la marge, mais les maquettes et gabarits ne laissent pratiquement aucune liberté. Et ce n’est pas une mauvaise pratique, c’est ainsi que les contenus vivent et respirent dans un environnement à forte cadence éditoriale. La fluidité est privilégiée. Tout cela ne peut pas être figé en amont. La priorité au contenu ne marcherait pas dans ce cas précis.

Le contenu comme structure

Nous avons vu récemment l’émergence d’un raisonnement fallacieux dans notre domaine. L’idée qu’il n’est pas possible de créer une conception convenable sans avoir connaissance du contenu. Je l’ai dit moi-même il y a quelque temps. Mais ce n’est qu’à moitié vrai. Les journaux, les magazines et de nombreux autres périodiques et publications issus de différents médias démontrent quotidiennement que cette théorie ne tient pas.

Vous pouvez mettre en place une bonne expérience utilisateur sans avoir connaissance du contenu. Ce que vous ne pouvez pas faire, c’est mettre en place une bonne expérience utilisateur sans connaître la structure de votre contenu. La question n’est pas de savoir ce qu’est ce contenu, mais de comment il est constitué. Et c’est une différence de taille.

Il faut donc commencer par la structure, pas par les mots. Qu’est-ce qu’un « article d’opinion » ? Quels sont les variables à prendre en compte ? Peut-on même les définir ? Y aura-t-il des images ? Combien ? (La réponse est toujours la même : « Je ne sais pas, ça dépend ! »). Nous pouvons concevoir en privilégiant la fluidité, mais cela signifie une perte de contrôle. Encore. Comment faire, alors ? Comment concevoir en privilégiant la fluidité ? Eh bien, nous définissons la structure de notre contenu et les gabarits qu’il occupera. Nous définissons les règles du système pour qu’il affiche le contenu de différentes manières (si possible) pour aider le lecteur à mieux comprendre le contenu.

Comme le dit Erik Spiekermann : « on donne de la forme au contenu ».

Les concepteurs en tant que directeurs de contenu

Les designers ont toujours été impliqués par le contenu. Nous ne nous arrêtons pas à l’aspect visuel. Mais comment le faire comprendre à nos clients à comprendre lorsque nous disons :

« Le contenu d’abord ! »

Ce n’est pas pour dire :

« Je vais rester assis ici sans bouger jusqu’à ce que vous me donniez le contenu. Je dis bien le contenu finalisé, validé, paraphé, signé. Merci, j’attends »

Non, bien sûr. Il faut plutôt comprendre :

« Nous aimerions bien comprendre le type et la structure des contenus pour ce projet. Ne vous inquiétez pas, vous n’êtes pas obligé de commencer à l’écrire, aidez-nous seulement à comprendre. »

Nous pouvons faire cela de nombreuses manières mais récemment, j’ai remarqué que ces grands principes fonctionnaient bien pour moi :

  1. Parler. Et utiliser des Post-It. Installez-vous dans une pièce (fermée à clef de préférence) et discutez du site web ou de l’application. Pas du contenu pour le moment. Pendant que vous êtes en train de parler, écrivez les mots qui résonnent à votre oreille. Après avoir discuté, accrochez ces mots sur un mur et commencez à les connecter entre eux. Nos confrères de l’expérience utilisateur ont sûrement un nom qui claque pour qualifier cet exercice, mais je ne le connais pas.
  2. Accepter le désordre. Vous devriez vous retrouver avec tout un tas de mots vaguement reliés entre eux (ce n’est toujours pas du contenu) à propos de différents sujets. Ces sujets sont l’ADN de votre site. L’attitude, le ton, la marque, le message, ainsi que les points de détail tels que les différents types de contenu, taxonomies, mots-clés et autres aspects techniques. Maintenant, il faut ordonner tout cela.
  3. Itérer. À un moment pendant le tri, vous aurez besoin de commencer à dégager la structure. Là aussi, j’ai constaté qu’effectuer cette étape de manière itérative et à plusieurs est plus fructueux.
  4. Structurer. Vous devriez maintenant avoir un début de structure. À l’étape 3, il y a sûrement un moment où votre client (ou vous-même) dira en désignant un terme noté sur un Post-it : « Oui, mais qu’est-ce que c’est que ça ? » Dessinez la structure sur un papier et qualifiez-la par un mot. C’est là que vous allez entrer dans le détail et tâcher de donner du corps à cette idée. C’est ce qui définit la structure de votre contenu. Et ce n’est pas terminé.
  5. Prévoir. Utilisez un tableau de contenu. En gros, c’est comme un tableur pour vos contenus. Remplissez-le, je vous conseille celui de Relly, il est excellent. Cet outil peut vraiment aider vos clients plus tard quand arrive l’étape « Oh mon dieu, j’ai tellement de contenu à écrire et je ne sais pas par où commencer ». Cela permet de se concentrer sur ce qui compte.

Arrêtons de cloisonner le contenu. Nous avons déjà fait cette erreur à l’époque où le web imitait les brochures imprimées ; l’approche « Contenu en premier » ne fait que déplacer le problème à l’autre bout du processus. Concentrons-nous donc sur la structure pour commencer, mais en gardant le contenu à l’esprit tout du long. La relation contenu-mise en forme est quasi symbiotique : ni l’un ni l’autre ne peut exister isolément.

Commençons par la structure. Et découvrons de quoi le contenu est fait, plutôt que de nous inquiéter de ce qu’il est.

Voici la liste des dix articles les plus récents en rapport avec cet article :

]]> http://www.pompage.net/traduction/structure-d-abord-le-contenu-suivra http://www.pompage.net/traduction/structure-d-abord-le-contenu-suivra Tue, 08 Jul 2014 10:07:00 +0200 <![CDATA[D'abord la structure. Le contenu suivra.]]>

Par Mark Boulton

Il faut bien commencer quelque part. On ne peut pas partir de rien.

En 2001, j’ai commencé à travailler pour la BBC à Cardiff. Quatre années durant j’ai travaillé aux côtés de journalistes et de chefs de projets sur toutes sortes de sites web et applications, du petit site de contenu de niche sur le surf jusqu’à la refonte de la page d’accueil. Tout ces projets furent abordés selon l’approche "Contenu en premier" (mais pas tel que défini par Jeremy Keith), mais nous n’avons jamais eu le contenu en premier.

J’ai travaillé avec de nombreux médias ces dix dernières années. J’ai beaucoup appris sur de nombreux processus éditoriaux à travers trois médias : la télévision, les journaux, et le web (et même un petit peu de radio). Je me réjouis des points communs entre eux et me tords de douleur en constatant les différentes manières de faire pour chacun d’eux, tant dans les organisations elles-mêmes que dans ce qu’elles produisent. Certaines choses ont été directement transposées sur le web avec succès ; d’autres ont été des échecs. Comme de fabriquer des sites web en singeant les CD-Roms, par exemple. Vous vous souvenez de cette époque ?

Le modèle que nous avons emprunté à l’impression papier pour l’appliquer aux premiers temps du Web — le modèle de page et le système de publication — est maintenant en danger. Il est menacé par le postulat qu’il faudrait avoir connaissance du contenu avant de lancer la conception. Quiconque a déjà travaillé dans l’édition, créé un concept de marque à grande échelle ou un système d’orientation sait parfaitement que c’est un non-sens. Nous n’avons pas besoin de donner la priorité au contenu, mais à la structure. Le contenu quand à lui est toujours essentiel.

Soyons clair à ce propos. Il est illusoire de vouloir écrire votre contenu — ou de demander à votre client de l’écrire — avant de concevoir la structure. Du moins en général. Le contenu a besoin d’être structuré et la structure modifie votre contenu, tout comme concevoir modifie le contenu. Ce n’est donc pas « contenu puis conception », ou « contenu ou conception » ; c’est « contenu et conception ».

Concevoir la maquette d’un magazine ou d’un journal papier nécessite d’imposer des contraintes rigoureuses aux multiples types de contenu. Vous devez définir, en étroite collaboration avec l’équipe éditoriale, les catégories de contenu que vous devrez accommoder. Le gabarit d’un article d’information, d’un éditorial ou d’un dossier nécessite un traitement visuel différent pour indiquer aux lecteurs que le contenu n’est pas de même type. Les variations de mise en forme doivent être assez limitées, d’ailleurs. Pourquoi ? Eh bien, surtout à cause du facteur temps. Journaux et magazines subissent d’énormes contraintes de temps, et le contenu est littéralement déversé dans un moule préfabriqué — on peut retoucher ou ajuster à la marge, mais les maquettes et gabarits ne laissent pratiquement aucune liberté. Et ce n’est pas une mauvaise pratique, c’est ainsi que les contenus vivent et respirent dans un environnement à forte cadence éditoriale. La fluidité est privilégiée. Tout cela ne peut pas être figé en amont. La priorité au contenu ne marcherait pas dans ce cas précis.

Le contenu comme structure

Nous avons vu récemment l’émergence d’un raisonnement fallacieux dans notre domaine. L’idée qu’il n’est pas possible de créer une conception convenable sans avoir connaissance du contenu. Je l’ai dit moi-même il y a quelque temps. Mais ce n’est qu’à moitié vrai. Les journaux, les magazines et de nombreux autres périodiques et publications issus de différents médias démontrent quotidiennement que cette théorie ne tient pas.

Vous pouvez mettre en place une bonne expérience utilisateur sans avoir connaissance du contenu. Ce que vous ne pouvez pas faire, c’est mettre en place une bonne expérience utilisateur sans connaître la structure de votre contenu. La question n’est pas de savoir ce qu’est ce contenu, mais de comment il est constitué. Et c’est une différence de taille.

Il faut donc commencer par la structure, pas par les mots. Qu’est-ce qu’un « article d’opinion » ? Quels sont les variables à prendre en compte ? Peut-on même les définir ? Y aura-t-il des images ? Combien ? (La réponse est toujours la même : « Je ne sais pas, ça dépend ! »). Nous pouvons concevoir en privilégiant la fluidité, mais cela signifie une perte de contrôle. Encore. Comment faire, alors ? Comment concevoir en privilégiant la fluidité ? Eh bien, nous définissons la structure de notre contenu et les gabarits qu’il occupera. Nous définissons les règles du système pour qu’il affiche le contenu de différentes manières (si possible) pour aider le lecteur à mieux comprendre le contenu.

Comme le dit Erik Spiekermann : « on donne de la forme au contenu ».

Les concepteurs en tant que directeurs de contenu

Les designers ont toujours été impliqués par le contenu. Nous ne nous arrêtons pas à l’aspect visuel. Mais comment le faire comprendre à nos clients à comprendre lorsque nous disons :

« Le contenu d’abord ! »

Ce n’est pas pour dire :

« Je vais rester assis ici sans bouger jusqu’à ce que vous me donniez le contenu. Je dis bien le contenu finalisé, validé, paraphé, signé. Merci, j’attends »

Non, bien sûr. Il faut plutôt comprendre :

« Nous aimerions bien comprendre le type et la structure des contenus pour ce projet. Ne vous inquiétez pas, vous n’êtes pas obligé de commencer à l’écrire, aidez-nous seulement à comprendre. »

Nous pouvons faire cela de nombreuses manières mais récemment, j’ai remarqué que ces grands principes fonctionnaient bien pour moi :

  1. Parler. Et utiliser des Post-It. Installez-vous dans une pièce (fermée à clef de préférence) et discutez du site web ou de l’application. Pas du contenu pour le moment. Pendant que vous êtes en train de parler, écrivez les mots qui résonnent à votre oreille. Après avoir discuté, accrochez ces mots sur un mur et commencez à les connecter entre eux. Nos confrères de l’expérience utilisateur ont sûrement un nom qui claque pour qualifier cet exercice, mais je ne le connais pas.
  2. Accepter le désordre. Vous devriez vous retrouver avec tout un tas de mots vaguement reliés entre eux (ce n’est toujours pas du contenu) à propos de différents sujets. Ces sujets sont l’ADN de votre site. L’attitude, le ton, la marque, le message, ainsi que les points de détail tels que les différents types de contenu, taxonomies, mots-clés et autres aspects techniques. Maintenant, il faut ordonner tout cela.
  3. Itérer. À un moment pendant le tri, vous aurez besoin de commencer à dégager la structure. Là aussi, j’ai constaté qu’effectuer cette étape de manière itérative et à plusieurs est plus fructueux.
  4. Structurer. Vous devriez maintenant avoir un début de structure. À l’étape 3, il y a sûrement un moment où votre client (ou vous-même) dira en désignant un terme noté sur un Post-it : « Oui, mais qu’est-ce que c’est que ça ? » Dessinez la structure sur un papier et qualifiez-la par un mot. C’est là que vous allez entrer dans le détail et tâcher de donner du corps à cette idée. C’est ce qui définit la structure de votre contenu. Et ce n’est pas terminé.
  5. Prévoir. Utilisez un tableau de contenu. En gros, c’est comme un tableur pour vos contenus. Remplissez-le, je vous conseille celui de Relly, il est excellent. Cet outil peut vraiment aider vos clients plus tard quand arrive l’étape « Oh mon dieu, j’ai tellement de contenu à écrire et je ne sais pas par où commencer ». Cela permet de se concentrer sur ce qui compte.

Arrêtons de cloisonner le contenu. Nous avons déjà fait cette erreur à l’époque où le web imitait les brochures imprimées ; l’approche « Contenu en premier » ne fait que déplacer le problème à l’autre bout du processus. Concentrons-nous donc sur la structure pour commencer, mais en gardant le contenu à l’esprit tout du long. La relation contenu-mise en forme est quasi symbiotique : ni l’un ni l’autre ne peut exister isolément.

Commençons par la structure. Et découvrons de quoi le contenu est fait, plutôt que de nous inquiéter de ce qu’il est.

Voici la liste des dix articles les plus récents en rapport avec cet article :

]]> http://www.pompage.net/traduction/structure-d-abord-le-contenu-suivra http://www.pompage.net/traduction/structure-d-abord-le-contenu-suivra Tue, 08 Jul 2014 10:07:00 +0200 <![CDATA[D'abord la structure. Le contenu suivra.]]>

Par Mark Boulton

Il faut bien commencer quelque part. On ne peut pas partir de rien.

En 2001, j’ai commencé à travailler pour la BBC à Cardiff. Quatre années durant j’ai travaillé aux côtés de journalistes et de chefs de projets sur toutes sortes de sites web et applications, du petit site de contenu de niche sur le surf jusqu’à la refonte de la page d’accueil. Tout ces projets furent abordés selon l’approche "Contenu en premier" (mais pas tel que défini par Jeremy Keith), mais nous n’avons jamais eu le contenu en premier.

J’ai travaillé avec de nombreux médias ces dix dernières années. J’ai beaucoup appris sur de nombreux processus éditoriaux à travers trois médias : la télévision, les journaux, et le web (et même un petit peu de radio). Je me réjouis des points communs entre eux et me tords de douleur en constatant les différentes manières de faire pour chacun d’eux, tant dans les organisations elles-mêmes que dans ce qu’elles produisent. Certaines choses ont été directement transposées sur le web avec succès ; d’autres ont été des échecs. Comme de fabriquer des sites web en singeant les CD-Roms, par exemple. Vous vous souvenez de cette époque ?

Le modèle que nous avons emprunté à l’impression papier pour l’appliquer aux premiers temps du Web — le modèle de page et le système de publication — est maintenant en danger. Il est menacé par le postulat qu’il faudrait avoir connaissance du contenu avant de lancer la conception. Quiconque a déjà travaillé dans l’édition, créé un concept de marque à grande échelle ou un système d’orientation sait parfaitement que c’est un non-sens. Nous n’avons pas besoin de donner la priorité au contenu, mais à la structure. Le contenu quand à lui est toujours essentiel.

Soyons clair à ce propos. Il est illusoire de vouloir écrire votre contenu — ou de demander à votre client de l’écrire — avant de concevoir la structure. Du moins en général. Le contenu a besoin d’être structuré et la structure modifie votre contenu, tout comme concevoir modifie le contenu. Ce n’est donc pas « contenu puis conception », ou « contenu ou conception » ; c’est « contenu et conception ».

Concevoir la maquette d’un magazine ou d’un journal papier nécessite d’imposer des contraintes rigoureuses aux multiples types de contenu. Vous devez définir, en étroite collaboration avec l’équipe éditoriale, les catégories de contenu que vous devrez accommoder. Le gabarit d’un article d’information, d’un éditorial ou d’un dossier nécessite un traitement visuel différent pour indiquer aux lecteurs que le contenu n’est pas de même type. Les variations de mise en forme doivent être assez limitées, d’ailleurs. Pourquoi ? Eh bien, surtout à cause du facteur temps. Journaux et magazines subissent d’énormes contraintes de temps, et le contenu est littéralement déversé dans un moule préfabriqué — on peut retoucher ou ajuster à la marge, mais les maquettes et gabarits ne laissent pratiquement aucune liberté. Et ce n’est pas une mauvaise pratique, c’est ainsi que les contenus vivent et respirent dans un environnement à forte cadence éditoriale. La fluidité est privilégiée. Tout cela ne peut pas être figé en amont. La priorité au contenu ne marcherait pas dans ce cas précis.

Le contenu comme structure

Nous avons vu récemment l’émergence d’un raisonnement fallacieux dans notre domaine. L’idée qu’il n’est pas possible de créer une conception convenable sans avoir connaissance du contenu. Je l’ai dit moi-même il y a quelque temps. Mais ce n’est qu’à moitié vrai. Les journaux, les magazines et de nombreux autres périodiques et publications issus de différents médias démontrent quotidiennement que cette théorie ne tient pas.

Vous pouvez mettre en place une bonne expérience utilisateur sans avoir connaissance du contenu. Ce que vous ne pouvez pas faire, c’est mettre en place une bonne expérience utilisateur sans connaître la structure de votre contenu. La question n’est pas de savoir ce qu’est ce contenu, mais de comment il est constitué. Et c’est une différence de taille.

Il faut donc commencer par la structure, pas par les mots. Qu’est-ce qu’un « article d’opinion » ? Quels sont les variables à prendre en compte ? Peut-on même les définir ? Y aura-t-il des images ? Combien ? (La réponse est toujours la même : « Je ne sais pas, ça dépend ! »). Nous pouvons concevoir en privilégiant la fluidité, mais cela signifie une perte de contrôle. Encore. Comment faire, alors ? Comment concevoir en privilégiant la fluidité ? Eh bien, nous définissons la structure de notre contenu et les gabarits qu’il occupera. Nous définissons les règles du système pour qu’il affiche le contenu de différentes manières (si possible) pour aider le lecteur à mieux comprendre le contenu.

Comme le dit Erik Spiekermann : « on donne de la forme au contenu ».

Les concepteurs en tant que directeurs de contenu

Les designers ont toujours été impliqués par le contenu. Nous ne nous arrêtons pas à l’aspect visuel. Mais comment le faire comprendre à nos clients à comprendre lorsque nous disons :

« Le contenu d’abord ! »

Ce n’est pas pour dire :

« Je vais rester assis ici sans bouger jusqu’à ce que vous me donniez le contenu. Je dis bien le contenu finalisé, validé, paraphé, signé. Merci, j’attends »

Non, bien sûr. Il faut plutôt comprendre :

« Nous aimerions bien comprendre le type et la structure des contenus pour ce projet. Ne vous inquiétez pas, vous n’êtes pas obligé de commencer à l’écrire, aidez-nous seulement à comprendre. »

Nous pouvons faire cela de nombreuses manières mais récemment, j’ai remarqué que ces grands principes fonctionnaient bien pour moi :

  1. Parler. Et utiliser des Post-It. Installez-vous dans une pièce (fermée à clef de préférence) et discutez du site web ou de l’application. Pas du contenu pour le moment. Pendant que vous êtes en train de parler, écrivez les mots qui résonnent à votre oreille. Après avoir discuté, accrochez ces mots sur un mur et commencez à les connecter entre eux. Nos confrères de l’expérience utilisateur ont sûrement un nom qui claque pour qualifier cet exercice, mais je ne le connais pas.
  2. Accepter le désordre. Vous devriez vous retrouver avec tout un tas de mots vaguement reliés entre eux (ce n’est toujours pas du contenu) à propos de différents sujets. Ces sujets sont l’ADN de votre site. L’attitude, le ton, la marque, le message, ainsi que les points de détail tels que les différents types de contenu, taxonomies, mots-clés et autres aspects techniques. Maintenant, il faut ordonner tout cela.
  3. Itérer. À un moment pendant le tri, vous aurez besoin de commencer à dégager la structure. Là aussi, j’ai constaté qu’effectuer cette étape de manière itérative et à plusieurs est plus fructueux.
  4. Structurer. Vous devriez maintenant avoir un début de structure. À l’étape 3, il y a sûrement un moment où votre client (ou vous-même) dira en désignant un terme noté sur un Post-it : « Oui, mais qu’est-ce que c’est que ça ? » Dessinez la structure sur un papier et qualifiez-la par un mot. C’est là que vous allez entrer dans le détail et tâcher de donner du corps à cette idée. C’est ce qui définit la structure de votre contenu. Et ce n’est pas terminé.
  5. Prévoir. Utilisez un tableau de contenu. En gros, c’est comme un tableur pour vos contenus. Remplissez-le, je vous conseille celui de Relly, il est excellent. Cet outil peut vraiment aider vos clients plus tard quand arrive l’étape « Oh mon dieu, j’ai tellement de contenu à écrire et je ne sais pas par où commencer ». Cela permet de se concentrer sur ce qui compte.

Arrêtons de cloisonner le contenu. Nous avons déjà fait cette erreur à l’époque où le web imitait les brochures imprimées ; l’approche « Contenu en premier » ne fait que déplacer le problème à l’autre bout du processus. Concentrons-nous donc sur la structure pour commencer, mais en gardant le contenu à l’esprit tout du long. La relation contenu-mise en forme est quasi symbiotique : ni l’un ni l’autre ne peut exister isolément.

Commençons par la structure. Et découvrons de quoi le contenu est fait, plutôt que de nous inquiéter de ce qu’il est.

Voici la liste des dix articles les plus récents en rapport avec cet article :

]]> https://www.pompage.net/traduction/structure-d-abord-le-contenu-suivra https://www.pompage.net/traduction/structure-d-abord-le-contenu-suivra Tue, 08 Jul 2014 10:07:00 +0200 <![CDATA[Principes à connaître pour améliorer vos feuilles de styles]]>

Par Hugo Giraudel

Cet article passe en revue quelques principes de base et astuces tirés de mon expérience personnelle pour apprendre à devenir meilleur en CSS. Dans cet article, je vais parler avant tout de ma propre expérience et de ce que j’ai appris sur CSS pendant près d’un an et demi de pratique intensive.

Tout d’abord, laissez-moi vous rappeler que CSS est un langage extrêmement simple. Il peut se résumer en 3 mots : sélecteur, propriété, valeur. Et c’est à peu près tout. C’est pourquoi certaines personnes n’aiment pas du tout CSS car elles ont l’impression d’être comme des enfants qui jouent aux Legos.

En effet, il suffit d’expliquer les bases de CSS à un enfant de 9 ans pour qu’il ou elle soit en mesure de créer un site web. Pas un site compliqué bien entendu, mais peut-être quelques pages avec des titres, des liens, du contenu, des images, quelque chose dans ce goût-là.

Toutefois, le fait que CSS soit un langage simple ne veut pas dire que tout le monde soit au même niveau. Certaines personnes utilisent CSS comme un chimpanzé se sert d’une fourchette, certaines personnes se débrouillent pas mal avec et d’autres peuvent faire des choses formidables.

De ce que je peux en dire, je m’amuse avec CSS depuis près de deux ans maintenant et je pratique à un niveau disons « intensif » depuis près de sept mois. Je suis encore loin de la perfection et il y a toujours des astuces que je ne connais pas ou que je ne comprends pas.

Quoi qu’il en soit, voici quelques trucs que j’ai compris au cours des mois écoulés et que j’aimerais partager avec vous. Encore une fois ce ne sont pas des bouts de code ou des astuces utiles, ce sont plutôt des principes généraux et des bonnes pratiques. Voici ce que je vais aborder :

  1. Ne pas se ruer sur le code et faire simple
  2. Apprendre les bases et quelques astuces
  3. Ne pas se répéter
  4. CSS orienté objet
  5. CSS3 : apprendre ce que l’on peut faire et ce que l’on peut utiliser
  6. Amélioration progressive et dégradation élégante
  7. Les préprocesseurs CSS
  8. Garder un œil sur l’avenir
  9. Lire le code des autres
  10. Pratiquer sans relâche

Qu’en dites-vous ? Vous êtes prêts ? Allez, c’est parti.

1. Ne vous ruez pas sur le code et faites au plus simple

Ne vous ruez pas sur le code

C’est plutôt un conseil général, qui n’est pas spécifique à CSS. Quand vous êtes sur le point de commencer à développer, réfléchissez d’abord à ce que vous allez faire. Posez-vous quelques questions :

  • Comment vais-je faire ça ?
  • Y a-t-il une autre manière de faire ?
  • Comment puis-je l’optimiser (pour que ce soit maintenable, propre, cool, etc.) ?

Commencer à coder sans réfléchir peut vous faire perdre du temps. Imaginez-vous passer une heure à créer quelque chose pour vous apercevoir que c’est sans issue et que vous devez tout recommencer depuis le début ? C’est hors de question.

Passer des heures sur un diaporama en CSS pour finir avec SlidesJS ou Adaptor, c’est vraiment nul. Non pas parce que vous avez échoué, mais parce que c’était une perte de temps. Vous pourriez le payer très cher, le jour où vous serez soumis à des délais très serrés.

Faites simple

CSS est un langage simple mais les choses peuvent facilement devenir complexes. Surtout si vous voulez qu’elles le deviennent. Dans la plupart des cas, l’idée la plus simple est souvent la meilleure. Quand vous devez réaliser quelque chose, demandez-vous toujours s’il n’y a pas un moyen plus simple de le faire. Vous seriez surpris du nombre de fois où la réponse est « oui ».

Par exemple, si vous voulez coder une barre de navigation horizontale vraiment simple qui ne comporte que des liens, vous avez plusieurs façons de faire :

  • Faire flotter les éléments de la liste
  • Passer les éléments de la liste en ligne
  • Passer les éléments de la liste en blocs en ligne (inline-block)

Choisissez le plus simple et transformez les éléments de liste en éléments en ligne. Pas besoin de hack pour nettoyer les flottants. Pas besoin de corriger l’espacement des éléments en ligne. Il y a juste besoin d’un espacement interne classique, rien de plus. Fin de chantier.

2. Connaître les bases et apprendre les astuces

Pour devenir bon en CSS ou quoi que ce soit d’autre dans la vie, vous devez connaître les bases. Vous ne deviendrez jamais un expert si vous n’êtes pas à l’aise avec les bases de la discipline.

Les bases de CSS

Quelles sont les bases de CSS ? Selon les personnes, vous aurez droit à différentes versions, c’est plus de l’ordre du ressenti, mais si vous voulez mon avis, il y a deux choses à comprendre avant tout pour vraiment se familiariser avec CSS :

  • Le modèle de boîte. Chaque élément en CSS est une boîte (de type bloc ou en ligne) avec une largeur, une hauteur, et éventuellement des espacements, des marges et des bordures. C’est la chose la plus importante à savoir. Vous en saurez davantage ici.
  • La spécificité. Pour pouvoir corriger vos CSS, il est essentiel de savoir quelle règle est plus forte que quelle autre. Pour plus d’informations sur le sujet, lisez les spécifications : L’assignation des valeurs des propriétés, la cascade et l’héritage.

Les astuces

Une fois que vous avez compris ça, vous êtes sur la bonne voie. À partir de là, vous n’aurez qu’à apprendre quelques astuces pour vous débrouiller avec les cas spécifiques. Et vous n’avez pas fini d’en croiser. Laissez-moi vous en montrer quelques-unes.

Le coup du « j’ai oublié de positionner l’élément parent »

.enfant { position: absolute; top: 0; left: 0;
} /* Ceci a été oublié */
/*
.parent { position: relative; // Ou n’importe quelle autre valeur que static.
}
*/

Et c’est là que vous vous dites : « Hein ?! Mais pourquoi est-ce que mon élément est en haut à gauche de la page ? » Eh oui : vous avez oublié de définir la position de l’élément parent (relative, absolute, tout ce que vous voulez sauf static).

Le coup du « contexte d’imbrication »

.parent { z-index: 1; opacity: 0.5; transform: rotate(5deg);
} .enfant { z-index: -1;
}

Tous les développeurs au monde ont bataillé au moins une fois sur le sujet de l’imbrication de boîtes. En résumé, il est tout simplement impossible d’appliquer un z-index à un enfant d’un élément (ou d’un pseudo-élément) qui possède déjà un contexte d’imbrication (déclenché soit par z-index, opacity ou transform) ; il n’y a pas d’autres possibilités. Une fois que vous maîtrisez ça, impossible de l’oublier, promis.

NB : pour plus d’information à propos de z-index et de l’imbrication CSS, je vous recommandece superbe billet de Steven Bradley.

Le coup du « J’ai oublié d’effacer le flottant »
Votre mise en page devient folle. Les blocs se baladent n’importe où. Vous pleurez sans comprendre les raisons de cet affichage étrange. Alors vérifiez vos flottants ! Dans la plupart des cas, c’est que vous avez oublié de les réinitialiser.

Note : dans le cas où un parent contient uniquement des éléments flottants, il va se réduire à moins que vous n’annulez les flottants, ou alors que vous définissiez une hauteur ou un overflow (NdT : propriété définissant les dépassements de blocs ou comment le contenu est rogné : si le contenu dépasse les dimensions d’un bloc, overflow permet de cacher le contenu, d’afficher une barre de défilement ou pas).

Je pourrais continuer pendant des heures sur ces sujets, mais ce n’est pas le but de cet article. Je dirais que CSS présente un grand nombre de cas particuliers et on en découvre encore chaque jour. Tant que vous ne vous serez pas cassé les dents dessus, vous ne saurez pas qu’ils existent ; mais ensuite, vous saurez comment les traiter.

3. DRY

DRY est l’acronyme de Don’t Repeat Yourself (Ne pas se répéter, NdT), et encore une fois ce n’est pas spécifique à CSS. Il s’agit plutôt d’une pratique répandue lorsque vous codez, quel que soit le langage avec lequel vous avez à composer.

Ainsi, l’idée principale est d’éviter de répéter les mêmes bouts de code X fois alors qu’une seule fois pourrait suffire. Dans certains langages, cela peut évoquer l’utilisation d’une fonction, mais en CSS, cela signifie utiliser une classe plutôt que cibler un élément spécifique (voir plus loin la section concernant OOCSS). Pourtant, parfois il existe une chose vraiment simple comme la mutualisation de son code (refactoring). Laissez-moi vous expliquer.

Si vous êtes en présence d’un bout de code qui est présent plusieurs fois dans votre feuille de style, il pourrait être intéressant de le mutualiser (refactoriser) afin de n’avoir plus qu’une seule occurrence. Lisez ce qui suit :

.navigation li { color: #333;
} .navigation li a { color: #333;
} /* Mutualisé */ .navigation li,
.navigation li a { color: #333;
}

Vous voyez ? Vous vous demandez peut-être quel est l’intérêt, puisque le résultat est le même. Il y a deux choses à prendre en compte : la performance et la facilité de maintenance.

À propos de la performance : moins de lignes de code signifie un parcours plus rapide de la CSS par le navigateur. Pour faire simple, le navigateur va appliquer la couleur aux deux règles à la fois au lieu de le faire deux fois.

À propos de la maintenance, je pense que cela parle de soi-même. En procédant de la sorte, vous avez seulement une ligne à changer alors qu’avant vous deviez en changer deux pour modifier la couleur. Qu’en est-il quand vous avez 50 fois ou 300 fois le même code ?

Plus d’informations sur DRY CSS

4. OOCSS

C’est quoi ce truc ?

OOCSS est l’acronyme d’Object-Oriented CSS (CSS Orienté Objet, NdT) . Vous avez probablement entendu parler de la programmation orientée objet. Il s’agit tout bonnement d’utiliser des « objets », généralement des instances de classes (qui se composent d’attributs et de méthodes). J’imagine que vous vous demandez quel peut être le rapport avec CSS ?

Premièrement, disons que c’est plus un concept ou une bonne pratique qu’un vrai principe. CSS ne peut pas vraiment être orienté objet sachant que ce n’est pas un langage de programmation : pas d’espace de nommage, pas de fonctions, pas de méthodes, pas de classes de programmation, aucune des instructions conditionnelles, etc. C’est pourquoi certaines personnes ricaneront quand vous parlerez d’OOCSS.

Même si je suis d’accord avec cela, malgré tout nous pouvons encore optimiser notre façon de coder les CSS pour faciliter le processus, rendre les sites Web plus rapides et améliorer la maintenabilité.

Comment faire ?

Pour le dire simplement, cela signifie utiliser des classes. Un grand nombre de classes. Pensez à votre site comme s’il possédait des « modules » ou des « composants », si vous voulez. Essayez de repérer les modèles qui se répètent pour en faire des « objets » (classes) afin de les réutiliser.

Pour être un peu plus précis, cela signifie essentiellement deux choses :

  • Séparer structure et apparence
  • Séparer conteneurs et contenu

Séparer structure et apparence

Séparer la structure et l’apparence peut se révéler important : vous savez que des éléments graphiques peuvent être utilisés à plusieurs endroits sur un site web et sur plusieurs types d’éléments­­­­, n’est-ce pas ? Prenez le bout de code suivant, cela peut convenir à un bouton, à une image, ce que vous voulez :

#mon-bouton,
.ma-boite
.ma-boite img { border: 1px solid #444; border-radius: 5px; box-shadow: 0 0 5px rgba(0,0,0,0.1);
}

Maintenant, au lieu de ce qui précède, nous pourrions créer une classe qu’on appellerait « habillage » (skin) ou quelque chose comme ça, et l’appliquer aux éléments qui en ont besoin. Le résultat est beaucoup plus compréhensible, la feuille de style plus maintenable et une interprétation de classes plus rapide.

.habillage { border: 1px solid #444; border-radius: 5px; box-shadow: 0 0 5px rgba(0,0,0,0.1);
}

Séparer conteneurs et contenu

Je pense que c’est l’une des règles les plus importantes de OOCSS : coder des composants indépendants, pas des bouts de code pour un élément spécifique de votre modèle. Les choses devraient être réutilisables, quelle que soit leur place sur votre site Internet, sans les coder à nouveau. Prenons l’exemple suivant :

#principal h2 { color: #343434; font-size: 25px; line-height: 20px; border-bottom: 1px solid rgba(0,0,0,0.2); box-shadow: 0 1px rgba(255,255,255,0.4);
}

D’accord. Maintenant, si je veux exactement le même style sur un titre de niveau 2 placé dans le pied de page ? Ou bien mettre en forme un titre de niveau 3 placé exactement de la même manière (quelle qu’en soit la raison) ? La meilleure façon de faire consisterait à créer une classe et à donner ces styles à cette classe, pas aux éléments eux-mêmes.

Qu’en est-il du « ne jamais utiliser d’ID » ?

Quand Nicole Sullivan a découvert le concept de CSS orienté-objet, ce fut un sujet chaud. En effet CSSLint, un outil de qualité du code CSS créé par Nicholas C. Zakas et Nicole Sullivan, déconseille l’utilisation des sélecteurs d’ID.

Pour comprendre le point de vue de Nicole, il est important de comprendre que les ID peuvent poser certains problèmes de priorité, car ils ont le score le plus élevé dans ce domaine. Prenez le code suivant à titre d’exemple (à voir sur CSSWizardry - source ici) :

<!-- HTML -->
<div id="en-tete"> <p> <a href="#">Foo</a> <a href="#">Bar</a> </p> <div class="tweet"> <a href="#">Suivez-moi sur twitter</a> </div>
</div>
<div class="tweet"> <a href="#">Suivez-moi sur twitter</a>
</div> /* CSS */
#en-tete a { color: #f90; }
.tweet a { color: #000; }

Pour mettre le premier lien Twitter en noir, vous avez deux options : soit lui donner une ID, soit utiliser le lourdaud <important!>. Si #en-tete était une classe au lieu d’une ID, le problème n’aurait pas existé.

C’est en partie la raison pour laquelle Nicole Sullivan a dit « pas d’ID ».

Je finirai cette partie par la citation de Harry Roberts sur le sujet : « [...] J’ai décidé qu’une interdiction générale était l’option la plus logique. Épargnez-vous beaucoup de soucis : n’utilisez jamais d’ID dans vos fichiers CSS ».

Bien sûr, il est tout à fait possible d’utiliser des IDs qui restent parfaitement valides.

Quel est mon sentiment sur OOCSS ?

En ce qui me concerne, je ne suis pas vraiment un expert sur le sujet. D’abord parce que je n’ai jamais travaillé sur un site énorme impliquant de nombreux développeurs front-end. Ne nous leurrons pas, c’est sans doute très utile pour les sites de grande importance, mais pas forcément pour le petit site que vous faites pour votre boulanger.
Cependant, même si je n’utilise pas OOCSS dans mes projets, j’essaie de me concentrer sur les choses importantes comme la réutilisation des composants, la maintenabilité de la feuille de style, la performance et autres. Ce sont les choses sur lesquelles OOCSS se concentre, donc d’une certaine façon, je ne suis pas si loin de la logique.

Autres ressources sur OOCSS et les IDs

5. CSS3 : découvrez ce que vous pouvez faire et ce que vous pouvez utiliser

Bon, assez de concepts. Parlons de choses sérieuses. Parlons un peu de CSS3. Bien qu’en réalité CSS3 n’existe pas en tant que tel :

Contrairement à CSS2, qui est une importante spécification définissant diverses caractéristiques, CSS3 est divisé en plusieurs documents séparés appelés « modules ». Chaque module ajoute de nouvelles fonctionnalités ou étend les fonctions définies dans CSS2, sur la préservation de la rétro-compatibilité. [...] En raison de la modularisation, les différents modules sont plus ou moins stables et aboutis.


(Traduction de Cascading Style Sheets sur Wikipedia EN)

Mais entendons-nous sur le fait que nous parlons des nouvelles fonctionnalités que comprennent les navigateurs modernes.

De nos jours, CSS3 est partout : des bords arrondis aux dégradés, de la transparence aux ombres et pseudo-éléments.

Que peut-on faire ?

À mon avis, vous pouvez vous servir de CSS3 pour réduire le nombre de requêtes HTTP (images), le nombre de balises et la taille des fichiers JavaScript. Voyons cela de plus près :

  • Coin arrondi (border-radius) : 1 ligne de CSS au lieu de 4 conteneurs + 4 images
  • Opacité (opacity) et canal alpha de couleur : 1 ligne de CSS au lieu d’un PNG semi-transparent
  • Sélecteurs avancés : pas besoin de JavaScript
  • Boîte flexible (flexbox) : quelques lignes de CSS au lieu de toute une bibliothèque JavaScript
  • Dégradés (gradient) : quelques lignes de CSS au lieu d’une image d’arrière-plan répétée
  • Arrières-plans multiples (background) : pas besoin de plusieurs conteneurs
  • Pseudo-éléments (pseudo-element) : pas de balises supplémentaires pour les éléments décoratifs

Et je pourrais continuer longtemps mais je pense que vous avez compris. Ce que je veux faire passer comme message, c’est ceci : lancez-vous, et découvrez tout ce que vous pouvez faire avec CSS3. Vous devez créer une table des matières ? Sachez que vous pouvez le faire uniquement avec CSS grâce à CSS counters. Vous devez définir une bordure originale personnalisée pour un site ? Sachez qu’il existe une propriété border-image pour l’intégrer.

Vous pouvez faire un million de choses avec CSS, et c’est encore plus vrai quand il s’agit de CSS3. Il est important de savoir ce que vous pouvez faire ou pas. Malheureusement, il n’existe pas de potion magique pour cela, vous devez lire la documentation et faire des expériences. À partir de là, vous apprendrez que vous pouvez faire des calculs avec la propriété calc (), mais vous ne pourrez pas obtenir 6 colonnes d’égale hauteur sans avoir à vous battre comme un beau diable.

Apprendre ce que vous pouvez utiliser

Le plus gros problème avec CSS, c’est que tous les navigateurs ne prennent pas en charge les mêmes propriétés. Pire, certaines propriétés sont gérées de plusieurs manières différentes quand il s’agit de CSS3. Ce sera votre plus grande malédiction lors de l’expérimentation avec CSS3.

À titre d’exemple, prenez la propriété CSS3 la plus simple : border-radius (coin arrondi). Eh bien, il y a des navigateurs qui ne comprennent pas les coins arrondis (IE8 + version antérieure et Opera Mini). En fait, même Firefox et Chrome n’interprètent pas border-radius de la même façon (ou ne l’ont pas toujours fait de la même façon).

Qu’est-ce que cela signifie pour vous en tant que développeur front-end ? Cela veut dire que si vous devez afficher des coins arrondis dans tous les navigateurs, vous pouvez le faire à l’ancienne. Arrière-plans multiples + images multiples, ou alors adopter les deux solutions et servir l’une ou l’autre en fonction du navigateur.

Quand je dois faire quelque chose en CSS, voici le processus que je suis :

  1. Comment vais-je faire cela ?
  2. D’accord, je comprends. Fait-il partie de la spécification CSS2.1 ?
    1. Oui : fastoche, fin de l’histoire.
    2. Non, passez à l’étape 3.
  3. Quelle est la qualité du rendu par les navigateurs ?
    1. Bonne : fastoche, fin de l’histoire.
    2. Mauvaise, passez à l’étape 4.
  4. Est-ce une amélioration ou une fonction vitale ?
    1. C’est juste une amélioration. Je ne fais rien pour les navigateurs non pris en charge ou à la limite j’ajoute une solution de repli (fallback).
    2. Il s’agit d’une caractéristique essentielle : passez à l’étape 5.
  5. Comment vais-je le faire fonctionner dans les navigateurs non pris en charge ?

Prenons un exemple réel, d’accord ? Avec quelque chose de simple, comme un dégradé. Allons-y.

  1. Comment vais-je faire cela ?
  2. D’accord, je comprends. Fait-il partie de la spécification CSS2.1 ?
    • Non, les dégradés appartiennent à CSS3.
  3. Quelle est la qualité du rendu par les navigateurs ?
    • Pas mal, mais pas parfait. IE8 + versions antérieures ainsi qu’Opera Mini ne prennent pas en charge les dégradés CSS.
  4. Est-ce une amélioration ou une fonctionnalité vitale ?
    1. Il s’agit plutôt d’une amélioration graphique, rien de fondamental. Je vais ajouter une couleur unie comme solution de repli.
    2. C’est un élément graphique indispensable : je dois le faire fonctionner pour les navigateurs non supportés.
  5. Comment vais-je faire pour les anciens navigateurs ?
    • Je vais devoir recourir à une image d’arrière-plan.

Grâce à ce processus pas à pas, vous savez comment faire quelque chose avec CSS (si c’est faisable), si vous pouvez l’utiliser en tenant compte du support des navigateurs et comment créer des solutions de repli.

NB : souvenez-vous toujours de l’audience cible de votre site web ou de votre application. Si vous créez du contenu web pour une application iPad, vous pourrez utiliser de nombreuses propriétés CSS3 sans vous soucier des solutions de repli. Toutefois si vous créez un site pour une banque, rappelez-vous que beaucoup de gens utilisent encore IE8 ou des versions plus anciennes encore.

Fournir des solutions de repli

Selon la situation, fournir une solution de repli pour les navigateurs non pris en charge peut être soit ridiculement simple soit extrêmement pénible. En effet, il y a des cas différents. Regardons cela de plus près.

Pas de solution de repli ou une solution de repli simple

Quand il y a une amélioration de l’expérience utilisateur dont l’absence de prise en charge est sans conséquences, vous n’êtes même pas obligés de fournir une solution de repli. C’est appréciable.

Il y a aussi quelques propriétés qui sont faciles à traiter quand il s’agit de solution de repli. En général, vous devez seulement écrire deux versions de cette propriété : d’abord la solution de repli, puis la version correcte pour les navigateurs qui le supportent.

.mon-element { border: 1px solid #666; border: 1px solid rgba(0,0,0,0.3); background: #708090; background: hsl(210, 13%, 50%);
}

Dans ce cas, les navigateurs ne supportant pas rgba et hsl ne liront pas les lignes 3 et 5 ; de ce fait vous fournissez des versions alternatives aux lignes 2 et 4. Pour les navigateurs pris en charge, ils vont d’abord appliquer la version alternative, puis la remplacer par la version correcte.

Modernizr

De nos jours, on ne peut guère parler de CSS3 sans mentionner Modernizr. Il s’agit d’une bibliothèque JavaScript qui teste la prise en charge des fonctionnalités HTML5 et CSS3 au chargement de la page. Cela peut sembler lourd, mais il est bien optimisé et assez rapide.

Quoi qu’il en soit, parfois, il faut savoir précisément si le navigateur prend en charge une fonctionnalité particulière. Notamment pour fournir une version alternative nécessitant d’autres propriétés CSS.

/* Version normale */
.menu-deroulant { opacity: 0; pointer-events: none;
} .declencheur:hover .menu-deroulant { opacity: 1; pointer-events: auto;
} /* Solution de repli avec Modernizr */ .no-opacity .menu-deroulant,
.no-pointerevents .menu-deroulant { opacity: 1;
pointer-events: auto;
display: none;
} .no-opacity .declencheur:hover .menu-deroulant,
.no-pointerevents .declencheur:hover .menu-deroulant { display: block;
}

Pour fournir une solution de repli de ce type, les classes ajoutées par la bibliothèque Javascript Modernizr vous seront d’un grand secours (.no-opacity [sans-opacite] et .no-pointerevents [sans-evenementpointeur]). Vous ne pouvez pas avoir les deux versions simultanément.

Quoi qu’il en soit, n’oubliez jamais de définir une solution de repli, c’est vraiment important. Les fonctionnalités majeures doivent être prises en charge par tous les navigateurs, tant les anciens que les nouveaux, et si ce n’est pas le cas partout, vous devez avertir l’utilisateur.

Donc, soit vous commencez avec une base simple et l’améliorez pour les navigateurs récents, soit vous commencez avec une base moderne et vous composez pour les navigateurs plus anciens. Voir la section suivante pour plus d’informations.

Autres ressources sur CSS3 :

6. Amélioration progressive et dégradation élégante

Ce sont deux termes dont vous avez probablement déjà entendu parler, en particulier la dégradation élégante, mais il y a une différence subtile entre les deux.

Amélioration progressive

Le principe de l’amélioration progressive est d’établir une base commune de fonctionnalités et de fonctions disponibles, et ensuite, d’améliorer l’expérience utilisateur en fonction de ce que le navigateur prend en charge.

Utiliser l’attribut HTML5 required pour avertir l’utilisateur qu’un champ est manquant dans un formulaire avant de le soumettre peut être considéré comme une amélioration progressive. Il s’agit d’une amélioration de l’expérience utilisateur rendue possible grâce au moteur natif du navigateur.

Dégradation élégante

Vous utilisez la dégradation élégante lorsque vous déclinez une version alternative ou inférieure de vos fonctionnalités au cas où elles ne sont pas prises en charge. Fondamentalement, on part du plus haut pour aller vers le plus bas.

Un exemple très simple serait l’avertissement que vous mettez entre les balises <canvas> pour informer les utilisateurs de navigateurs qui ne les prennent pas en charge qu’il y a quelque chose qu’ils ne peuvent pas voir.

<canvas>
Cette page utilise HTML5 Canvas. Veuillez utiliser un navigateur récent pour voir ce contenu. Pour obtenir un autre navigateur, allez à <a href="http://browsehappy.com/">BrowseHappy</a>
</canvas>

Quelle est la différence ?

En fin de compte, il n’y en a pas. Vous avez des fonctionnalités pour les navigateurs récents et des fonctionnalités ou des solutions de repli pour les plus anciens. C’est plutôt une question de procédure : soit vous codez pour les navigateurs modernes tout en proposant une solution de repli pour les anciens, soit vous le faites dans l’autre sens. C’est un choix.

En tout cas, je veux redire ici que l’expérience utilisateur n’est pas nécessairement la même dans tous les navigateurs. En fait, ce n’est même pas possible, puisque les moteurs des navigateurs sont différents. Quoi qu’il en soit, vous devez fournir des fonctionnalités de base pour tout le monde, mais faites-moi plaisir : améliorez votre site web ou votre application pour les navigateurs modernes. Ils sont bien conçus, ils fournissent des fonctionnalités à l’état natif : utilisez-les.

Lectures complémentaires sur l’amélioration progressive et la dégradation élégante

7. Les préprocesseurs CSS

Aaaah, les préprocesseurs… Le sujet chaud du moment. Sont-ils utiles ? Pour quoi faire ? Devrais-je en employer un ? Lequel ? Je pense que c’est l’un des sujets les plus débattus sur CSS en ce moment.

Je vais essayer d’être aussi objectif que possible dans cette partie. Permettez-moi de commencer par ceci : si vous ne voulez pas utiliser un préprocesseur, alors ne le faites pas. Ce ne sera jamais un problème. Vous ne serez pas un mauvais développeur front-end pour autant. Cela ne vous rendra pas incapable de faire certaines choses. Mais vous devriez, néanmoins, essayer de vous faire votre propre opinion à ce sujet.

Ok, j’en ai fini avec les précautions. Qu’est-ce qu’un préprocesseur, de manière générale ? Un préprocesseur est une sorte d’outil qui compile une syntaxe donnée dans une langue utilisée par un autre programme (dans le cas présent : le navigateur). Il y a des préprocesseurs pour de nombreux languages : il y a Markdown ou Jade pour le HTML. Il y a LESS, Sass et Stylus pour CSS. Il existe CoffeeScript pour JavaScript. Il y a CakePHP pour PHP et ainsi de suite.

De quoi parle-t-on ?

Un préprocesseur CSS fournit aux CSS certaines particularités à partir de langages orientés objet. Des choses comme :

  • les variables
  • les fonctions (avec des paramètres)
  • les espaces de nommages
  • l’imbrication
  • les instructions conditionnelles
  • les opérations
  • etc.

Ça a l’air attrayant, non ? Peut-être que vous voulez un exemple pour comprendre la manière dont cela fonctionne. Prenons le CSS suivant pour une barre de navigation.

.navigation { width: 800px; width: calc(100%-150px);
}
.navigation li { color: #444;
}
.navigation li a { text-decoration: none;
}

Et voici maintenant la version compilée (SCSS) :

$couleur-principale: #444; .navigation { width: (100%-150px); li { color: $couleur-principale; a { text-decoration: none; } }
}

En gros, un préprocesseur va interpréter ceci dans une version CSS standard. Ce sera exactement la même chose, sauf pour le calcul. Il lancera l’opération elle-même et affichera le résultat correspondant sans qu’il soit nécessaire d’utiliser une fonction comme calc().

Donc, vous vous retrouvez avec une feuille de style plus compréhensible (variables et imbrications) et plus facile à maintenir (variables et fonctions). C’était un exemple très théorique, mais dans un projet réel, vous sentirez la différence.

Comment le choisir ?

Il existe beaucoup de préprocesseurs CSS, chacun avec ses avantages et ses particularités. Quoi qu’il en soit, chacun d’entre eux fait plus ou moins la même chose, donc le choix vous appartient. Voici les principales options quand il s’agit de préprocesseurs CSS :

  • Sass (écrit en Ruby)
  • LESS (écrit en JavaScript)
  • Stylus (écrit en JavaScript)
  • Crush (écrit en PHP)

L’idéal, c’est d’apprendre à les connaître, de les tester et de voir ce qui répond le mieux à vos besoins et à votre projet. Il y a plusieurs facteurs qui entrent en jeu ; les énumérer tous serait hors de la portée de cet article, mais vous pouvez trouver quelques ressources pertinentes ci-dessous.

Mon sentiment sur les préprocesseurs CSS ?

Je ne suis pas un expert quand il s’agit de préprocesseurs CSS, mais j’en suis un partisan. Ils fournissent des fonctionnalités très utiles mais qu’on ne trouve pas dans les CSS comme les variables, les déclarations, l’imbrication et les conditions.

J’ai bricolé un peu avec LESS, et il m’a fait à peu près ce que je voulais. Ou du moins, jusqu’à ce que je commence à me lancer dans des choses un peu plus compliquées que vous avez pu lire dans mon dernier article sur CSS Loading Animations (pour les boucles + préfixes vendeurs + keyframes).

J’ai aussi jeté un coup d’œil rapide à Sass et Compass. À ma grande surprise, c’était incroyablement facile à installer et à lancer grâce à Ruby. J’avais peur, mais c’est très très intuitif, croyez-moi. En fin de compte, je suis vraiment impressionné par l’association Sass + Compass. Vous pouvez également en savoir plus sur les raisons pour lesquelles je suis passé de LESS à Sass dans cet article sur mon blog.

Quoi qu’il en soit, je suis encore tout à fait capable d’écrire des CSS classiques sans préprocesseur, et la plupart du temps c’est ce que je fais. Mais au final, je pense que nous allons tous en utiliser un, quel qu’il soit. Il nous manque vraiment certains éléments très utiles avec les CSS, et les préprocesseurs CSS sont là pour y remédier.

Lectures complémentaires sur les préprocesseurs CSS

8. Garder un œil sur l’avenir

Les langages sont en constante évolution. C’est particulièrement vrai pour les CSS. Les spécifications CSS bougent sans cesse, et les navigateurs ajoutent sans cesse de nouvelles fonctionnalités à leurs moteurs.

À ce propos, mon premier conseil serait de rester à l’écoute de ce qui se prépare. Je sais que vous ne pouvez pas être en mesure de tout utiliser dès son lancement, mais savoir quelle fonctionnalité est maintenant prise en charge par Canary Chrome, bientôt par Chrome version stable et Safari, puis par Opera, Firefox et ainsi de suite, c’est important afin de prendre du recul sur les problèmes CSS et les solutions possibles.

Ressources pour garder un œil sur l’avenir :

9. Lire le code des autres

Une des meilleures façons d’apprendre à coder est de lire du code.

Heureusement, le CSS est visible côté client, ce qui vous permet de le lire sur n’importe quel site avec un inspecteur web comme WebKit inspector, Dragonfly, Firebug, etc. De plus, l’industrie du web est très orientée vers l’open-source, ce qui signifie que les gens sont heureux de partager leurs sources avec vous.

Une autre excellente façon d’apprendre est de suivre des tutoriels. Prenez un tutoriel simple, et suivez-le étape par étape. Ensuite, essayez de le refaire à partir de zéro. S’il vous arrive d’être bloqué, jetez un coup d’œil à la solution, puis continuez par vous-même.

Lorsque vous serez à l’aise avec CSS et que vous voudrez entrer finement dans les détails, vous voudrez peut-être jeter un œil à des démonstrations et des expériences qui ne sont pas commentées ni expliquées. Les gens créent des choses tous les jours, et vous tomberez sans arrêt sur des choses que vous ne connaissiez pas encore.

À ce sujet, il y a quelques mois Chris Coyier, Tim Sabat et Alex Vazquez ont lancé CodePen, une sorte de plate-forme pour créer, partager et explorer du code (HTML, CSS, JavaScript). CodePen comprend également un tas d’outils comme les bibliothèques (jQuery, jQuery UI, MooTools, YUI, Prototype, Zepto, Dojo, Ext JS, PrefixFree, etc) et les préprocesseurs (HAML, Markdown, Slim, LESS, SCSS, Sass, CoffeeScript) si vous en avez besoin.

D’autres ressources pour trouver des exemples de code créé par d’autres personnes :

10. Pratiquez sans relâche

Vous savez ce qu’on dit à propos de l’apprentissage : on apprend en faisant. Donc, mon meilleur conseil est de continuer à pratiquer comme pour toute autre chose. Plus vous pratiquez, meilleur vous serez. La pratique ne signifie pas nécessairement faire un site web à partir de zéro. Il suffit de choisir une capture simple sur Dribbble et d’essayer de la refaire en CSS. Le résultat ne sera peut-être pas utile immédiatement, mais ce que vous avez appris vous sera utile un jour.

Et comme je l’ai dit dans la partie « Apprendre les bases et quelques astuces » de cet article, CSS est plein de cas particuliers. Vous devrez apprendre à les gérer si vous voulez écrire des CSS. Et la seule façon de connaître ces cas particuliers consiste à pratiquer, découvrir de nouveaux cas, jeter un œil à la solution, et continuer.

Je vous recommande aussi de partager votre code. Il est toujours utile d’obtenir un retour constructif, alors assurez-vous de demander aux gens de vérifier votre code une fois qu’il est presque fini. Il suffit de les déposer dans un JSFiddle, de partager et de demander des commentaires.

Sommaire et crédits

Comme cet article mentionne un tas de liens et de ressources diverses, autant les rassembler tous au même endroit :

Merci beaucoup d’avoir lu cet article. J’espère qu’il vous aidera d’une manière ou d’une autre à améliorer la façon dont vous apprenez et utilisez les CSS.

]]> http://www.pompage.net/traduction/ameliorer-vos-feuilles-de-styles http://www.pompage.net/traduction/ameliorer-vos-feuilles-de-styles Thu, 19 Jun 2014 03:06:00 +0200 <![CDATA[]]>

Par Hugo Giraudel

Cet article passe en revue quelques principes de base et astuces tirés de mon expérience personnelle pour apprendre à devenir meilleur en CSS. Dans cet article, je vais parler avant tout de ma propre expérience et de ce que j’ai appris sur CSS pendant près d’un an et demi de pratique intensive.

Tout d’abord, laissez-moi vous rappeler que CSS est un langage extrêmement simple. Il peut se résumer en 3 mots : sélecteur, propriété, valeur. Et c’est à peu près tout. C’est pourquoi certaines personnes n’aiment pas du tout CSS car elles ont l’impression d’être comme des enfants qui jouent aux Legos.

En effet, il suffit d’expliquer les bases de CSS à un enfant de 9 ans pour qu’il ou elle soit en mesure de créer un site web. Pas un site compliqué bien entendu, mais peut-être quelques pages avec des titres, des liens, du contenu, des images, quelque chose dans ce goût-là.

Toutefois, le fait que CSS soit un langage simple ne veut pas dire que tout le monde soit au même niveau. Certaines personnes utilisent CSS comme un chimpanzé se sert d’une fourchette, certaines personnes se débrouillent pas mal avec et d’autres peuvent faire des choses formidables.

De ce que je peux en dire, je m’amuse avec CSS depuis près de deux ans maintenant et je pratique à un niveau disons « intensif » depuis près de sept mois. Je suis encore loin de la perfection et il y a toujours des astuces que je ne connais pas ou que je ne comprends pas.

Quoi qu’il en soit, voici quelques trucs que j’ai compris au cours des mois écoulés et que j’aimerais partager avec vous. Encore une fois ce ne sont pas des bouts de code ou des astuces utiles, ce sont plutôt des principes généraux et des bonnes pratiques. Voici ce que je vais aborder :

  1. Ne pas se ruer sur le code et faire simple
  2. Apprendre les bases et quelques astuces
  3. Ne pas se répéter
  4. CSS orienté objet
  5. CSS3 : apprendre ce que l’on peut faire et ce que l’on peut utiliser
  6. Amélioration progressive et dégradation élégante
  7. Les préprocesseurs CSS
  8. Garder un œil sur l’avenir
  9. Lire le code des autres
  10. Pratiquer sans relâche

Qu’en dites-vous ? Vous êtes prêts ? Allez, c’est parti.

1. Ne vous ruez pas sur le code et faites au plus simple

Ne vous ruez pas sur le code

C’est plutôt un conseil général, qui n’est pas spécifique à CSS. Quand vous êtes sur le point de commencer à développer, réfléchissez d’abord à ce que vous allez faire. Posez-vous quelques questions :

  • Comment vais-je faire ça ?
  • Y a-t-il une autre manière de faire ?
  • Comment puis-je l’optimiser (pour que ce soit maintenable, propre, cool, etc.) ?

Commencer à coder sans réfléchir peut vous faire perdre du temps. Imaginez-vous passer une heure à créer quelque chose pour vous apercevoir que c’est sans issue et que vous devez tout recommencer depuis le début ? C’est hors de question.

Passer des heures sur un diaporama en CSS pour finir avec SlidesJS ou Adaptor, c’est vraiment nul. Non pas parce que vous avez échoué, mais parce que c’était une perte de temps. Vous pourriez le payer très cher, le jour où vous serez soumis à des délais très serrés.

Faites simple

CSS est un langage simple mais les choses peuvent facilement devenir complexes. Surtout si vous voulez qu’elles le deviennent. Dans la plupart des cas, l’idée la plus simple est souvent la meilleure. Quand vous devez réaliser quelque chose, demandez-vous toujours s’il n’y a pas un moyen plus simple de le faire. Vous seriez surpris du nombre de fois où la réponse est « oui ».

Par exemple, si vous voulez coder une barre de navigation horizontale vraiment simple qui ne comporte que des liens, vous avez plusieurs façons de faire :

  • Faire flotter les éléments de la liste
  • Passer les éléments de la liste en ligne
  • Passer les éléments de la liste en blocs en ligne (inline-block)

Choisissez le plus simple et transformez les éléments de liste en éléments en ligne. Pas besoin de hack pour nettoyer les flottants. Pas besoin de corriger l’espacement des éléments en ligne. Il y a juste besoin d’un espacement interne classique, rien de plus. Fin de chantier.

2. Connaître les bases et apprendre les astuces

Pour devenir bon en CSS ou quoi que ce soit d’autre dans la vie, vous devez connaître les bases. Vous ne deviendrez jamais un expert si vous n’êtes pas à l’aise avec les bases de la discipline.

Les bases de CSS

Quelles sont les bases de CSS ? Selon les personnes, vous aurez droit à différentes versions, c’est plus de l’ordre du ressenti, mais si vous voulez mon avis, il y a deux choses à comprendre avant tout pour vraiment se familiariser avec CSS :

  • Le modèle de boîte. Chaque élément en CSS est une boîte (de type bloc ou en ligne) avec une largeur, une hauteur, et éventuellement des espacements, des marges et des bordures. C’est la chose la plus importante à savoir. Vous en saurez davantage ici.
  • La spécificité. Pour pouvoir corriger vos CSS, il est essentiel de savoir quelle règle est plus forte que quelle autre. Pour plus d’informations sur le sujet, lisez les spécifications : L’assignation des valeurs des propriétés, la cascade et l’héritage.

Les astuces

Une fois que vous avez compris ça, vous êtes sur la bonne voie. À partir de là, vous n’aurez qu’à apprendre quelques astuces pour vous débrouiller avec les cas spécifiques. Et vous n’avez pas fini d’en croiser. Laissez-moi vous en montrer quelques-unes.

Le coup du « j’ai oublié de positionner l’élément parent »

.enfant { position: absolute; top: 0; left: 0;
} /* Ceci a été oublié */
/*
.parent { position: relative; // Ou n’importe quelle autre valeur que static.
}
*/

Et c’est là que vous vous dites : « Hein ?! Mais pourquoi est-ce que mon élément est en haut à gauche de la page ? » Eh oui : vous avez oublié de définir la position de l’élément parent (relative, absolute, tout ce que vous voulez sauf static).

Le coup du « contexte d’imbrication »

.parent { z-index: 1; opacity: 0.5; transform: rotate(5deg);
} .enfant { z-index: -1;
}

Tous les développeurs au monde ont bataillé au moins une fois sur le sujet de l’imbrication de boîtes. En résumé, il est tout simplement impossible d’appliquer un z-index à un enfant d’un élément (ou d’un pseudo-élément) qui possède déjà un contexte d’imbrication (déclenché soit par z-index, opacity ou transform) ; il n’y a pas d’autres possibilités. Une fois que vous maîtrisez ça, impossible de l’oublier, promis.

NB : pour plus d’information à propos de z-index et de l’imbrication CSS, je vous recommandece superbe billet de Steven Bradley.

Le coup du « J’ai oublié d’effacer le flottant »
Votre mise en page devient folle. Les blocs se baladent n’importe où. Vous pleurez sans comprendre les raisons de cet affichage étrange. Alors vérifiez vos flottants ! Dans la plupart des cas, c’est que vous avez oublié de les réinitialiser.

Note : dans le cas où un parent contient uniquement des éléments flottants, il va se réduire à moins que vous n’annulez les flottants, ou alors que vous définissiez une hauteur ou un overflow (NdT : propriété définissant les dépassements de blocs ou comment le contenu est rogné : si le contenu dépasse les dimensions d’un bloc, overflow permet de cacher le contenu, d’afficher une barre de défilement ou pas).

Je pourrais continuer pendant des heures sur ces sujets, mais ce n’est pas le but de cet article. Je dirais que CSS présente un grand nombre de cas particuliers et on en découvre encore chaque jour. Tant que vous ne vous serez pas cassé les dents dessus, vous ne saurez pas qu’ils existent ; mais ensuite, vous saurez comment les traiter.

3. DRY

DRY est l’acronyme de Don’t Repeat Yourself (Ne pas se répéter, NdT), et encore une fois ce n’est pas spécifique à CSS. Il s’agit plutôt d’une pratique répandue lorsque vous codez, quel que soit le langage avec lequel vous avez à composer.

Ainsi, l’idée principale est d’éviter de répéter les mêmes bouts de code X fois alors qu’une seule fois pourrait suffire. Dans certains langages, cela peut évoquer l’utilisation d’une fonction, mais en CSS, cela signifie utiliser une classe plutôt que cibler un élément spécifique (voir plus loin la section concernant OOCSS). Pourtant, parfois il existe une chose vraiment simple comme la mutualisation de son code (refactoring). Laissez-moi vous expliquer.

Si vous êtes en présence d’un bout de code qui est présent plusieurs fois dans votre feuille de style, il pourrait être intéressant de le mutualiser (refactoriser) afin de n’avoir plus qu’une seule occurrence. Lisez ce qui suit :

.navigation li { color: #333;
} .navigation li a { color: #333;
} /* Mutualisé */ .navigation li,
.navigation li a { color: #333;
}

Vous voyez ? Vous vous demandez peut-être quel est l’intérêt, puisque le résultat est le même. Il y a deux choses à prendre en compte : la performance et la facilité de maintenance.

À propos de la performance : moins de lignes de code signifie un parcours plus rapide de la CSS par le navigateur. Pour faire simple, le navigateur va appliquer la couleur aux deux règles à la fois au lieu de le faire deux fois.

À propos de la maintenance, je pense que cela parle de soi-même. En procédant de la sorte, vous avez seulement une ligne à changer alors qu’avant vous deviez en changer deux pour modifier la couleur. Qu’en est-il quand vous avez 50 fois ou 300 fois le même code ?

Plus d’informations sur DRY CSS

4. OOCSS

C’est quoi ce truc ?

OOCSS est l’acronyme d’Object-Oriented CSS (CSS Orienté Objet, NdT) . Vous avez probablement entendu parler de la programmation orientée objet. Il s’agit tout bonnement d’utiliser des « objets », généralement des instances de classes (qui se composent d’attributs et de méthodes). J’imagine que vous vous demandez quel peut être le rapport avec CSS ?

Premièrement, disons que c’est plus un concept ou une bonne pratique qu’un vrai principe. CSS ne peut pas vraiment être orienté objet sachant que ce n’est pas un langage de programmation : pas d’espace de nommage, pas de fonctions, pas de méthodes, pas de classes de programmation, aucune des instructions conditionnelles, etc. C’est pourquoi certaines personnes ricaneront quand vous parlerez d’OOCSS.

Même si je suis d’accord avec cela, malgré tout nous pouvons encore optimiser notre façon de coder les CSS pour faciliter le processus, rendre les sites Web plus rapides et améliorer la maintenabilité.

Comment faire ?

Pour le dire simplement, cela signifie utiliser des classes. Un grand nombre de classes. Pensez à votre site comme s’il possédait des « modules » ou des « composants », si vous voulez. Essayez de repérer les modèles qui se répètent pour en faire des « objets » (classes) afin de les réutiliser.

Pour être un peu plus précis, cela signifie essentiellement deux choses :

  • Séparer structure et apparence
  • Séparer conteneurs et contenu

Séparer structure et apparence

Séparer la structure et l’apparence peut se révéler important : vous savez que des éléments graphiques peuvent être utilisés à plusieurs endroits sur un site web et sur plusieurs types d’éléments­­­­, n’est-ce pas ? Prenez le bout de code suivant, cela peut convenir à un bouton, à une image, ce que vous voulez :

#mon-bouton,
.ma-boite
.ma-boite img { border: 1px solid #444; border-radius: 5px; box-shadow: 0 0 5px rgba(0,0,0,0.1);
}

Maintenant, au lieu de ce qui précède, nous pourrions créer une classe qu’on appellerait « habillage » (skin) ou quelque chose comme ça, et l’appliquer aux éléments qui en ont besoin. Le résultat est beaucoup plus compréhensible, la feuille de style plus maintenable et une interprétation de classes plus rapide.

.habillage { border: 1px solid #444; border-radius: 5px; box-shadow: 0 0 5px rgba(0,0,0,0.1);
}

Séparer conteneurs et contenu

Je pense que c’est l’une des règles les plus importantes de OOCSS : coder des composants indépendants, pas des bouts de code pour un élément spécifique de votre modèle. Les choses devraient être réutilisables, quelle que soit leur place sur votre site Internet, sans les coder à nouveau. Prenons l’exemple suivant :

#principal h2 { color: #343434; font-size: 25px; line-height: 20px; border-bottom: 1px solid rgba(0,0,0,0.2); box-shadow: 0 1px rgba(255,255,255,0.4);
}

D’accord. Maintenant, si je veux exactement le même style sur un titre de niveau 2 placé dans le pied de page ? Ou bien mettre en forme un titre de niveau 3 placé exactement de la même manière (quelle qu’en soit la raison) ? La meilleure façon de faire consisterait à créer une classe et à donner ces styles à cette classe, pas aux éléments eux-mêmes.

Qu’en est-il du « ne jamais utiliser d’ID » ?

Quand Nicole Sullivan a découvert le concept de CSS orienté-objet, ce fut un sujet chaud. En effet CSSLint, un outil de qualité du code CSS créé par Nicholas C. Zakas et Nicole Sullivan, déconseille l’utilisation des sélecteurs d’ID.

Pour comprendre le point de vue de Nicole, il est important de comprendre que les ID peuvent poser certains problèmes de priorité, car ils ont le score le plus élevé dans ce domaine. Prenez le code suivant à titre d’exemple (à voir sur CSSWizardry - source ici) :

<!-- HTML -->
<div id="en-tete"> <p> <a href="#">Foo</a> <a href="#">Bar</a> </p> <div class="tweet"> <a href="#">Suivez-moi sur twitter</a> </div>
</div>
<div class="tweet"> <a href="#">Suivez-moi sur twitter</a>
</div> /* CSS */
#en-tete a { color: #f90; }
.tweet a { color: #000; }

Pour mettre le premier lien Twitter en noir, vous avez deux options : soit lui donner une ID, soit utiliser le lourdaud <important!>. Si #en-tete était une classe au lieu d’une ID, le problème n’aurait pas existé.

C’est en partie la raison pour laquelle Nicole Sullivan a dit « pas d’ID ».

Je finirai cette partie par la citation de Harry Roberts sur le sujet : « [...] J’ai décidé qu’une interdiction générale était l’option la plus logique. Épargnez-vous beaucoup de soucis : n’utilisez jamais d’ID dans vos fichiers CSS ».

Bien sûr, il est tout à fait possible d’utiliser des IDs qui restent parfaitement valides.

Quel est mon sentiment sur OOCSS ?

En ce qui me concerne, je ne suis pas vraiment un expert sur le sujet. D’abord parce que je n’ai jamais travaillé sur un site énorme impliquant de nombreux développeurs front-end. Ne nous leurrons pas, c’est sans doute très utile pour les sites de grande importance, mais pas forcément pour le petit site que vous faites pour votre boulanger.
Cependant, même si je n’utilise pas OOCSS dans mes projets, j’essaie de me concentrer sur les choses importantes comme la réutilisation des composants, la maintenabilité de la feuille de style, la performance et autres. Ce sont les choses sur lesquelles OOCSS se concentre, donc d’une certaine façon, je ne suis pas si loin de la logique.

Autres ressources sur OOCSS et les IDs

5. CSS3 : découvrez ce que vous pouvez faire et ce que vous pouvez utiliser

Bon, assez de concepts. Parlons de choses sérieuses. Parlons un peu de CSS3. Bien qu’en réalité CSS3 n’existe pas en tant que tel :

Contrairement à CSS2, qui est une importante spécification définissant diverses caractéristiques, CSS3 est divisé en plusieurs documents séparés appelés « modules ». Chaque module ajoute de nouvelles fonctionnalités ou étend les fonctions définies dans CSS2, sur la préservation de la rétro-compatibilité. [...] En raison de la modularisation, les différents modules sont plus ou moins stables et aboutis.

(Traduction de Cascading Style Sheets sur Wikipedia EN)

Mais entendons-nous sur le fait que nous parlons des nouvelles fonctionnalités que comprennent les navigateurs modernes.

De nos jours, CSS3 est partout : des bords arrondis aux dégradés, de la transparence aux ombres et pseudo-éléments.

Que peut-on faire ?

À mon avis, vous pouvez vous servir de CSS3 pour réduire le nombre de requêtes HTTP (images), le nombre de balises et la taille des fichiers JavaScript. Voyons cela de plus près :

  • Coin arrondi (border-radius) : 1 ligne de CSS au lieu de 4 conteneurs + 4 images
  • Opacité (opacity) et canal alpha de couleur : 1 ligne de CSS au lieu d’un PNG semi-transparent
  • Sélecteurs avancés : pas besoin de JavaScript
  • Boîte flexible (flexbox) : quelques lignes de CSS au lieu de toute une bibliothèque JavaScript
  • Dégradés (gradient) : quelques lignes de CSS au lieu d’une image d’arrière-plan répétée
  • Arrières-plans multiples (background) : pas besoin de plusieurs conteneurs
  • Pseudo-éléments (pseudo-element) : pas de balises supplémentaires pour les éléments décoratifs

Et je pourrais continuer longtemps mais je pense que vous avez compris. Ce que je veux faire passer comme message, c’est ceci : lancez-vous, et découvrez tout ce que vous pouvez faire avec CSS3. Vous devez créer une table des matières ? Sachez que vous pouvez le faire uniquement avec CSS grâce à CSS counters. Vous devez définir une bordure originale personnalisée pour un site ? Sachez qu’il existe une propriété border-image pour l’intégrer.

Vous pouvez faire un million de choses avec CSS, et c’est encore plus vrai quand il s’agit de CSS3. Il est important de savoir ce que vous pouvez faire ou pas. Malheureusement, il n’existe pas de potion magique pour cela, vous devez lire la documentation et faire des expériences. À partir de là, vous apprendrez que vous pouvez faire des calculs avec la propriété calc (), mais vous ne pourrez pas obtenir 6 colonnes d’égale hauteur sans avoir à vous battre comme un beau diable.

Apprendre ce que vous pouvez utiliser

Le plus gros problème avec CSS, c’est que tous les navigateurs ne prennent pas en charge les mêmes propriétés. Pire, certaines propriétés sont gérées de plusieurs manières différentes quand il s’agit de CSS3. Ce sera votre plus grande malédiction lors de l’expérimentation avec CSS3.

À titre d’exemple, prenez la propriété CSS3 la plus simple : border-radius (coin arrondi). Eh bien, il y a des navigateurs qui ne comprennent pas les coins arrondis (IE8 + version antérieure et Opera Mini). En fait, même Firefox et Chrome n’interprètent pas border-radius de la même façon (ou ne l’ont pas toujours fait de la même façon).

Qu’est-ce que cela signifie pour vous en tant que développeur front-end ? Cela veut dire que si vous devez afficher des coins arrondis dans tous les navigateurs, vous pouvez le faire à l’ancienne. Arrière-plans multiples + images multiples, ou alors adopter les deux solutions et servir l’une ou l’autre en fonction du navigateur.

Quand je dois faire quelque chose en CSS, voici le processus que je suis :

  1. Comment vais-je faire cela ?
  2. D’accord, je comprends. Fait-il partie de la spécification CSS2.1 ?
    1. Oui : fastoche, fin de l’histoire.
    2. Non, passez à l’étape 3.
  3. Quelle est la qualité du rendu par les navigateurs ?
    1. Bonne : fastoche, fin de l’histoire.
    2. Mauvaise, passez à l’étape 4.
  4. Est-ce une amélioration ou une fonction vitale ?
    1. C’est juste une amélioration. Je ne fais rien pour les navigateurs non pris en charge ou à la limite j’ajoute une solution de repli (fallback).
    2. Il s’agit d’une caractéristique essentielle : passez à l’étape 5.
  5. Comment vais-je le faire fonctionner dans les navigateurs non pris en charge ?

Prenons un exemple réel, d’accord ? Avec quelque chose de simple, comme un dégradé. Allons-y.

  1. Comment vais-je faire cela ?
  2. D’accord, je comprends. Fait-il partie de la spécification CSS2.1 ?
    • Non, les dégradés appartiennent à CSS3.
  3. Quelle est la qualité du rendu par les navigateurs ?
    • Pas mal, mais pas parfait. IE8 + versions antérieures ainsi qu’Opera Mini ne prennent pas en charge les dégradés CSS.
  4. Est-ce une amélioration ou une fonctionnalité vitale ?
    1. Il s’agit plutôt d’une amélioration graphique, rien de fondamental. Je vais ajouter une couleur unie comme solution de repli.
    2. C’est un élément graphique indispensable : je dois le faire fonctionner pour les navigateurs non supportés.
  5. Comment vais-je faire pour les anciens navigateurs ?
    • Je vais devoir recourir à une image d’arrière-plan.

Grâce à ce processus pas à pas, vous savez comment faire quelque chose avec CSS (si c’est faisable), si vous pouvez l’utiliser en tenant compte du support des navigateurs et comment créer des solutions de repli.

NB : souvenez-vous toujours de l’audience cible de votre site web ou de votre application. Si vous créez du contenu web pour une application iPad, vous pourrez utiliser de nombreuses propriétés CSS3 sans vous soucier des solutions de repli. Toutefois si vous créez un site pour une banque, rappelez-vous que beaucoup de gens utilisent encore IE8 ou des versions plus anciennes encore.

Fournir des solutions de repli

Selon la situation, fournir une solution de repli pour les navigateurs non pris en charge peut être soit ridiculement simple soit extrêmement pénible. En effet, il y a des cas différents. Regardons cela de plus près.

Pas de solution de repli ou une solution de repli simple

Quand il y a une amélioration de l’expérience utilisateur dont l’absence de prise en charge est sans conséquences, vous n’êtes même pas obligés de fournir une solution de repli. C’est appréciable.

Il y a aussi quelques propriétés qui sont faciles à traiter quand il s’agit de solution de repli. En général, vous devez seulement écrire deux versions de cette propriété : d’abord la solution de repli, puis la version correcte pour les navigateurs qui le supportent.

.mon-element { border: 1px solid #666; border: 1px solid rgba(0,0,0,0.3); background: #708090; background: hsl(210, 13%, 50%);
}

Dans ce cas, les navigateurs ne supportant pas rgba et hsl ne liront pas les lignes 3 et 5 ; de ce fait vous fournissez des versions alternatives aux lignes 2 et 4. Pour les navigateurs pris en charge, ils vont d’abord appliquer la version alternative, puis la remplacer par la version correcte.

Modernizr

De nos jours, on ne peut guère parler de CSS3 sans mentionner Modernizr. Il s’agit d’une bibliothèque JavaScript qui teste la prise en charge des fonctionnalités HTML5 et CSS3 au chargement de la page. Cela peut sembler lourd, mais il est bien optimisé et assez rapide.

Quoi qu’il en soit, parfois, il faut savoir précisément si le navigateur prend en charge une fonctionnalité particulière. Notamment pour fournir une version alternative nécessitant d’autres propriétés CSS.

/* Version normale */
.menu-deroulant { opacity: 0; pointer-events: none;
} .declencheur:hover .menu-deroulant { opacity: 1; pointer-events: auto;
} /* Solution de repli avec Modernizr */ .no-opacity .menu-deroulant,
.no-pointerevents .menu-deroulant { opacity: 1;
pointer-events: auto;
display: none;
} .no-opacity .declencheur:hover .menu-deroulant,
.no-pointerevents .declencheur:hover .menu-deroulant { display: block;
}

Pour fournir une solution de repli de ce type, les classes ajoutées par la bibliothèque Javascript Modernizr vous seront d’un grand secours (.no-opacity [sans-opacite] et .no-pointerevents [sans-evenementpointeur]). Vous ne pouvez pas avoir les deux versions simultanément.

Quoi qu’il en soit, n’oubliez jamais de définir une solution de repli, c’est vraiment important. Les fonctionnalités majeures doivent être prises en charge par tous les navigateurs, tant les anciens que les nouveaux, et si ce n’est pas le cas partout, vous devez avertir l’utilisateur.

Donc, soit vous commencez avec une base simple et l’améliorez pour les navigateurs récents, soit vous commencez avec une base moderne et vous composez pour les navigateurs plus anciens. Voir la section suivante pour plus d’informations.

Autres ressources sur CSS3 :

6. Amélioration progressive et dégradation élégante

Ce sont deux termes dont vous avez probablement déjà entendu parler, en particulier la dégradation élégante, mais il y a une différence subtile entre les deux.

Amélioration progressive

Le principe de l’amélioration progressive est d’établir une base commune de fonctionnalités et de fonctions disponibles, et ensuite, d’améliorer l’expérience utilisateur en fonction de ce que le navigateur prend en charge.

Utiliser l’attribut HTML5 required pour avertir l’utilisateur qu’un champ est manquant dans un formulaire avant de le soumettre peut être considéré comme une amélioration progressive. Il s’agit d’une amélioration de l’expérience utilisateur rendue possible grâce au moteur natif du navigateur.

Dégradation élégante

Vous utilisez la dégradation élégante lorsque vous déclinez une version alternative ou inférieure de vos fonctionnalités au cas où elles ne sont pas prises en charge. Fondamentalement, on part du plus haut pour aller vers le plus bas.

Un exemple très simple serait l’avertissement que vous mettez entre les balises <canvas> pour informer les utilisateurs de navigateurs qui ne les prennent pas en charge qu’il y a quelque chose qu’ils ne peuvent pas voir.

<canvas>
Cette page utilise HTML5 Canvas. Veuillez utiliser un navigateur récent pour voir ce contenu. Pour obtenir un autre navigateur, allez à <a href="http://browsehappy.com/">BrowseHappy</a>
</canvas>

Quelle est la différence ?

En fin de compte, il n’y en a pas. Vous avez des fonctionnalités pour les navigateurs récents et des fonctionnalités ou des solutions de repli pour les plus anciens. C’est plutôt une question de procédure : soit vous codez pour les navigateurs modernes tout en proposant une solution de repli pour les anciens, soit vous le faites dans l’autre sens. C’est un choix.

En tout cas, je veux redire ici que l’expérience utilisateur n’est pas nécessairement la même dans tous les navigateurs. En fait, ce n’est même pas possible, puisque les moteurs des navigateurs sont différents. Quoi qu’il en soit, vous devez fournir des fonctionnalités de base pour tout le monde, mais faites-moi plaisir : améliorez votre site web ou votre application pour les navigateurs modernes. Ils sont bien conçus, ils fournissent des fonctionnalités à l’état natif : utilisez-les.

Lectures complémentaires sur l’amélioration progressive et la dégradation élégante

7. Les préprocesseurs CSS

Aaaah, les préprocesseurs… Le sujet chaud du moment. Sont-ils utiles ? Pour quoi faire ? Devrais-je en employer un ? Lequel ? Je pense que c’est l’un des sujets les plus débattus sur CSS en ce moment.

Je vais essayer d’être aussi objectif que possible dans cette partie. Permettez-moi de commencer par ceci : si vous ne voulez pas utiliser un préprocesseur, alors ne le faites pas. Ce ne sera jamais un problème. Vous ne serez pas un mauvais développeur front-end pour autant. Cela ne vous rendra pas incapable de faire certaines choses. Mais vous devriez, néanmoins, essayer de vous faire votre propre opinion à ce sujet.

Ok, j’en ai fini avec les précautions. Qu’est-ce qu’un préprocesseur, de manière générale ? Un préprocesseur est une sorte d’outil qui compile une syntaxe donnée dans une langue utilisée par un autre programme (dans le cas présent : le navigateur). Il y a des préprocesseurs pour de nombreux languages : il y a Markdown ou Jade pour le HTML. Il y a LESS, Sass et Stylus pour CSS. Il existe CoffeeScript pour JavaScript. Il y a CakePHP pour PHP et ainsi de suite.

De quoi parle-t-on ?

Un préprocesseur CSS fournit aux CSS certaines particularités à partir de langages orientés objet. Des choses comme :

  • les variables
  • les fonctions (avec des paramètres)
  • les espaces de nommages
  • l’imbrication
  • les instructions conditionnelles
  • les opérations
  • etc.

Ça a l’air attrayant, non ? Peut-être que vous voulez un exemple pour comprendre la manière dont cela fonctionne. Prenons le CSS suivant pour une barre de navigation.

.navigation { width: 800px; width: calc(100%-150px);
}
.navigation li { color: #444;
}
.navigation li a { text-decoration: none;
}

Et voici maintenant la version compilée (SCSS) :

$couleur-principale: #444; .navigation { width: (100%-150px); li { color: $couleur-principale; a { text-decoration: none; } }
}

En gros, un préprocesseur va interpréter ceci dans une version CSS standard. Ce sera exactement la même chose, sauf pour le calcul. Il lancera l’opération elle-même et affichera le résultat correspondant sans qu’il soit nécessaire d’utiliser une fonction comme calc().

Donc, vous vous retrouvez avec une feuille de style plus compréhensible (variables et imbrications) et plus facile à maintenir (variables et fonctions). C’était un exemple très théorique, mais dans un projet réel, vous sentirez la différence.

Comment le choisir ?

Il existe beaucoup de préprocesseurs CSS, chacun avec ses avantages et ses particularités. Quoi qu’il en soit, chacun d’entre eux fait plus ou moins la même chose, donc le choix vous appartient. Voici les principales options quand il s’agit de préprocesseurs CSS :

  • Sass (écrit en Ruby)
  • LESS (écrit en JavaScript)
  • Stylus (écrit en JavaScript)
  • Crush (écrit en PHP)

L’idéal, c’est d’apprendre à les connaître, de les tester et de voir ce qui répond le mieux à vos besoins et à votre projet. Il y a plusieurs facteurs qui entrent en jeu ; les énumérer tous serait hors de la portée de cet article, mais vous pouvez trouver quelques ressources pertinentes ci-dessous.

Mon sentiment sur les préprocesseurs CSS ?

Je ne suis pas un expert quand il s’agit de préprocesseurs CSS, mais j’en suis un partisan. Ils fournissent des fonctionnalités très utiles mais qu’on ne trouve pas dans les CSS comme les variables, les déclarations, l’imbrication et les conditions.

J’ai bricolé un peu avec LESS, et il m’a fait à peu près ce que je voulais. Ou du moins, jusqu’à ce que je commence à me lancer dans des choses un peu plus compliquées que vous avez pu lire dans mon dernier article sur CSS Loading Animations (pour les boucles + préfixes vendeurs + keyframes).

J’ai aussi jeté un coup d’œil rapide à Sass et Compass. À ma grande surprise, c’était incroyablement facile à installer et à lancer grâce à Ruby. J’avais peur, mais c’est très très intuitif, croyez-moi. En fin de compte, je suis vraiment impressionné par l’association Sass + Compass. Vous pouvez également en savoir plus sur les raisons pour lesquelles je suis passé de LESS à Sass dans cet article sur mon blog.

Quoi qu’il en soit, je suis encore tout à fait capable d’écrire des CSS classiques sans préprocesseur, et la plupart du temps c’est ce que je fais. Mais au final, je pense que nous allons tous en utiliser un, quel qu’il soit. Il nous manque vraiment certains éléments très utiles avec les CSS, et les préprocesseurs CSS sont là pour y remédier.

Lectures complémentaires sur les préprocesseurs CSS

8. Garder un œil sur l’avenir

Les langages sont en constante évolution. C’est particulièrement vrai pour les CSS. Les spécifications CSS bougent sans cesse, et les navigateurs ajoutent sans cesse de nouvelles fonctionnalités à leurs moteurs.

À ce propos, mon premier conseil serait de rester à l’écoute de ce qui se prépare. Je sais que vous ne pouvez pas être en mesure de tout utiliser dès son lancement, mais savoir quelle fonctionnalité est maintenant prise en charge par Canary Chrome, bientôt par Chrome version stable et Safari, puis par Opera, Firefox et ainsi de suite, c’est important afin de prendre du recul sur les problèmes CSS et les solutions possibles.

Ressources pour garder un œil sur l’avenir :

9. Lire le code des autres

Une des meilleures façons d’apprendre à coder est de lire du code.

Heureusement, le CSS est visible côté client, ce qui vous permet de le lire sur n’importe quel site avec un inspecteur web comme WebKit inspector, Dragonfly, Firebug, etc. De plus, l’industrie du web est très orientée vers l’open-source, ce qui signifie que les gens sont heureux de partager leurs sources avec vous.

Une autre excellente façon d’apprendre est de suivre des tutoriels. Prenez un tutoriel simple, et suivez-le étape par étape. Ensuite, essayez de le refaire à partir de zéro. S’il vous arrive d’être bloqué, jetez un coup d’œil à la solution, puis continuez par vous-même.

Lorsque vous serez à l’aise avec CSS et que vous voudrez entrer finement dans les détails, vous voudrez peut-être jeter un œil à des démonstrations et des expériences qui ne sont pas commentées ni expliquées. Les gens créent des choses tous les jours, et vous tomberez sans arrêt sur des choses que vous ne connaissiez pas encore.

À ce sujet, il y a quelques mois Chris Coyier, Tim Sabat et Alex Vazquez ont lancé CodePen, une sorte de plate-forme pour créer, partager et explorer du code (HTML, CSS, JavaScript). CodePen comprend également un tas d’outils comme les bibliothèques (jQuery, jQuery UI, MooTools, YUI, Prototype, Zepto, Dojo, Ext JS, PrefixFree, etc) et les préprocesseurs (HAML, Markdown, Slim, LESS, SCSS, Sass, CoffeeScript) si vous en avez besoin.

D’autres ressources pour trouver des exemples de code créé par d’autres personnes :

10. Pratiquez sans relâche

Vous savez ce qu’on dit à propos de l’apprentissage : on apprend en faisant. Donc, mon meilleur conseil est de continuer à pratiquer comme pour toute autre chose. Plus vous pratiquez, meilleur vous serez. La pratique ne signifie pas nécessairement faire un site web à partir de zéro. Il suffit de choisir une capture simple sur Dribbble et d’essayer de la refaire en CSS. Le résultat ne sera peut-être pas utile immédiatement, mais ce que vous avez appris vous sera utile un jour.

Et comme je l’ai dit dans la partie « Apprendre les bases et quelques astuces » de cet article, CSS est plein de cas particuliers. Vous devrez apprendre à les gérer si vous voulez écrire des CSS. Et la seule façon de connaître ces cas particuliers consiste à pratiquer, découvrir de nouveaux cas, jeter un œil à la solution, et continuer.

Je vous recommande aussi de partager votre code. Il est toujours utile d’obtenir un retour constructif, alors assurez-vous de demander aux gens de vérifier votre code une fois qu’il est presque fini. Il suffit de les déposer dans un JSFiddle, de partager et de demander des commentaires.

Sommaire et crédits

Comme cet article mentionne un tas de liens et de ressources diverses, autant les rassembler tous au même endroit :

Merci beaucoup d’avoir lu cet article. J’espère qu’il vous aidera d’une manière ou d’une autre à améliorer la façon dont vous apprenez et utilisez les CSS.

]]> http://www.pompage.net/traduction/ameliorer-vos-feuilles-de-styles http://www.pompage.net/traduction/ameliorer-vos-feuilles-de-styles Thu, 19 Jun 2014 03:06:00 +0200 <![CDATA[Principes à connaître pour améliorer vos feuilles de styles]]>

Par Hugo Giraudel

Cet article passe en revue quelques principes de base et astuces tirés de mon expérience personnelle pour apprendre à devenir meilleur en CSS. Dans cet article, je vais parler avant tout de ma propre expérience et de ce que j’ai appris sur CSS pendant près d’un an et demi de pratique intensive.

Tout d’abord, laissez-moi vous rappeler que CSS est un langage extrêmement simple. Il peut se résumer en 3 mots : sélecteur, propriété, valeur. Et c’est à peu près tout. C’est pourquoi certaines personnes n’aiment pas du tout CSS car elles ont l’impression d’être comme des enfants qui jouent aux Legos.

En effet, il suffit d’expliquer les bases de CSS à un enfant de 9 ans pour qu’il ou elle soit en mesure de créer un site web. Pas un site compliqué bien entendu, mais peut-être quelques pages avec des titres, des liens, du contenu, des images, quelque chose dans ce goût-là.

Toutefois, le fait que CSS soit un langage simple ne veut pas dire que tout le monde soit au même niveau. Certaines personnes utilisent CSS comme un chimpanzé se sert d’une fourchette, certaines personnes se débrouillent pas mal avec et d’autres peuvent faire des choses formidables.

De ce que je peux en dire, je m’amuse avec CSS depuis près de deux ans maintenant et je pratique à un niveau disons « intensif » depuis près de sept mois. Je suis encore loin de la perfection et il y a toujours des astuces que je ne connais pas ou que je ne comprends pas.

Quoi qu’il en soit, voici quelques trucs que j’ai compris au cours des mois écoulés et que j’aimerais partager avec vous. Encore une fois ce ne sont pas des bouts de code ou des astuces utiles, ce sont plutôt des principes généraux et des bonnes pratiques. Voici ce que je vais aborder :

  1. Ne pas se ruer sur le code et faire simple
  2. Apprendre les bases et quelques astuces
  3. Ne pas se répéter
  4. CSS orienté objet
  5. CSS3 : apprendre ce que l’on peut faire et ce que l’on peut utiliser
  6. Amélioration progressive et dégradation élégante
  7. Les préprocesseurs CSS
  8. Garder un œil sur l’avenir
  9. Lire le code des autres
  10. Pratiquer sans relâche

Qu’en dites-vous ? Vous êtes prêts ? Allez, c’est parti.

1. Ne vous ruez pas sur le code et faites au plus simple

Ne vous ruez pas sur le code

C’est plutôt un conseil général, qui n’est pas spécifique à CSS. Quand vous êtes sur le point de commencer à développer, réfléchissez d’abord à ce que vous allez faire. Posez-vous quelques questions :

  • Comment vais-je faire ça ?
  • Y a-t-il une autre manière de faire ?
  • Comment puis-je l’optimiser (pour que ce soit maintenable, propre, cool, etc.) ?

Commencer à coder sans réfléchir peut vous faire perdre du temps. Imaginez-vous passer une heure à créer quelque chose pour vous apercevoir que c’est sans issue et que vous devez tout recommencer depuis le début ? C’est hors de question.

Passer des heures sur un diaporama en CSS pour finir avec SlidesJS ou Adaptor, c’est vraiment nul. Non pas parce que vous avez échoué, mais parce que c’était une perte de temps. Vous pourriez le payer très cher, le jour où vous serez soumis à des délais très serrés.

Faites simple

CSS est un langage simple mais les choses peuvent facilement devenir complexes. Surtout si vous voulez qu’elles le deviennent. Dans la plupart des cas, l’idée la plus simple est souvent la meilleure. Quand vous devez réaliser quelque chose, demandez-vous toujours s’il n’y a pas un moyen plus simple de le faire. Vous seriez surpris du nombre de fois où la réponse est « oui ».

Par exemple, si vous voulez coder une barre de navigation horizontale vraiment simple qui ne comporte que des liens, vous avez plusieurs façons de faire :

  • Faire flotter les éléments de la liste
  • Passer les éléments de la liste en ligne
  • Passer les éléments de la liste en blocs en ligne (inline-block)

Choisissez le plus simple et transformez les éléments de liste en éléments en ligne. Pas besoin de hack pour nettoyer les flottants. Pas besoin de corriger l’espacement des éléments en ligne. Il y a juste besoin d’un espacement interne classique, rien de plus. Fin de chantier.

2. Connaître les bases et apprendre les astuces

Pour devenir bon en CSS ou quoi que ce soit d’autre dans la vie, vous devez connaître les bases. Vous ne deviendrez jamais un expert si vous n’êtes pas à l’aise avec les bases de la discipline.

Les bases de CSS

Quelles sont les bases de CSS ? Selon les personnes, vous aurez droit à différentes versions, c’est plus de l’ordre du ressenti, mais si vous voulez mon avis, il y a deux choses à comprendre avant tout pour vraiment se familiariser avec CSS :

  • Le modèle de boîte. Chaque élément en CSS est une boîte (de type bloc ou en ligne) avec une largeur, une hauteur, et éventuellement des espacements, des marges et des bordures. C’est la chose la plus importante à savoir. Vous en saurez davantage ici.
  • La spécificité. Pour pouvoir corriger vos CSS, il est essentiel de savoir quelle règle est plus forte que quelle autre. Pour plus d’informations sur le sujet, lisez les spécifications : L’assignation des valeurs des propriétés, la cascade et l’héritage.

Les astuces

Une fois que vous avez compris ça, vous êtes sur la bonne voie. À partir de là, vous n’aurez qu’à apprendre quelques astuces pour vous débrouiller avec les cas spécifiques. Et vous n’avez pas fini d’en croiser. Laissez-moi vous en montrer quelques-unes.

Le coup du « j’ai oublié de positionner l’élément parent »

.enfant { position: absolute; top: 0; left: 0;
} /* Ceci a été oublié */
/*
.parent { position: relative; // Ou n’importe quelle autre valeur que static.
}
*/

Et c’est là que vous vous dites : « Hein ?! Mais pourquoi est-ce que mon élément est en haut à gauche de la page ? » Eh oui : vous avez oublié de définir la position de l’élément parent (relative, absolute, tout ce que vous voulez sauf static).

Le coup du « contexte d’imbrication »

.parent { z-index: 1; opacity: 0.5; transform: rotate(5deg);
} .enfant { z-index: -1;
}

Tous les développeurs au monde ont bataillé au moins une fois sur le sujet de l’imbrication de boîtes. En résumé, il est tout simplement impossible d’appliquer un z-index à un enfant d’un élément (ou d’un pseudo-élément) qui possède déjà un contexte d’imbrication (déclenché soit par z-index, opacity ou transform) ; il n’y a pas d’autres possibilités. Une fois que vous maîtrisez ça, impossible de l’oublier, promis.

NB : pour plus d’information à propos de z-index et de l’imbrication CSS, je vous recommandece superbe billet de Steven Bradley.

Le coup du « J’ai oublié d’effacer le flottant »
Votre mise en page devient folle. Les blocs se baladent n’importe où. Vous pleurez sans comprendre les raisons de cet affichage étrange. Alors vérifiez vos flottants ! Dans la plupart des cas, c’est que vous avez oublié de les réinitialiser.

Note : dans le cas où un parent contient uniquement des éléments flottants, il va se réduire à moins que vous n’annulez les flottants, ou alors que vous définissiez une hauteur ou un overflow (NdT : propriété définissant les dépassements de blocs ou comment le contenu est rogné : si le contenu dépasse les dimensions d’un bloc, overflow permet de cacher le contenu, d’afficher une barre de défilement ou pas).

Je pourrais continuer pendant des heures sur ces sujets, mais ce n’est pas le but de cet article. Je dirais que CSS présente un grand nombre de cas particuliers et on en découvre encore chaque jour. Tant que vous ne vous serez pas cassé les dents dessus, vous ne saurez pas qu’ils existent ; mais ensuite, vous saurez comment les traiter.

3. DRY

DRY est l’acronyme de Don’t Repeat Yourself (Ne pas se répéter, NdT), et encore une fois ce n’est pas spécifique à CSS. Il s’agit plutôt d’une pratique répandue lorsque vous codez, quel que soit le langage avec lequel vous avez à composer.

Ainsi, l’idée principale est d’éviter de répéter les mêmes bouts de code X fois alors qu’une seule fois pourrait suffire. Dans certains langages, cela peut évoquer l’utilisation d’une fonction, mais en CSS, cela signifie utiliser une classe plutôt que cibler un élément spécifique (voir plus loin la section concernant OOCSS). Pourtant, parfois il existe une chose vraiment simple comme la mutualisation de son code (refactoring). Laissez-moi vous expliquer.

Si vous êtes en présence d’un bout de code qui est présent plusieurs fois dans votre feuille de style, il pourrait être intéressant de le mutualiser (refactoriser) afin de n’avoir plus qu’une seule occurrence. Lisez ce qui suit :

.navigation li { color: #333;
} .navigation li a { color: #333;
} /* Mutualisé */ .navigation li,
.navigation li a { color: #333;
}

Vous voyez ? Vous vous demandez peut-être quel est l’intérêt, puisque le résultat est le même. Il y a deux choses à prendre en compte : la performance et la facilité de maintenance.

À propos de la performance : moins de lignes de code signifie un parcours plus rapide de la CSS par le navigateur. Pour faire simple, le navigateur va appliquer la couleur aux deux règles à la fois au lieu de le faire deux fois.

À propos de la maintenance, je pense que cela parle de soi-même. En procédant de la sorte, vous avez seulement une ligne à changer alors qu’avant vous deviez en changer deux pour modifier la couleur. Qu’en est-il quand vous avez 50 fois ou 300 fois le même code ?

Plus d’informations sur DRY CSS

4. OOCSS

C’est quoi ce truc ?

OOCSS est l’acronyme d’Object-Oriented CSS (CSS Orienté Objet, NdT) . Vous avez probablement entendu parler de la programmation orientée objet. Il s’agit tout bonnement d’utiliser des « objets », généralement des instances de classes (qui se composent d’attributs et de méthodes). J’imagine que vous vous demandez quel peut être le rapport avec CSS ?

Premièrement, disons que c’est plus un concept ou une bonne pratique qu’un vrai principe. CSS ne peut pas vraiment être orienté objet sachant que ce n’est pas un langage de programmation : pas d’espace de nommage, pas de fonctions, pas de méthodes, pas de classes de programmation, aucune des instructions conditionnelles, etc. C’est pourquoi certaines personnes ricaneront quand vous parlerez d’OOCSS.

Même si je suis d’accord avec cela, malgré tout nous pouvons encore optimiser notre façon de coder les CSS pour faciliter le processus, rendre les sites Web plus rapides et améliorer la maintenabilité.

Comment faire ?

Pour le dire simplement, cela signifie utiliser des classes. Un grand nombre de classes. Pensez à votre site comme s’il possédait des « modules » ou des « composants », si vous voulez. Essayez de repérer les modèles qui se répètent pour en faire des « objets » (classes) afin de les réutiliser.

Pour être un peu plus précis, cela signifie essentiellement deux choses :

  • Séparer structure et apparence
  • Séparer conteneurs et contenu

Séparer structure et apparence

Séparer la structure et l’apparence peut se révéler important : vous savez que des éléments graphiques peuvent être utilisés à plusieurs endroits sur un site web et sur plusieurs types d’éléments­­­­, n’est-ce pas ? Prenez le bout de code suivant, cela peut convenir à un bouton, à une image, ce que vous voulez :

#mon-bouton,
.ma-boite
.ma-boite img { border: 1px solid #444; border-radius: 5px; box-shadow: 0 0 5px rgba(0,0,0,0.1);
}

Maintenant, au lieu de ce qui précède, nous pourrions créer une classe qu’on appellerait « habillage » (skin) ou quelque chose comme ça, et l’appliquer aux éléments qui en ont besoin. Le résultat est beaucoup plus compréhensible, la feuille de style plus maintenable et une interprétation de classes plus rapide.

.habillage { border: 1px solid #444; border-radius: 5px; box-shadow: 0 0 5px rgba(0,0,0,0.1);
}

Séparer conteneurs et contenu

Je pense que c’est l’une des règles les plus importantes de OOCSS : coder des composants indépendants, pas des bouts de code pour un élément spécifique de votre modèle. Les choses devraient être réutilisables, quelle que soit leur place sur votre site Internet, sans les coder à nouveau. Prenons l’exemple suivant :

#principal h2 { color: #343434; font-size: 25px; line-height: 20px; border-bottom: 1px solid rgba(0,0,0,0.2); box-shadow: 0 1px rgba(255,255,255,0.4);
}

D’accord. Maintenant, si je veux exactement le même style sur un titre de niveau 2 placé dans le pied de page ? Ou bien mettre en forme un titre de niveau 3 placé exactement de la même manière (quelle qu’en soit la raison) ? La meilleure façon de faire consisterait à créer une classe et à donner ces styles à cette classe, pas aux éléments eux-mêmes.

Qu’en est-il du « ne jamais utiliser d’ID » ?

Quand Nicole Sullivan a découvert le concept de CSS orienté-objet, ce fut un sujet chaud. En effet CSSLint, un outil de qualité du code CSS créé par Nicholas C. Zakas et Nicole Sullivan, déconseille l’utilisation des sélecteurs d’ID.

Pour comprendre le point de vue de Nicole, il est important de comprendre que les ID peuvent poser certains problèmes de priorité, car ils ont le score le plus élevé dans ce domaine. Prenez le code suivant à titre d’exemple (à voir sur CSSWizardry - source ici) :

<!-- HTML -->
<div id="en-tete"> <p> <a href="#">Foo</a> <a href="#">Bar</a> </p> <div class="tweet"> <a href="#">Suivez-moi sur twitter</a> </div>
</div>
<div class="tweet"> <a href="#">Suivez-moi sur twitter</a>
</div> /* CSS */
#en-tete a { color: #f90; }
.tweet a { color: #000; }

Pour mettre le premier lien Twitter en noir, vous avez deux options : soit lui donner une ID, soit utiliser le lourdaud <important!>. Si #en-tete était une classe au lieu d’une ID, le problème n’aurait pas existé.

C’est en partie la raison pour laquelle Nicole Sullivan a dit « pas d’ID ».

Je finirai cette partie par la citation de Harry Roberts sur le sujet : « [...] J’ai décidé qu’une interdiction générale était l’option la plus logique. Épargnez-vous beaucoup de soucis : n’utilisez jamais d’ID dans vos fichiers CSS ».

Bien sûr, il est tout à fait possible d’utiliser des IDs qui restent parfaitement valides.

Quel est mon sentiment sur OOCSS ?

En ce qui me concerne, je ne suis pas vraiment un expert sur le sujet. D’abord parce que je n’ai jamais travaillé sur un site énorme impliquant de nombreux développeurs front-end. Ne nous leurrons pas, c’est sans doute très utile pour les sites de grande importance, mais pas forcément pour le petit site que vous faites pour votre boulanger.
Cependant, même si je n’utilise pas OOCSS dans mes projets, j’essaie de me concentrer sur les choses importantes comme la réutilisation des composants, la maintenabilité de la feuille de style, la performance et autres. Ce sont les choses sur lesquelles OOCSS se concentre, donc d’une certaine façon, je ne suis pas si loin de la logique.

Autres ressources sur OOCSS et les IDs

5. CSS3 : découvrez ce que vous pouvez faire et ce que vous pouvez utiliser

Bon, assez de concepts. Parlons de choses sérieuses. Parlons un peu de CSS3. Bien qu’en réalité CSS3 n’existe pas en tant que tel :

Contrairement à CSS2, qui est une importante spécification définissant diverses caractéristiques, CSS3 est divisé en plusieurs documents séparés appelés « modules ». Chaque module ajoute de nouvelles fonctionnalités ou étend les fonctions définies dans CSS2, sur la préservation de la rétro-compatibilité. [...] En raison de la modularisation, les différents modules sont plus ou moins stables et aboutis.

(Traduction de Cascading Style Sheets sur Wikipedia EN)

Mais entendons-nous sur le fait que nous parlons des nouvelles fonctionnalités que comprennent les navigateurs modernes.

De nos jours, CSS3 est partout : des bords arrondis aux dégradés, de la transparence aux ombres et pseudo-éléments.

Que peut-on faire ?

À mon avis, vous pouvez vous servir de CSS3 pour réduire le nombre de requêtes HTTP (images), le nombre de balises et la taille des fichiers JavaScript. Voyons cela de plus près :

  • Coin arrondi (border-radius) : 1 ligne de CSS au lieu de 4 conteneurs + 4 images
  • Opacité (opacity) et canal alpha de couleur : 1 ligne de CSS au lieu d’un PNG semi-transparent
  • Sélecteurs avancés : pas besoin de JavaScript
  • Boîte flexible (flexbox) : quelques lignes de CSS au lieu de toute une bibliothèque JavaScript
  • Dégradés (gradient) : quelques lignes de CSS au lieu d’une image d’arrière-plan répétée
  • Arrières-plans multiples (background) : pas besoin de plusieurs conteneurs
  • Pseudo-éléments (pseudo-element) : pas de balises supplémentaires pour les éléments décoratifs

Et je pourrais continuer longtemps mais je pense que vous avez compris. Ce que je veux faire passer comme message, c’est ceci : lancez-vous, et découvrez tout ce que vous pouvez faire avec CSS3. Vous devez créer une table des matières ? Sachez que vous pouvez le faire uniquement avec CSS grâce à CSS counters. Vous devez définir une bordure originale personnalisée pour un site ? Sachez qu’il existe une propriété border-image pour l’intégrer.

Vous pouvez faire un million de choses avec CSS, et c’est encore plus vrai quand il s’agit de CSS3. Il est important de savoir ce que vous pouvez faire ou pas. Malheureusement, il n’existe pas de potion magique pour cela, vous devez lire la documentation et faire des expériences. À partir de là, vous apprendrez que vous pouvez faire des calculs avec la propriété calc (), mais vous ne pourrez pas obtenir 6 colonnes d’égale hauteur sans avoir à vous battre comme un beau diable.

Apprendre ce que vous pouvez utiliser

Le plus gros problème avec CSS, c’est que tous les navigateurs ne prennent pas en charge les mêmes propriétés. Pire, certaines propriétés sont gérées de plusieurs manières différentes quand il s’agit de CSS3. Ce sera votre plus grande malédiction lors de l’expérimentation avec CSS3.

À titre d’exemple, prenez la propriété CSS3 la plus simple : border-radius (coin arrondi). Eh bien, il y a des navigateurs qui ne comprennent pas les coins arrondis (IE8 + version antérieure et Opera Mini). En fait, même Firefox et Chrome n’interprètent pas border-radius de la même façon (ou ne l’ont pas toujours fait de la même façon).

Qu’est-ce que cela signifie pour vous en tant que développeur front-end ? Cela veut dire que si vous devez afficher des coins arrondis dans tous les navigateurs, vous pouvez le faire à l’ancienne. Arrière-plans multiples + images multiples, ou alors adopter les deux solutions et servir l’une ou l’autre en fonction du navigateur.

Quand je dois faire quelque chose en CSS, voici le processus que je suis :

  1. Comment vais-je faire cela ?
  2. D’accord, je comprends. Fait-il partie de la spécification CSS2.1 ?
    1. Oui : fastoche, fin de l’histoire.
    2. Non, passez à l’étape 3.
  3. Quelle est la qualité du rendu par les navigateurs ?
    1. Bonne : fastoche, fin de l’histoire.
    2. Mauvaise, passez à l’étape 4.
  4. Est-ce une amélioration ou une fonction vitale ?
    1. C’est juste une amélioration. Je ne fais rien pour les navigateurs non pris en charge ou à la limite j’ajoute une solution de repli (fallback).
    2. Il s’agit d’une caractéristique essentielle : passez à l’étape 5.
  5. Comment vais-je le faire fonctionner dans les navigateurs non pris en charge ?

Prenons un exemple réel, d’accord ? Avec quelque chose de simple, comme un dégradé. Allons-y.

  1. Comment vais-je faire cela ?
  2. D’accord, je comprends. Fait-il partie de la spécification CSS2.1 ?
    • Non, les dégradés appartiennent à CSS3.
  3. Quelle est la qualité du rendu par les navigateurs ?
    • Pas mal, mais pas parfait. IE8 + versions antérieures ainsi qu’Opera Mini ne prennent pas en charge les dégradés CSS.
  4. Est-ce une amélioration ou une fonctionnalité vitale ?
    1. Il s’agit plutôt d’une amélioration graphique, rien de fondamental. Je vais ajouter une couleur unie comme solution de repli.
    2. C’est un élément graphique indispensable : je dois le faire fonctionner pour les navigateurs non supportés.
  5. Comment vais-je faire pour les anciens navigateurs ?
    • Je vais devoir recourir à une image d’arrière-plan.

Grâce à ce processus pas à pas, vous savez comment faire quelque chose avec CSS (si c’est faisable), si vous pouvez l’utiliser en tenant compte du support des navigateurs et comment créer des solutions de repli.

NB : souvenez-vous toujours de l’audience cible de votre site web ou de votre application. Si vous créez du contenu web pour une application iPad, vous pourrez utiliser de nombreuses propriétés CSS3 sans vous soucier des solutions de repli. Toutefois si vous créez un site pour une banque, rappelez-vous que beaucoup de gens utilisent encore IE8 ou des versions plus anciennes encore.

Fournir des solutions de repli

Selon la situation, fournir une solution de repli pour les navigateurs non pris en charge peut être soit ridiculement simple soit extrêmement pénible. En effet, il y a des cas différents. Regardons cela de plus près.

Pas de solution de repli ou une solution de repli simple

Quand il y a une amélioration de l’expérience utilisateur dont l’absence de prise en charge est sans conséquences, vous n’êtes même pas obligés de fournir une solution de repli. C’est appréciable.

Il y a aussi quelques propriétés qui sont faciles à traiter quand il s’agit de solution de repli. En général, vous devez seulement écrire deux versions de cette propriété : d’abord la solution de repli, puis la version correcte pour les navigateurs qui le supportent.

.mon-element { border: 1px solid #666; border: 1px solid rgba(0,0,0,0.3); background: #708090; background: hsl(210, 13%, 50%);
}

Dans ce cas, les navigateurs ne supportant pas rgba et hsl ne liront pas les lignes 3 et 5 ; de ce fait vous fournissez des versions alternatives aux lignes 2 et 4. Pour les navigateurs pris en charge, ils vont d’abord appliquer la version alternative, puis la remplacer par la version correcte.

Modernizr

De nos jours, on ne peut guère parler de CSS3 sans mentionner Modernizr. Il s’agit d’une bibliothèque JavaScript qui teste la prise en charge des fonctionnalités HTML5 et CSS3 au chargement de la page. Cela peut sembler lourd, mais il est bien optimisé et assez rapide.

Quoi qu’il en soit, parfois, il faut savoir précisément si le navigateur prend en charge une fonctionnalité particulière. Notamment pour fournir une version alternative nécessitant d’autres propriétés CSS.

/* Version normale */
.menu-deroulant { opacity: 0; pointer-events: none;
} .declencheur:hover .menu-deroulant { opacity: 1; pointer-events: auto;
} /* Solution de repli avec Modernizr */ .no-opacity .menu-deroulant,
.no-pointerevents .menu-deroulant { opacity: 1;
pointer-events: auto;
display: none;
} .no-opacity .declencheur:hover .menu-deroulant,
.no-pointerevents .declencheur:hover .menu-deroulant { display: block;
}

Pour fournir une solution de repli de ce type, les classes ajoutées par la bibliothèque Javascript Modernizr vous seront d’un grand secours (.no-opacity [sans-opacite] et .no-pointerevents [sans-evenementpointeur]). Vous ne pouvez pas avoir les deux versions simultanément.

Quoi qu’il en soit, n’oubliez jamais de définir une solution de repli, c’est vraiment important. Les fonctionnalités majeures doivent être prises en charge par tous les navigateurs, tant les anciens que les nouveaux, et si ce n’est pas le cas partout, vous devez avertir l’utilisateur.

Donc, soit vous commencez avec une base simple et l’améliorez pour les navigateurs récents, soit vous commencez avec une base moderne et vous composez pour les navigateurs plus anciens. Voir la section suivante pour plus d’informations.

Autres ressources sur CSS3 :

6. Amélioration progressive et dégradation élégante

Ce sont deux termes dont vous avez probablement déjà entendu parler, en particulier la dégradation élégante, mais il y a une différence subtile entre les deux.

Amélioration progressive

Le principe de l’amélioration progressive est d’établir une base commune de fonctionnalités et de fonctions disponibles, et ensuite, d’améliorer l’expérience utilisateur en fonction de ce que le navigateur prend en charge.

Utiliser l’attribut HTML5 required pour avertir l’utilisateur qu’un champ est manquant dans un formulaire avant de le soumettre peut être considéré comme une amélioration progressive. Il s’agit d’une amélioration de l’expérience utilisateur rendue possible grâce au moteur natif du navigateur.

Dégradation élégante

Vous utilisez la dégradation élégante lorsque vous déclinez une version alternative ou inférieure de vos fonctionnalités au cas où elles ne sont pas prises en charge. Fondamentalement, on part du plus haut pour aller vers le plus bas.

Un exemple très simple serait l’avertissement que vous mettez entre les balises <canvas> pour informer les utilisateurs de navigateurs qui ne les prennent pas en charge qu’il y a quelque chose qu’ils ne peuvent pas voir.

<canvas>
Cette page utilise HTML5 Canvas. Veuillez utiliser un navigateur récent pour voir ce contenu. Pour obtenir un autre navigateur, allez à <a href="http://browsehappy.com/">BrowseHappy</a>
</canvas>

Quelle est la différence ?

En fin de compte, il n’y en a pas. Vous avez des fonctionnalités pour les navigateurs récents et des fonctionnalités ou des solutions de repli pour les plus anciens. C’est plutôt une question de procédure : soit vous codez pour les navigateurs modernes tout en proposant une solution de repli pour les anciens, soit vous le faites dans l’autre sens. C’est un choix.

En tout cas, je veux redire ici que l’expérience utilisateur n’est pas nécessairement la même dans tous les navigateurs. En fait, ce n’est même pas possible, puisque les moteurs des navigateurs sont différents. Quoi qu’il en soit, vous devez fournir des fonctionnalités de base pour tout le monde, mais faites-moi plaisir : améliorez votre site web ou votre application pour les navigateurs modernes. Ils sont bien conçus, ils fournissent des fonctionnalités à l’état natif : utilisez-les.

Lectures complémentaires sur l’amélioration progressive et la dégradation élégante

7. Les préprocesseurs CSS

Aaaah, les préprocesseurs… Le sujet chaud du moment. Sont-ils utiles ? Pour quoi faire ? Devrais-je en employer un ? Lequel ? Je pense que c’est l’un des sujets les plus débattus sur CSS en ce moment.

Je vais essayer d’être aussi objectif que possible dans cette partie. Permettez-moi de commencer par ceci : si vous ne voulez pas utiliser un préprocesseur, alors ne le faites pas. Ce ne sera jamais un problème. Vous ne serez pas un mauvais développeur front-end pour autant. Cela ne vous rendra pas incapable de faire certaines choses. Mais vous devriez, néanmoins, essayer de vous faire votre propre opinion à ce sujet.

Ok, j’en ai fini avec les précautions. Qu’est-ce qu’un préprocesseur, de manière générale ? Un préprocesseur est une sorte d’outil qui compile une syntaxe donnée dans une langue utilisée par un autre programme (dans le cas présent : le navigateur). Il y a des préprocesseurs pour de nombreux languages : il y a Markdown ou Jade pour le HTML. Il y a LESS, Sass et Stylus pour CSS. Il existe CoffeeScript pour JavaScript. Il y a CakePHP pour PHP et ainsi de suite.

De quoi parle-t-on ?

Un préprocesseur CSS fournit aux CSS certaines particularités à partir de langages orientés objet. Des choses comme :

  • les variables
  • les fonctions (avec des paramètres)
  • les espaces de nommages
  • l’imbrication
  • les instructions conditionnelles
  • les opérations
  • etc.

Ça a l’air attrayant, non ? Peut-être que vous voulez un exemple pour comprendre la manière dont cela fonctionne. Prenons le CSS suivant pour une barre de navigation.

.navigation { width: 800px; width: calc(100%-150px);
}
.navigation li { color: #444;
}
.navigation li a { text-decoration: none;
}

Et voici maintenant la version compilée (SCSS) :

$couleur-principale: #444; .navigation { width: (100%-150px); li { color: $couleur-principale; a { text-decoration: none; } }
}

En gros, un préprocesseur va interpréter ceci dans une version CSS standard. Ce sera exactement la même chose, sauf pour le calcul. Il lancera l’opération elle-même et affichera le résultat correspondant sans qu’il soit nécessaire d’utiliser une fonction comme calc().

Donc, vous vous retrouvez avec une feuille de style plus compréhensible (variables et imbrications) et plus facile à maintenir (variables et fonctions). C’était un exemple très théorique, mais dans un projet réel, vous sentirez la différence.

Comment le choisir ?

Il existe beaucoup de préprocesseurs CSS, chacun avec ses avantages et ses particularités. Quoi qu’il en soit, chacun d’entre eux fait plus ou moins la même chose, donc le choix vous appartient. Voici les principales options quand il s’agit de préprocesseurs CSS :

  • Sass (écrit en Ruby)
  • LESS (écrit en JavaScript)
  • Stylus (écrit en JavaScript)
  • Crush (écrit en PHP)

L’idéal, c’est d’apprendre à les connaître, de les tester et de voir ce qui répond le mieux à vos besoins et à votre projet. Il y a plusieurs facteurs qui entrent en jeu ; les énumérer tous serait hors de la portée de cet article, mais vous pouvez trouver quelques ressources pertinentes ci-dessous.

Mon sentiment sur les préprocesseurs CSS ?

Je ne suis pas un expert quand il s’agit de préprocesseurs CSS, mais j’en suis un partisan. Ils fournissent des fonctionnalités très utiles mais qu’on ne trouve pas dans les CSS comme les variables, les déclarations, l’imbrication et les conditions.

J’ai bricolé un peu avec LESS, et il m’a fait à peu près ce que je voulais. Ou du moins, jusqu’à ce que je commence à me lancer dans des choses un peu plus compliquées que vous avez pu lire dans mon dernier article sur CSS Loading Animations (pour les boucles + préfixes vendeurs + keyframes).

J’ai aussi jeté un coup d’œil rapide à Sass et Compass. À ma grande surprise, c’était incroyablement facile à installer et à lancer grâce à Ruby. J’avais peur, mais c’est très très intuitif, croyez-moi. En fin de compte, je suis vraiment impressionné par l’association Sass + Compass. Vous pouvez également en savoir plus sur les raisons pour lesquelles je suis passé de LESS à Sass dans cet article sur mon blog.

Quoi qu’il en soit, je suis encore tout à fait capable d’écrire des CSS classiques sans préprocesseur, et la plupart du temps c’est ce que je fais. Mais au final, je pense que nous allons tous en utiliser un, quel qu’il soit. Il nous manque vraiment certains éléments très utiles avec les CSS, et les préprocesseurs CSS sont là pour y remédier.

Lectures complémentaires sur les préprocesseurs CSS

8. Garder un œil sur l’avenir

Les langages sont en constante évolution. C’est particulièrement vrai pour les CSS. Les spécifications CSS bougent sans cesse, et les navigateurs ajoutent sans cesse de nouvelles fonctionnalités à leurs moteurs.

À ce propos, mon premier conseil serait de rester à l’écoute de ce qui se prépare. Je sais que vous ne pouvez pas être en mesure de tout utiliser dès son lancement, mais savoir quelle fonctionnalité est maintenant prise en charge par Canary Chrome, bientôt par Chrome version stable et Safari, puis par Opera, Firefox et ainsi de suite, c’est important afin de prendre du recul sur les problèmes CSS et les solutions possibles.

Ressources pour garder un œil sur l’avenir :

9. Lire le code des autres

Une des meilleures façons d’apprendre à coder est de lire du code.

Heureusement, le CSS est visible côté client, ce qui vous permet de le lire sur n’importe quel site avec un inspecteur web comme WebKit inspector, Dragonfly, Firebug, etc. De plus, l’industrie du web est très orientée vers l’open-source, ce qui signifie que les gens sont heureux de partager leurs sources avec vous.

Une autre excellente façon d’apprendre est de suivre des tutoriels. Prenez un tutoriel simple, et suivez-le étape par étape. Ensuite, essayez de le refaire à partir de zéro. S’il vous arrive d’être bloqué, jetez un coup d’œil à la solution, puis continuez par vous-même.

Lorsque vous serez à l’aise avec CSS et que vous voudrez entrer finement dans les détails, vous voudrez peut-être jeter un œil à des démonstrations et des expériences qui ne sont pas commentées ni expliquées. Les gens créent des choses tous les jours, et vous tomberez sans arrêt sur des choses que vous ne connaissiez pas encore.

À ce sujet, il y a quelques mois Chris Coyier, Tim Sabat et Alex Vazquez ont lancé CodePen, une sorte de plate-forme pour créer, partager et explorer du code (HTML, CSS, JavaScript). CodePen comprend également un tas d’outils comme les bibliothèques (jQuery, jQuery UI, MooTools, YUI, Prototype, Zepto, Dojo, Ext JS, PrefixFree, etc) et les préprocesseurs (HAML, Markdown, Slim, LESS, SCSS, Sass, CoffeeScript) si vous en avez besoin.

D’autres ressources pour trouver des exemples de code créé par d’autres personnes :

10. Pratiquez sans relâche

Vous savez ce qu’on dit à propos de l’apprentissage : on apprend en faisant. Donc, mon meilleur conseil est de continuer à pratiquer comme pour toute autre chose. Plus vous pratiquez, meilleur vous serez. La pratique ne signifie pas nécessairement faire un site web à partir de zéro. Il suffit de choisir une capture simple sur Dribbble et d’essayer de la refaire en CSS. Le résultat ne sera peut-être pas utile immédiatement, mais ce que vous avez appris vous sera utile un jour.

Et comme je l’ai dit dans la partie « Apprendre les bases et quelques astuces » de cet article, CSS est plein de cas particuliers. Vous devrez apprendre à les gérer si vous voulez écrire des CSS. Et la seule façon de connaître ces cas particuliers consiste à pratiquer, découvrir de nouveaux cas, jeter un œil à la solution, et continuer.

Je vous recommande aussi de partager votre code. Il est toujours utile d’obtenir un retour constructif, alors assurez-vous de demander aux gens de vérifier votre code une fois qu’il est presque fini. Il suffit de les déposer dans un JSFiddle, de partager et de demander des commentaires.

Sommaire et crédits

Comme cet article mentionne un tas de liens et de ressources diverses, autant les rassembler tous au même endroit :

Merci beaucoup d’avoir lu cet article. J’espère qu’il vous aidera d’une manière ou d’une autre à améliorer la façon dont vous apprenez et utilisez les CSS.

]]> https://www.pompage.net/traduction/ameliorer-vos-feuilles-de-styles https://www.pompage.net/traduction/ameliorer-vos-feuilles-de-styles Thu, 19 Jun 2014 03:06:00 +0200 <![CDATA[Quelles mesures CSS, pour quel usage ?]]>

Par Dudley Storey

Confrontés au foisonnement des systèmes de mesure CSS, les développeurs web peuvent avoir du mal à comprendre quelles unités il faut utiliser dans leurs pages, et à quel moment. On peut être tenté de toujours utiliser les mêmes mesures, mais ce choix risque de limiter sérieusement l’aboutissement de vos designs. Je propose ci-dessous une liste de suggestions, mais non pas de règles absolues : libre à vous de vous en écarter si vous le jugez préférable.

À choisir pour : les traits de bordure et les éléments généraux, lorsqu’il s’agit de designs à largeur fixe ; également pour les valeurs des décalages des ombres portées en CSS. À éviter pour les points d’arrêt dans @media car cela casse la mise en page en cas de zoom : mieux vaut employer rem ou em.
À éviter pour : la typographie, sauf s’il s’agit d’établir une taille de police de base dans un « reset CSS » (remise à zéro des styles, NdT).

Les pourcentages (%)

À choisir pour : intégrer des images et des conteneurs à taille variable ; et pour définir la hauteur de la balise body dans certains cas.
À éviter pour : la typographie. (Exception : la taille de police pour un reset CSS).

em et ex

À choisir pour : la typographie, et les éléments qui y sont liés (les marges, par exemple), mais sans perdre de vue que em et ex peuvent être très délicats à employer dans des mises en page complexes. L’unité alternative rem est plus appropriée dans ces cas-là.

Les points et les picas

À choisir pour : les feuilles de style d’impression.
À éviter pour : tout le reste.

rem

À choisir si : vous voulez une alternative plus solide et fiable aux solutions avec em ou ex, et pour les mêmes usages, y compris les points d’arrêt dans les requêtes de médias.
À éviter si : vous devez prendre en charge IE8 et les versions antérieures. Sinon, utilisez cette unité mais prévoyez une solution de repli (en fournissant une alternative dans une unité plus courante avant la valeur en rem) ou encore un « polyfill » (c’est-à-dire un script effectuant le calcul dans les navigateurs ne comprenant pas cette unité, NdT).

Unités relatives à la surface d’affichage (vh et vw)

À choisir pour : la typographie réactive ; et pour des conteneurs réactifs « parfaits ».
Difficile de savoir pour quel usage il faudrait éviter ces unités, car vh et vw sont très récents et encore loin d’avoir été totalement exploités en design web. Attention toutefois à l’absence de prise en charge sous IE8 : prévoyez donc des solutions de repli.

Les pouces (in) et les centimètres (cm)

À choisir dans : les feuilles de style d’impression, et en particulier pour les marges des pages.
À éviter pour : tout le reste.

Les caractères (ch)

À choisir pour : dimensionner et positionner les polices à espacement constant. Attention, le support navigateur est incomplet.

Grille de texte (gd)

De préférence pour : des mises en page expérimentales, car c’est une unité qui n’est prise en charge que par IE10+ au moment où j’écris ces lignes. Des substituts de type « polyfill » commencent néanmoins à apparaître.

Nombres bruts

Bien que presque toutes les propriétés CSS exigent que l’unité de mesure soit indiquée dans la déclaration, pour quelques-unes d’entre elles il est préférable de n’employer que des valeurs d’entiers ou à virgule flottante. En particulier, les propriétés line-height (hauteur de ligne) et border-image (image de bordure) sont plutôt à spécifier à l’aide de nombres bruts.

]]> http://www.pompage.net/traduction/css-unites-et-usages http://www.pompage.net/traduction/css-unites-et-usages Wed, 09 Apr 2014 10:04:00 +0200 <![CDATA[Quelles mesures CSS, pour quel usage ?]]>

Par Dudley Storey

Confrontés au foisonnement des systèmes de mesure CSS, les développeurs web peuvent avoir du mal à comprendre quelles unités il faut utiliser dans leurs pages, et à quel moment. On peut être tenté de toujours utiliser les mêmes mesures, mais ce choix risque de limiter sérieusement l’aboutissement de vos designs. Je propose ci-dessous une liste de suggestions, mais non pas de règles absolues : libre à vous de vous en écarter si vous le jugez préférable.

À choisir pour : les traits de bordure et les éléments généraux, lorsqu’il s’agit de designs à largeur fixe ; également pour les valeurs des décalages des ombres portées en CSS. À éviter pour les points d’arrêt dans @media car cela casse la mise en page en cas de zoom : mieux vaut employer rem ou em.
À éviter pour : la typographie, sauf s’il s’agit d’établir une taille de police de base dans un « reset CSS » (remise à zéro des styles, NdT).

Les pourcentages (%)

À choisir pour : intégrer des images et des conteneurs à taille variable ; et pour définir la hauteur de la balise body dans certains cas.
À éviter pour : la typographie. (Exception : la taille de police pour un reset CSS).

em et ex

À choisir pour : la typographie, et les éléments qui y sont liés (les marges, par exemple), mais sans perdre de vue que em et ex peuvent être très délicats à employer dans des mises en page complexes. L’unité alternative rem est plus appropriée dans ces cas-là.

Les points et les picas

À choisir pour : les feuilles de style d’impression.
À éviter pour : tout le reste.

rem

À choisir si : vous voulez une alternative plus solide et fiable aux solutions avec em ou ex, et pour les mêmes usages, y compris les points d’arrêt dans les requêtes de médias.
À éviter si : vous devez prendre en charge IE8 et les versions antérieures. Sinon, utilisez cette unité mais prévoyez une solution de repli (en fournissant une alternative dans une unité plus courante avant la valeur en rem) ou encore un « polyfill » (c’est-à-dire un script effectuant le calcul dans les navigateurs ne comprenant pas cette unité, NdT).

Unités relatives à la surface d’affichage (vh et vw)

À choisir pour : la typographie réactive ; et pour des conteneurs réactifs « parfaits ».
Difficile de savoir pour quel usage il faudrait éviter ces unités, car vh et vw sont très récents et encore loin d’avoir été totalement exploités en design web. Attention toutefois à l’absence de prise en charge sous IE8 : prévoyez donc des solutions de repli.

Les pouces (in) et les centimètres (cm)

À choisir dans : les feuilles de style d’impression, et en particulier pour les marges des pages.
À éviter pour : tout le reste.

Les caractères (ch)

À choisir pour : dimensionner et positionner les polices à espacement constant. Attention, le support navigateur est incomplet.

Grille de texte (gd)

De préférence pour : des mises en page expérimentales, car c’est une unité qui n’est prise en charge que par IE10+ au moment où j’écris ces lignes. Des substituts de type « polyfill » commencent néanmoins à apparaître.

Nombres bruts

Bien que presque toutes les propriétés CSS exigent que l’unité de mesure soit indiquée dans la déclaration, pour quelques-unes d’entre elles il est préférable de n’employer que des valeurs d’entiers ou à virgule flottante. En particulier, les propriétés line-height (hauteur de ligne) et border-image (image de bordure) sont plutôt à spécifier à l’aide de nombres bruts.

]]> http://www.pompage.net/traduction/css-unites-et-usages http://www.pompage.net/traduction/css-unites-et-usages Wed, 09 Apr 2014 10:04:00 +0200 <![CDATA[Quelles mesures CSS, pour quel usage ?]]>

Par Dudley Storey

Confrontés au foisonnement des systèmes de mesure CSS, les développeurs web peuvent avoir du mal à comprendre quelles unités il faut utiliser dans leurs pages, et à quel moment. On peut être tenté de toujours utiliser les mêmes mesures, mais ce choix risque de limiter sérieusement l’aboutissement de vos designs. Je propose ci-dessous une liste de suggestions, mais non pas de règles absolues : libre à vous de vous en écarter si vous le jugez préférable.

À choisir pour : les traits de bordure et les éléments généraux, lorsqu’il s’agit de designs à largeur fixe ; également pour les valeurs des décalages des ombres portées en CSS. À éviter pour les points d’arrêt dans @media car cela casse la mise en page en cas de zoom : mieux vaut employer rem ou em.
À éviter pour : la typographie, sauf s’il s’agit d’établir une taille de police de base dans un « reset CSS » (remise à zéro des styles, NdT).

Les pourcentages (%)

À choisir pour : intégrer des images et des conteneurs à taille variable ; et pour définir la hauteur de la balise body dans certains cas.
À éviter pour : la typographie. (Exception : la taille de police pour un reset CSS).

em et ex

À choisir pour : la typographie, et les éléments qui y sont liés (les marges, par exemple), mais sans perdre de vue que em et ex peuvent être très délicats à employer dans des mises en page complexes. L’unité alternative rem est plus appropriée dans ces cas-là.

Les points et les picas

À choisir pour : les feuilles de style d’impression.
À éviter pour : tout le reste.

rem

À choisir si : vous voulez une alternative plus solide et fiable aux solutions avec em ou ex, et pour les mêmes usages, y compris les points d’arrêt dans les requêtes de médias.
À éviter si : vous devez prendre en charge IE8 et les versions antérieures. Sinon, utilisez cette unité mais prévoyez une solution de repli (en fournissant une alternative dans une unité plus courante avant la valeur en rem) ou encore un « polyfill » (c’est-à-dire un script effectuant le calcul dans les navigateurs ne comprenant pas cette unité, NdT).

Unités relatives à la surface d’affichage (vh et vw)

À choisir pour : la typographie réactive ; et pour des conteneurs réactifs « parfaits ».
Difficile de savoir pour quel usage il faudrait éviter ces unités, car vh et vw sont très récents et encore loin d’avoir été totalement exploités en design web. Attention toutefois à l’absence de prise en charge sous IE8 : prévoyez donc des solutions de repli.

Les pouces (in) et les centimètres (cm)

À choisir dans : les feuilles de style d’impression, et en particulier pour les marges des pages.
À éviter pour : tout le reste.

Les caractères (ch)

À choisir pour : dimensionner et positionner les polices à espacement constant. Attention, le support navigateur est incomplet.

Grille de texte (gd)

De préférence pour : des mises en page expérimentales, car c’est une unité qui n’est prise en charge que par IE10+ au moment où j’écris ces lignes. Des substituts de type « polyfill » commencent néanmoins à apparaître.

Nombres bruts

Bien que presque toutes les propriétés CSS exigent que l’unité de mesure soit indiquée dans la déclaration, pour quelques-unes d’entre elles il est préférable de n’employer que des valeurs d’entiers ou à virgule flottante. En particulier, les propriétés line-height (hauteur de ligne) et border-image (image de bordure) sont plutôt à spécifier à l’aide de nombres bruts.

]]> https://www.pompage.net/traduction/css-unites-et-usages https://www.pompage.net/traduction/css-unites-et-usages Wed, 09 Apr 2014 10:04:00 +0200 <![CDATA[Tests de contenu]]>

Par Angela Colter

Personne n’a besoin de vous convaincre qu’il est important de tester le design et les interactions entre votre site et les personnes qui auront à l’utiliser, pas vrai ? Mais si vous vous limitez à cela, vous passez à côté de retours sur la partie la plus importante de votre site : le contenu. Que le but de votre site soit de convaincre les gens d’adopter un nouveau comportement, d’acheter quelque chose ou simplement de les informer, si vous vous contentez de vérifier qu'ils parviennent à trouver l'information ou bien à réaliser une transaction, alors vous manquez l'essentiel : le contenu est-il approprié au public ? Sont-ils capables de lire et de comprendre ce que vous avez écrit ?

Prenez un site d’information médicale avec deux ensembles de fiches techniques : une version simplifiée pour le public de base et une version plus technique pour les médecins. Pendant les tests, un médecin participant qui lisait la version technique s’est arrêté pour nous dire : « Écoutez. J’ai cinq minutes entre deux patients pour comprendre l’essentiel de ces informations. Je ne fais pas de recherche sur le sujet, je veux juste en savoir suffisamment pour pouvoir en parler à mes patients. Si je n’arrive pas à comprendre rapidement, je ne peux pas l’utiliser ». Nous avions fait des suppositions incorrectes à propos des besoins de chaque segment du public. Nous serions passé à côté de cette révélation importante si nous n’avions pas testé le contenu.

Vous vous y prenez mal

Avez-vous déjà posé ces questions à vos utilisateurs à propos de votre contenu ?

Ces informations vous ont-elles plu ?
Avez-vous compris ce que vous avez lu ?

Il est tentant de poser ces questions mais elles ne vous aideront pas à découvrir si votre contenu est adapté à votre public. La question de savoir si le contenu plaît est très appréciée — surtout dans les études de marché — mais elle n’est pas pertinente dans l’évaluation de la conception car le fait que quelque chose plaise a très peu de rapport avec le fait de le comprendre et de l’utiliser. Dan Formosa donne des explications très intéressantes qui expliquent pourquoi vous devriez éviter de demander aux gens ce qu’ils apprécient pendant des recherches utilisateurs. Pour ce qui est de la question de la compréhension, il est utile d’en savoir un minimum sur la façon dont les gens lisent.

Le processus de lecture

La lecture est le fruit de deux processus cognitifs simultanés : le décodage et la compréhension.

Quand nous commençons à lire, nous apprenons que certains symboles représentent des concepts. Nous commençons par reconnaître des lettres et par associer les formes aux sons qu’elles représentent. Ensuite, nous passons à l’étape de la reconnaissance de mots entiers et de leur sens. Une fois que nous avons digéré ces mots de manière individuelle, nous pouvons passer à la compréhension : trouver ce que l’auteur a voulu dire en attachant ces mots les uns aux autres. C’est un travail difficile, en particulier si vous apprenez à lire ou si vous faites partie des près de 50% de la population qui ont de faibles capacités de lecture.

Même s’il est tentant de faire lire le texte à quelqu’un et de lui demander s’il l’a compris, vous ne devriez pas vous appuyer sur un simple « oui ». Il est possible de reconnaître tous les mots (décoder), et avoir pourtant mal appréhendé le sens (comprendre). Vous en avez probablement fait l’expérience vous-même : avez-vous déjà lu quelque chose jusqu’au bout pour vous apercevoir que vous n’aviez pas compris ? Vous reconnaissez chaque mot, mais parce que le texte n’est pas clair ou parce que vous êtres fatigués, le sens du passage vous échappe.

Alors comment déterminer si votre contenu est adapté à pour vos utilisateurs ? Voyons comment le prédire (sans utilisateur) et comment le tester (avec des utilisateurs).

Estimons-le

Les formules de lisibilité mesurent les éléments quantifiables de l’écrit, tels que la longueur des mots et des phrases, pour prédire le niveau de compétence nécessaire pour les comprendre. Ils peuvent constituer une façon rapide, facile, et bon marché de déterminer si un texte sera trop difficile à comprendre pour un public particulier. Les résultats sont faciles à comprendre : beaucoup donnent le niveau scolaire états-uniens du texte.

Vous pouvez acheter des logiciels de lisibilité. Il existe également des outils gratuits en ligne proposés par Added Bytes, Juicy Studio, et Edit Central. Enfin, vous pouvez toujours vous rabattre sur la formule de gradation Flesch-Kincaid de Microsoft Word.

Cependant, il y a un gros problème avec les formules de lisibilité : la plupart des propriétés qui rendent un texte facile à comprendre comme le contenu, l’organisation, ou la mise en page ne peuvent pas se mesurer de façon mathématique. Utiliser des mots courts et des phrases simples ne garantit en rien que le texte sera lisible. Les formules de lisibilité ne prennent pas en compte le sens. En aucun cas. Par exemple, prenons la phrase suivante de la page « A propos » de A List Apart. L’index SMOG estime qu’il faut un niveau de troisième pour la comprendre :

Nous recevons plus de courrier en une journée que nous pourrions en lire en une semaine.

Maintenant, réarrangeons les mots de façon à obscurcir le sens. Le résultat : toujours compréhensible pour un élève de troisième.

En une journée nous courrier plus qu’en une semaine recevons plus que nous pourrions en lire.

Les formules de lisibilité peuvent aider à prédire le niveau de difficulté du texte et vous aider à argumenter pour pouvoir le tester avec des utilisateurs. Mais ne les utilisez pas comme votre seule méthode d’évaluation, et ne réécrivez pas vos textes juste pour satisfaire une formule. Rappelez-vous, les formules de lisibilité estiment le niveau de difficulté d’un texte. Elles ne peuvent pas vous enseigner comment rédiger des textes compréhensibles.

Faire un test d’utilisabilité modéré

Pour déterminer si les gens comprennent votre contenu, faites-leur lire et appliquer de nouvelles connaissances. En d’autres termes, faites un test d’utilisabilité ! Voici comment créer des scénarios de tâches dans lesquels les participants interprètent et utilisent ce qu’ils ont lu :

  • Identifiez les problèmes cruciaux pour vos utilisateurs et vos affaires.
  • Créez des tâches qui testent les connaissances des utilisateurs sur ces problèmes.
  • Dites bien aux participants que ce ne sont pas eux qui sont testés mais bien le contenu.

Disons que vous testez SEPTA, un site de transport en commun. Il offre plusieurs types d’abonnement mensuels qui varient selon le moyen de transport utilisé et la distance parcourue : par exemple, le TransPass permet de prendre le métro, le bus ou le trolley. Un TrailPass vous permet aussi de prendre le train, etc. Si vous vouliez uniquement tester l’interface, vous articuleriez la tâche de la façon suivante :

Achetez un TrailPass mensuel.

Mais vous souhaitez tester avec quelle facilité le contenu explique la différence entre les abonnements pour que les gens puissent choisir celui qui leur convient le mieux. Ainsi, articulez la tâche de cette façon :

Achetez l’abonnement le meilleur marché qui répond à vos besoins.

Vous voyez la différence ? La première version ne requiert pas des participants qu’ils prennent en compte le contenu du tout. Elle leur dit simplement quelle version choisir. La deuxième version leur demande d’utiliser le contenu pour déterminer quelle option est la meilleure pour eux. Soyez sûr d’obtenir des participants qu’ils articulent explicitement leurs besoins pour que vous puissiez juger s’ils ont choisi la meilleure option.

Demandez aux participants de penser à haute voix pendant qu’ils lisent le contenu. Vous obtiendrez de précieux indices sur ce qui leur paraît confus et pourquoi. Idéalement, vous souhaitez que vos utilisateurs comprennent le texte dès leur première lecture. S’ils ont besoin de relire quoi que ce soit, vous devez clarifier le texte. Demandez aussi à vos participants de paraphraser certaines portions ; s’ils ne comprennent pas l’idée générale, vous feriez mieux de recommencer.

Pour déterminer quand les scénarii et les explications de texte sont corrects, vous devez savoir à quoi ressemblent les bonnes réponses. S’il le faut, travaillez avec un expert sur le sujet pour créer une feuille de réponses avant de diriger les séances. Vous pouvez organiser des séances de test utilisateur modérées en temps réel soit en personne soit à distance. Mais vous pouvez également utiliser des méthodes asynchrones.

Faites un test d’utilisabilité non modéré

Si vous avez besoin d’un panel plus conséquent, que vous avez un budget serré ou que le temps presse, essayez une étude à distance sans modérateur. Envoyez aux participants l’un des outils de test utilisateur de votre choix comme Loop11 ou OpenHallway, donnez-leur des tâches à réaliser et enregistrez leurs réponses. Vous pouvez même utiliser quelque chose comme SurveyMonkey et formater votre étude comme un test à choix multiple : cela vous prendra plus de temps au début que des questions ouvertes car vous devez définir les réponses possibles à l’avance mais ainsi l’évaluation quantitative sera plus rapide.

La clé du succès d’un test à choix multiple réussi est de créer des questions sans équivoque.

  • Formulez votre question dans une forme affirmative et pas négative.
  • Incluez seulement une seule réponse correcte ou clairement meilleure.
  • Inventez entre deux et quatre réponses incorrectes (des distracteurs) qui pourraient être plausibles si vous ne compreniez pas le texte.
  • Assurez-vous que les alternatives s’excluent mutuellement.
  • Évitez de donner des indices dans les réponses.
  • Évitez d’utiliser « Toutes les options ci-dessus » ou « Aucune option ci-dessus » en tant que choix.
  • Évitez d’utiliser « jamais », « toujours », et « seulement ».

Pensez aussi à ajouter la possibilité de répondre « Je ne sais pas » pour éviter que les participants ne cochent une réponse au hasard juste pour passer la question. Il ne s’agit pas du bac. Une réponse choisie par défaut ne vous aidera pas à analyser votre contenu.

Scénario de tâches :

Vous souhaitez acheter des chèques voyage avec votre carte de crédit. Quel pourcentage s’applique à votre achat ?

Réponses possibles : Le taux annuel standard de 10.99% Le taux annuel pour avance de liquide de 24.24%* Le taux de pénalité de 29.99% Je ne sais pas.

(* Cette réponse est la réponse correcte à en croire le contrat de mon propre organisme de crédit)

Tout comme dans les tests modérés, faites comprendre aux utilisateurs que le test concerne le contenu et non leurs capacités.

Utilisez un test de Cloze

Un test de Cloze enlève certains mots d’une partie de votre texte et demande à vos utilisateurs de remplir les mots manquants. Les participants au test doivent se référer au contexte ainsi qu’à leurs connaissances antérieures du sujet pour identifier les mots effacés. C’est basé sur la théorie de Gestalt de complétude – dans laquelle le cerveau essaie de remplir les pièces manquantes – et l’applique à l’écrit.

Cela ressemble à ceci :

Si vous voulez _____ si les ______________ de votre site comprennent votre contenu, alors vous _____ le tester avec eux.

Cela ressemble à un exercice de remplissage, n’est-ce pas ? Mais au lieu d’essayer d’inventer la phrase la plus amusante, la plus étrange ou la plus intéressante, comme dans le jeu américain Mad Libs, les participants doivent deviner le mot exact que l’auteur a utilisé. Même si les tests Cloze sont rares dans le champ de l’expérience utilisateur, les éducateurs les utilisent depuis des décennies pour s’assurer qu’un texte est adapté à leurs étudiants surtout dans les cours d’anglais deuxième langue.

Voilà comment faire :

  • Prenez un extrait de texte de 125 à 250 mots à peu près.
  • Enlevez un mot sur cinq en le remplaçant par un espace blanc.
  • Demandez aux participants de remplir les espaces avec le mot qui, selon eux, a été enlevé.
  • Établissez un score en comptant le nombre total de bonnes réponses et en le divisant par le nombre total d’espaces blancs.

Un score de 60% ou mieux indique que le texte est approprié à votre public. Les participants ayant obtenu entre 40 et 60% auront quelques difficultés à comprendre le texte original. Ce n’est pas rédhibitoire, mais cela veut dire que le public aura besoin d’aide supplémentaire pour comprendre votre contenu.
Un score de moins de 40% veut dire que les lecteurs seront frustrés par le texte et qu’il devrait être réécrit.

Cela peut sembler farfelu, mais essayez cette méthode avant de l’écarter. Dans une étude gouvernementale sur la lisibilité d’information liées aux services de santé, un panel d’expert a catégorisé des articles de santé comme étant faciles ou difficiles. Nous avons ensuite fait passer des tests Cloze en utilisant ces articles à des participants dont le niveau d’alphabétisation allait de bas à moyen. Nous avons découvert que les résultats reflétaient ceux du panel d’expert. Le score moyen des articles dits « faciles » était de 60, indiquant qu’ils avaient été écrits de manière appropriée pour ce public. Le score moyen des articles dits « difficiles » était de 39 : trop difficile pour ce public.

Les tests Cloze sont facile à créer, administrer et évaluer. Ils donnent une bonne idée de l’adéquation entre le contenu et le public visé. Si vous utilisez des tests Cloze seuls ou en combinaison avec d’autres tests utilisateurs, sachez que remplir ces blancs demande beaucoup d’efforts cognitifs. Prévoyez 25 blancs minimum pour avoir une étude de qualité, mais sachez qu’au-delà de 50 le test devient vite fatiguant.

Quand tester

Testez votre contenu à n’importe quel moment dans le processus de développement du site. Dès que vous avez du contenu, vous pouvez le tester. Vous avez besoin de convaincre votre patron de budgéter les tests de contenu ? Passez votre contenu dans une formule de lisibilité. Vous avez du contenu mais pas de wireframes ou de design visuel ? Faites un test Cloze pour évaluer le contenu. Est-ce que la compréhension contenu est cruciale pour terminer une tâche ou un ensemble de tâches ? Affichez le contenu lors de tests d’ergonomie.

Que tester

Vous ne pouvez pas tester chaque phrase de votre site et vous n’en avez pas besoin. Concentrez-vous sur les tâches importantes pour vos utilisateurs et votre produit. Par exemple, est-ce que votre centre de support reçoit des appels concernant des informations qui devraient se trouver sur le site ? Testez le contenu pour trouver si votre site laisse à désirer et à quel endroit.

N’attendez plus : allez-y !

Tout comme les tests d’ergonomie se concentrent sur ce que les utilisateurs font et non pas ce qu’ils disent faire, les tests de contenu déterminent ce que les utilisateurs comprennent et non pas ce qu’ils disent comprendre.

Quel que soit votre budget, votre calendrier et votre accès aux utilisateurs, il existe une méthode pour tester si votre contenu est approprié pour les personnes qui le lise. Donc, testez ! Si votre contenu fonctionne, vous serez vraiment fixé, sinon il ne vous restera plus qu’à le réécrire.

Translated with the permission of A List Apart and the author[s].]]> http://www.pompage.net/traduction/tests-de-contenu http://www.pompage.net/traduction/tests-de-contenu Wed, 26 Mar 2014 11:03:00 +0100 <![CDATA[Tests de contenu]]>

Par Angela Colter

Personne n’a besoin de vous convaincre qu’il est important de tester le design et les interactions entre votre site et les personnes qui auront à l’utiliser, pas vrai ? Mais si vous vous limitez à cela, vous passez à côté de retours sur la partie la plus importante de votre site : le contenu. Que le but de votre site soit de convaincre les gens d’adopter un nouveau comportement, d’acheter quelque chose ou simplement de les informer, si vous vous contentez de vérifier qu'ils parviennent à trouver l'information ou bien à réaliser une transaction, alors vous manquez l'essentiel : le contenu est-il approprié au public ? Sont-ils capables de lire et de comprendre ce que vous avez écrit ?

Prenez un site d’information médicale avec deux ensembles de fiches techniques : une version simplifiée pour le public de base et une version plus technique pour les médecins. Pendant les tests, un médecin participant qui lisait la version technique s’est arrêté pour nous dire : « Écoutez. J’ai cinq minutes entre deux patients pour comprendre l’essentiel de ces informations. Je ne fais pas de recherche sur le sujet, je veux juste en savoir suffisamment pour pouvoir en parler à mes patients. Si je n’arrive pas à comprendre rapidement, je ne peux pas l’utiliser ». Nous avions fait des suppositions incorrectes à propos des besoins de chaque segment du public. Nous serions passé à côté de cette révélation importante si nous n’avions pas testé le contenu.

Vous vous y prenez mal

Avez-vous déjà posé ces questions à vos utilisateurs à propos de votre contenu ?

Ces informations vous ont-elles plu ?
Avez-vous compris ce que vous avez lu ?

Il est tentant de poser ces questions mais elles ne vous aideront pas à découvrir si votre contenu est adapté à votre public. La question de savoir si le contenu plaît est très appréciée — surtout dans les études de marché — mais elle n’est pas pertinente dans l’évaluation de la conception car le fait que quelque chose plaise a très peu de rapport avec le fait de le comprendre et de l’utiliser. Dan Formosa donne des explications très intéressantes qui expliquent pourquoi vous devriez éviter de demander aux gens ce qu’ils apprécient pendant des recherches utilisateurs. Pour ce qui est de la question de la compréhension, il est utile d’en savoir un minimum sur la façon dont les gens lisent.

Le processus de lecture

La lecture est le fruit de deux processus cognitifs simultanés : le décodage et la compréhension.

Quand nous commençons à lire, nous apprenons que certains symboles représentent des concepts. Nous commençons par reconnaître des lettres et par associer les formes aux sons qu’elles représentent. Ensuite, nous passons à l’étape de la reconnaissance de mots entiers et de leur sens. Une fois que nous avons digéré ces mots de manière individuelle, nous pouvons passer à la compréhension : trouver ce que l’auteur a voulu dire en attachant ces mots les uns aux autres. C’est un travail difficile, en particulier si vous apprenez à lire ou si vous faites partie des près de 50% de la population qui ont de faibles capacités de lecture.

Même s’il est tentant de faire lire le texte à quelqu’un et de lui demander s’il l’a compris, vous ne devriez pas vous appuyer sur un simple « oui ». Il est possible de reconnaître tous les mots (décoder), et avoir pourtant mal appréhendé le sens (comprendre). Vous en avez probablement fait l’expérience vous-même : avez-vous déjà lu quelque chose jusqu’au bout pour vous apercevoir que vous n’aviez pas compris ? Vous reconnaissez chaque mot, mais parce que le texte n’est pas clair ou parce que vous êtres fatigués, le sens du passage vous échappe.

Alors comment déterminer si votre contenu est adapté à pour vos utilisateurs ? Voyons comment le prédire (sans utilisateur) et comment le tester (avec des utilisateurs).

Estimons-le

Les formules de lisibilité mesurent les éléments quantifiables de l’écrit, tels que la longueur des mots et des phrases, pour prédire le niveau de compétence nécessaire pour les comprendre. Ils peuvent constituer une façon rapide, facile, et bon marché de déterminer si un texte sera trop difficile à comprendre pour un public particulier. Les résultats sont faciles à comprendre : beaucoup donnent le niveau scolaire états-uniens du texte.

Vous pouvez acheter des logiciels de lisibilité. Il existe également des outils gratuits en ligne proposés par Added Bytes, Juicy Studio, et Edit Central. Enfin, vous pouvez toujours vous rabattre sur la formule de gradation Flesch-Kincaid de Microsoft Word.

Cependant, il y a un gros problème avec les formules de lisibilité : la plupart des propriétés qui rendent un texte facile à comprendre comme le contenu, l’organisation, ou la mise en page ne peuvent pas se mesurer de façon mathématique. Utiliser des mots courts et des phrases simples ne garantit en rien que le texte sera lisible. Les formules de lisibilité ne prennent pas en compte le sens. En aucun cas. Par exemple, prenons la phrase suivante de la page « A propos » de A List Apart. L’index SMOG estime qu’il faut un niveau de troisième pour la comprendre :

Nous recevons plus de courrier en une journée que nous pourrions en lire en une semaine.

Maintenant, réarrangeons les mots de façon à obscurcir le sens. Le résultat : toujours compréhensible pour un élève de troisième.

En une journée nous courrier plus qu’en une semaine recevons plus que nous pourrions en lire.

Les formules de lisibilité peuvent aider à prédire le niveau de difficulté du texte et vous aider à argumenter pour pouvoir le tester avec des utilisateurs. Mais ne les utilisez pas comme votre seule méthode d’évaluation, et ne réécrivez pas vos textes juste pour satisfaire une formule. Rappelez-vous, les formules de lisibilité estiment le niveau de difficulté d’un texte. Elles ne peuvent pas vous enseigner comment rédiger des textes compréhensibles.

Faire un test d’utilisabilité modéré

Pour déterminer si les gens comprennent votre contenu, faites-leur lire et appliquer de nouvelles connaissances. En d’autres termes, faites un test d’utilisabilité ! Voici comment créer des scénarios de tâches dans lesquels les participants interprètent et utilisent ce qu’ils ont lu :

  • Identifiez les problèmes cruciaux pour vos utilisateurs et vos affaires.
  • Créez des tâches qui testent les connaissances des utilisateurs sur ces problèmes.
  • Dites bien aux participants que ce ne sont pas eux qui sont testés mais bien le contenu.

Disons que vous testez SEPTA, un site de transport en commun. Il offre plusieurs types d’abonnement mensuels qui varient selon le moyen de transport utilisé et la distance parcourue : par exemple, le TransPass permet de prendre le métro, le bus ou le trolley. Un TrailPass vous permet aussi de prendre le train, etc. Si vous vouliez uniquement tester l’interface, vous articuleriez la tâche de la façon suivante :

Achetez un TrailPass mensuel.

Mais vous souhaitez tester avec quelle facilité le contenu explique la différence entre les abonnements pour que les gens puissent choisir celui qui leur convient le mieux. Ainsi, articulez la tâche de cette façon :

Achetez l’abonnement le meilleur marché qui répond à vos besoins.

Vous voyez la différence ? La première version ne requiert pas des participants qu’ils prennent en compte le contenu du tout. Elle leur dit simplement quelle version choisir. La deuxième version leur demande d’utiliser le contenu pour déterminer quelle option est la meilleure pour eux. Soyez sûr d’obtenir des participants qu’ils articulent explicitement leurs besoins pour que vous puissiez juger s’ils ont choisi la meilleure option.

Demandez aux participants de penser à haute voix pendant qu’ils lisent le contenu. Vous obtiendrez de précieux indices sur ce qui leur paraît confus et pourquoi. Idéalement, vous souhaitez que vos utilisateurs comprennent le texte dès leur première lecture. S’ils ont besoin de relire quoi que ce soit, vous devez clarifier le texte. Demandez aussi à vos participants de paraphraser certaines portions ; s’ils ne comprennent pas l’idée générale, vous feriez mieux de recommencer.

Pour déterminer quand les scénarii et les explications de texte sont corrects, vous devez savoir à quoi ressemblent les bonnes réponses. S’il le faut, travaillez avec un expert sur le sujet pour créer une feuille de réponses avant de diriger les séances. Vous pouvez organiser des séances de test utilisateur modérées en temps réel soit en personne soit à distance. Mais vous pouvez également utiliser des méthodes asynchrones.

Faites un test d’utilisabilité non modéré

Si vous avez besoin d’un panel plus conséquent, que vous avez un budget serré ou que le temps presse, essayez une étude à distance sans modérateur. Envoyez aux participants l’un des outils de test utilisateur de votre choix comme Loop11 ou OpenHallway, donnez-leur des tâches à réaliser et enregistrez leurs réponses. Vous pouvez même utiliser quelque chose comme SurveyMonkey et formater votre étude comme un test à choix multiple : cela vous prendra plus de temps au début que des questions ouvertes car vous devez définir les réponses possibles à l’avance mais ainsi l’évaluation quantitative sera plus rapide.

La clé du succès d’un test à choix multiple réussi est de créer des questions sans équivoque.

  • Formulez votre question dans une forme affirmative et pas négative.
  • Incluez seulement une seule réponse correcte ou clairement meilleure.
  • Inventez entre deux et quatre réponses incorrectes (des distracteurs) qui pourraient être plausibles si vous ne compreniez pas le texte.
  • Assurez-vous que les alternatives s’excluent mutuellement.
  • Évitez de donner des indices dans les réponses.
  • Évitez d’utiliser « Toutes les options ci-dessus » ou « Aucune option ci-dessus » en tant que choix.
  • Évitez d’utiliser « jamais », « toujours », et « seulement ».

Pensez aussi à ajouter la possibilité de répondre « Je ne sais pas » pour éviter que les participants ne cochent une réponse au hasard juste pour passer la question. Il ne s’agit pas du bac. Une réponse choisie par défaut ne vous aidera pas à analyser votre contenu.

Scénario de tâches :

Vous souhaitez acheter des chèques voyage avec votre carte de crédit. Quel pourcentage s’applique à votre achat ?

Réponses possibles : Le taux annuel standard de 10.99% Le taux annuel pour avance de liquide de 24.24%* Le taux de pénalité de 29.99% Je ne sais pas.

(* Cette réponse est la réponse correcte à en croire le contrat de mon propre organisme de crédit)

Tout comme dans les tests modérés, faites comprendre aux utilisateurs que le test concerne le contenu et non leurs capacités.

Utilisez un test de Cloze

Un test de Cloze enlève certains mots d’une partie de votre texte et demande à vos utilisateurs de remplir les mots manquants. Les participants au test doivent se référer au contexte ainsi qu’à leurs connaissances antérieures du sujet pour identifier les mots effacés. C’est basé sur la théorie de Gestalt de complétude – dans laquelle le cerveau essaie de remplir les pièces manquantes – et l’applique à l’écrit.

Cela ressemble à ceci :

Si vous voulez _____ si les ______________ de votre site comprennent votre contenu, alors vous _____ le tester avec eux.

Cela ressemble à un exercice de remplissage, n’est-ce pas ? Mais au lieu d’essayer d’inventer la phrase la plus amusante, la plus étrange ou la plus intéressante, comme dans le jeu américain Mad Libs, les participants doivent deviner le mot exact que l’auteur a utilisé. Même si les tests Cloze sont rares dans le champ de l’expérience utilisateur, les éducateurs les utilisent depuis des décennies pour s’assurer qu’un texte est adapté à leurs étudiants surtout dans les cours d’anglais deuxième langue.

Voilà comment faire :

  • Prenez un extrait de texte de 125 à 250 mots à peu près.
  • Enlevez un mot sur cinq en le remplaçant par un espace blanc.
  • Demandez aux participants de remplir les espaces avec le mot qui, selon eux, a été enlevé.
  • Établissez un score en comptant le nombre total de bonnes réponses et en le divisant par le nombre total d’espaces blancs.

Un score de 60% ou mieux indique que le texte est approprié à votre public. Les participants ayant obtenu entre 40 et 60% auront quelques difficultés à comprendre le texte original. Ce n’est pas rédhibitoire, mais cela veut dire que le public aura besoin d’aide supplémentaire pour comprendre votre contenu.
Un score de moins de 40% veut dire que les lecteurs seront frustrés par le texte et qu’il devrait être réécrit.

Cela peut sembler farfelu, mais essayez cette méthode avant de l’écarter. Dans une étude gouvernementale sur la lisibilité d’information liées aux services de santé, un panel d’expert a catégorisé des articles de santé comme étant faciles ou difficiles. Nous avons ensuite fait passer des tests Cloze en utilisant ces articles à des participants dont le niveau d’alphabétisation allait de bas à moyen. Nous avons découvert que les résultats reflétaient ceux du panel d’expert. Le score moyen des articles dits « faciles » était de 60, indiquant qu’ils avaient été écrits de manière appropriée pour ce public. Le score moyen des articles dits « difficiles » était de 39 : trop difficile pour ce public.

Les tests Cloze sont facile à créer, administrer et évaluer. Ils donnent une bonne idée de l’adéquation entre le contenu et le public visé. Si vous utilisez des tests Cloze seuls ou en combinaison avec d’autres tests utilisateurs, sachez que remplir ces blancs demande beaucoup d’efforts cognitifs. Prévoyez 25 blancs minimum pour avoir une étude de qualité, mais sachez qu’au-delà de 50 le test devient vite fatiguant.

Quand tester

Testez votre contenu à n’importe quel moment dans le processus de développement du site. Dès que vous avez du contenu, vous pouvez le tester. Vous avez besoin de convaincre votre patron de budgéter les tests de contenu ? Passez votre contenu dans une formule de lisibilité. Vous avez du contenu mais pas de wireframes ou de design visuel ? Faites un test Cloze pour évaluer le contenu. Est-ce que la compréhension contenu est cruciale pour terminer une tâche ou un ensemble de tâches ? Affichez le contenu lors de tests d’ergonomie.

Que tester

Vous ne pouvez pas tester chaque phrase de votre site et vous n’en avez pas besoin. Concentrez-vous sur les tâches importantes pour vos utilisateurs et votre produit. Par exemple, est-ce que votre centre de support reçoit des appels concernant des informations qui devraient se trouver sur le site ? Testez le contenu pour trouver si votre site laisse à désirer et à quel endroit.

N’attendez plus : allez-y !

Tout comme les tests d’ergonomie se concentrent sur ce que les utilisateurs font et non pas ce qu’ils disent faire, les tests de contenu déterminent ce que les utilisateurs comprennent et non pas ce qu’ils disent comprendre.

Quel que soit votre budget, votre calendrier et votre accès aux utilisateurs, il existe une méthode pour tester si votre contenu est approprié pour les personnes qui le lise. Donc, testez ! Si votre contenu fonctionne, vous serez vraiment fixé, sinon il ne vous restera plus qu’à le réécrire.

Translated with the permission of A List Apart and the author[s]. ]]> http://www.pompage.net/traduction/tests-de-contenu http://www.pompage.net/traduction/tests-de-contenu Wed, 26 Mar 2014 11:03:00 +0100 <![CDATA[Tests de contenu]]>

Par Angela Colter

Personne n’a besoin de vous convaincre qu’il est important de tester le design et les interactions entre votre site et les personnes qui auront à l’utiliser, pas vrai ? Mais si vous vous limitez à cela, vous passez à côté de retours sur la partie la plus importante de votre site : le contenu. Que le but de votre site soit de convaincre les gens d’adopter un nouveau comportement, d’acheter quelque chose ou simplement de les informer, si vous vous contentez de vérifier qu'ils parviennent à trouver l'information ou bien à réaliser une transaction, alors vous manquez l'essentiel : le contenu est-il approprié au public ? Sont-ils capables de lire et de comprendre ce que vous avez écrit ?

Prenez un site d’information médicale avec deux ensembles de fiches techniques : une version simplifiée pour le public de base et une version plus technique pour les médecins. Pendant les tests, un médecin participant qui lisait la version technique s’est arrêté pour nous dire : « Écoutez. J’ai cinq minutes entre deux patients pour comprendre l’essentiel de ces informations. Je ne fais pas de recherche sur le sujet, je veux juste en savoir suffisamment pour pouvoir en parler à mes patients. Si je n’arrive pas à comprendre rapidement, je ne peux pas l’utiliser ». Nous avions fait des suppositions incorrectes à propos des besoins de chaque segment du public. Nous serions passé à côté de cette révélation importante si nous n’avions pas testé le contenu.

Vous vous y prenez mal

Avez-vous déjà posé ces questions à vos utilisateurs à propos de votre contenu ?

Ces informations vous ont-elles plu ?
Avez-vous compris ce que vous avez lu ?

Il est tentant de poser ces questions mais elles ne vous aideront pas à découvrir si votre contenu est adapté à votre public. La question de savoir si le contenu plaît est très appréciée — surtout dans les études de marché — mais elle n’est pas pertinente dans l’évaluation de la conception car le fait que quelque chose plaise a très peu de rapport avec le fait de le comprendre et de l’utiliser. Dan Formosa donne des explications très intéressantes qui expliquent pourquoi vous devriez éviter de demander aux gens ce qu’ils apprécient pendant des recherches utilisateurs. Pour ce qui est de la question de la compréhension, il est utile d’en savoir un minimum sur la façon dont les gens lisent.

Le processus de lecture

La lecture est le fruit de deux processus cognitifs simultanés : le décodage et la compréhension.

Quand nous commençons à lire, nous apprenons que certains symboles représentent des concepts. Nous commençons par reconnaître des lettres et par associer les formes aux sons qu’elles représentent. Ensuite, nous passons à l’étape de la reconnaissance de mots entiers et de leur sens. Une fois que nous avons digéré ces mots de manière individuelle, nous pouvons passer à la compréhension : trouver ce que l’auteur a voulu dire en attachant ces mots les uns aux autres. C’est un travail difficile, en particulier si vous apprenez à lire ou si vous faites partie des près de 50% de la population qui ont de faibles capacités de lecture.

Même s’il est tentant de faire lire le texte à quelqu’un et de lui demander s’il l’a compris, vous ne devriez pas vous appuyer sur un simple « oui ». Il est possible de reconnaître tous les mots (décoder), et avoir pourtant mal appréhendé le sens (comprendre). Vous en avez probablement fait l’expérience vous-même : avez-vous déjà lu quelque chose jusqu’au bout pour vous apercevoir que vous n’aviez pas compris ? Vous reconnaissez chaque mot, mais parce que le texte n’est pas clair ou parce que vous êtres fatigués, le sens du passage vous échappe.

Alors comment déterminer si votre contenu est adapté à pour vos utilisateurs ? Voyons comment le prédire (sans utilisateur) et comment le tester (avec des utilisateurs).

Estimons-le

Les formules de lisibilité mesurent les éléments quantifiables de l’écrit, tels que la longueur des mots et des phrases, pour prédire le niveau de compétence nécessaire pour les comprendre. Ils peuvent constituer une façon rapide, facile, et bon marché de déterminer si un texte sera trop difficile à comprendre pour un public particulier. Les résultats sont faciles à comprendre : beaucoup donnent le niveau scolaire états-uniens du texte.

Vous pouvez acheter des logiciels de lisibilité. Il existe également des outils gratuits en ligne proposés par Added Bytes, Juicy Studio, et Edit Central. Enfin, vous pouvez toujours vous rabattre sur la formule de gradation Flesch-Kincaid de Microsoft Word.

Cependant, il y a un gros problème avec les formules de lisibilité : la plupart des propriétés qui rendent un texte facile à comprendre comme le contenu, l’organisation, ou la mise en page ne peuvent pas se mesurer de façon mathématique. Utiliser des mots courts et des phrases simples ne garantit en rien que le texte sera lisible. Les formules de lisibilité ne prennent pas en compte le sens. En aucun cas. Par exemple, prenons la phrase suivante de la page « A propos » de A List Apart. L’index SMOG estime qu’il faut un niveau de troisième pour la comprendre :

Nous recevons plus de courrier en une journée que nous pourrions en lire en une semaine.

Maintenant, réarrangeons les mots de façon à obscurcir le sens. Le résultat : toujours compréhensible pour un élève de troisième.

En une journée nous courrier plus qu’en une semaine recevons plus que nous pourrions en lire.

Les formules de lisibilité peuvent aider à prédire le niveau de difficulté du texte et vous aider à argumenter pour pouvoir le tester avec des utilisateurs. Mais ne les utilisez pas comme votre seule méthode d’évaluation, et ne réécrivez pas vos textes juste pour satisfaire une formule. Rappelez-vous, les formules de lisibilité estiment le niveau de difficulté d’un texte. Elles ne peuvent pas vous enseigner comment rédiger des textes compréhensibles.

Faire un test d’utilisabilité modéré

Pour déterminer si les gens comprennent votre contenu, faites-leur lire et appliquer de nouvelles connaissances. En d’autres termes, faites un test d’utilisabilité ! Voici comment créer des scénarios de tâches dans lesquels les participants interprètent et utilisent ce qu’ils ont lu :

  • Identifiez les problèmes cruciaux pour vos utilisateurs et vos affaires.
  • Créez des tâches qui testent les connaissances des utilisateurs sur ces problèmes.
  • Dites bien aux participants que ce ne sont pas eux qui sont testés mais bien le contenu.

Disons que vous testez SEPTA, un site de transport en commun. Il offre plusieurs types d’abonnement mensuels qui varient selon le moyen de transport utilisé et la distance parcourue : par exemple, le TransPass permet de prendre le métro, le bus ou le trolley. Un TrailPass vous permet aussi de prendre le train, etc. Si vous vouliez uniquement tester l’interface, vous articuleriez la tâche de la façon suivante :

Achetez un TrailPass mensuel.

Mais vous souhaitez tester avec quelle facilité le contenu explique la différence entre les abonnements pour que les gens puissent choisir celui qui leur convient le mieux. Ainsi, articulez la tâche de cette façon :

Achetez l’abonnement le meilleur marché qui répond à vos besoins.

Vous voyez la différence ? La première version ne requiert pas des participants qu’ils prennent en compte le contenu du tout. Elle leur dit simplement quelle version choisir. La deuxième version leur demande d’utiliser le contenu pour déterminer quelle option est la meilleure pour eux. Soyez sûr d’obtenir des participants qu’ils articulent explicitement leurs besoins pour que vous puissiez juger s’ils ont choisi la meilleure option.

Demandez aux participants de penser à haute voix pendant qu’ils lisent le contenu. Vous obtiendrez de précieux indices sur ce qui leur paraît confus et pourquoi. Idéalement, vous souhaitez que vos utilisateurs comprennent le texte dès leur première lecture. S’ils ont besoin de relire quoi que ce soit, vous devez clarifier le texte. Demandez aussi à vos participants de paraphraser certaines portions ; s’ils ne comprennent pas l’idée générale, vous feriez mieux de recommencer.

Pour déterminer quand les scénarii et les explications de texte sont corrects, vous devez savoir à quoi ressemblent les bonnes réponses. S’il le faut, travaillez avec un expert sur le sujet pour créer une feuille de réponses avant de diriger les séances. Vous pouvez organiser des séances de test utilisateur modérées en temps réel soit en personne soit à distance. Mais vous pouvez également utiliser des méthodes asynchrones.

Faites un test d’utilisabilité non modéré

Si vous avez besoin d’un panel plus conséquent, que vous avez un budget serré ou que le temps presse, essayez une étude à distance sans modérateur. Envoyez aux participants l’un des outils de test utilisateur de votre choix comme Loop11 ou OpenHallway, donnez-leur des tâches à réaliser et enregistrez leurs réponses. Vous pouvez même utiliser quelque chose comme SurveyMonkey et formater votre étude comme un test à choix multiple : cela vous prendra plus de temps au début que des questions ouvertes car vous devez définir les réponses possibles à l’avance mais ainsi l’évaluation quantitative sera plus rapide.

La clé du succès d’un test à choix multiple réussi est de créer des questions sans équivoque.

  • Formulez votre question dans une forme affirmative et pas négative.
  • Incluez seulement une seule réponse correcte ou clairement meilleure.
  • Inventez entre deux et quatre réponses incorrectes (des distracteurs) qui pourraient être plausibles si vous ne compreniez pas le texte.
  • Assurez-vous que les alternatives s’excluent mutuellement.
  • Évitez de donner des indices dans les réponses.
  • Évitez d’utiliser « Toutes les options ci-dessus » ou « Aucune option ci-dessus » en tant que choix.
  • Évitez d’utiliser « jamais », « toujours », et « seulement ».

Pensez aussi à ajouter la possibilité de répondre « Je ne sais pas » pour éviter que les participants ne cochent une réponse au hasard juste pour passer la question. Il ne s’agit pas du bac. Une réponse choisie par défaut ne vous aidera pas à analyser votre contenu.

Scénario de tâches :

Vous souhaitez acheter des chèques voyage avec votre carte de crédit. Quel pourcentage s’applique à votre achat ?

Réponses possibles : Le taux annuel standard de 10.99% Le taux annuel pour avance de liquide de 24.24%* Le taux de pénalité de 29.99% Je ne sais pas.

(* Cette réponse est la réponse correcte à en croire le contrat de mon propre organisme de crédit)

Tout comme dans les tests modérés, faites comprendre aux utilisateurs que le test concerne le contenu et non leurs capacités.

Utilisez un test de Cloze

Un test de Cloze enlève certains mots d’une partie de votre texte et demande à vos utilisateurs de remplir les mots manquants. Les participants au test doivent se référer au contexte ainsi qu’à leurs connaissances antérieures du sujet pour identifier les mots effacés. C’est basé sur la théorie de Gestalt de complétude – dans laquelle le cerveau essaie de remplir les pièces manquantes – et l’applique à l’écrit.

Cela ressemble à ceci :

Si vous voulez _____ si les ______________ de votre site comprennent votre contenu, alors vous _____ le tester avec eux.

Cela ressemble à un exercice de remplissage, n’est-ce pas ? Mais au lieu d’essayer d’inventer la phrase la plus amusante, la plus étrange ou la plus intéressante, comme dans le jeu américain Mad Libs, les participants doivent deviner le mot exact que l’auteur a utilisé. Même si les tests Cloze sont rares dans le champ de l’expérience utilisateur, les éducateurs les utilisent depuis des décennies pour s’assurer qu’un texte est adapté à leurs étudiants surtout dans les cours d’anglais deuxième langue.

Voilà comment faire :

  • Prenez un extrait de texte de 125 à 250 mots à peu près.
  • Enlevez un mot sur cinq en le remplaçant par un espace blanc.
  • Demandez aux participants de remplir les espaces avec le mot qui, selon eux, a été enlevé.
  • Établissez un score en comptant le nombre total de bonnes réponses et en le divisant par le nombre total d’espaces blancs.

Un score de 60% ou mieux indique que le texte est approprié à votre public. Les participants ayant obtenu entre 40 et 60% auront quelques difficultés à comprendre le texte original. Ce n’est pas rédhibitoire, mais cela veut dire que le public aura besoin d’aide supplémentaire pour comprendre votre contenu.
Un score de moins de 40% veut dire que les lecteurs seront frustrés par le texte et qu’il devrait être réécrit.

Cela peut sembler farfelu, mais essayez cette méthode avant de l’écarter. Dans une étude gouvernementale sur la lisibilité d’information liées aux services de santé, un panel d’expert a catégorisé des articles de santé comme étant faciles ou difficiles. Nous avons ensuite fait passer des tests Cloze en utilisant ces articles à des participants dont le niveau d’alphabétisation allait de bas à moyen. Nous avons découvert que les résultats reflétaient ceux du panel d’expert. Le score moyen des articles dits « faciles » était de 60, indiquant qu’ils avaient été écrits de manière appropriée pour ce public. Le score moyen des articles dits « difficiles » était de 39 : trop difficile pour ce public.

Les tests Cloze sont facile à créer, administrer et évaluer. Ils donnent une bonne idée de l’adéquation entre le contenu et le public visé. Si vous utilisez des tests Cloze seuls ou en combinaison avec d’autres tests utilisateurs, sachez que remplir ces blancs demande beaucoup d’efforts cognitifs. Prévoyez 25 blancs minimum pour avoir une étude de qualité, mais sachez qu’au-delà de 50 le test devient vite fatiguant.

Quand tester

Testez votre contenu à n’importe quel moment dans le processus de développement du site. Dès que vous avez du contenu, vous pouvez le tester. Vous avez besoin de convaincre votre patron de budgéter les tests de contenu ? Passez votre contenu dans une formule de lisibilité. Vous avez du contenu mais pas de wireframes ou de design visuel ? Faites un test Cloze pour évaluer le contenu. Est-ce que la compréhension contenu est cruciale pour terminer une tâche ou un ensemble de tâches ? Affichez le contenu lors de tests d’ergonomie.

Que tester

Vous ne pouvez pas tester chaque phrase de votre site et vous n’en avez pas besoin. Concentrez-vous sur les tâches importantes pour vos utilisateurs et votre produit. Par exemple, est-ce que votre centre de support reçoit des appels concernant des informations qui devraient se trouver sur le site ? Testez le contenu pour trouver si votre site laisse à désirer et à quel endroit.

N’attendez plus : allez-y !

Tout comme les tests d’ergonomie se concentrent sur ce que les utilisateurs font et non pas ce qu’ils disent faire, les tests de contenu déterminent ce que les utilisateurs comprennent et non pas ce qu’ils disent comprendre.

Quel que soit votre budget, votre calendrier et votre accès aux utilisateurs, il existe une méthode pour tester si votre contenu est approprié pour les personnes qui le lise. Donc, testez ! Si votre contenu fonctionne, vous serez vraiment fixé, sinon il ne vous restera plus qu’à le réécrire.

Translated with the permission of A List Apart and the author[s]. ]]> https://www.pompage.net/traduction/tests-de-contenu https://www.pompage.net/traduction/tests-de-contenu Wed, 26 Mar 2014 11:03:00 +0100 <![CDATA[Traduit ailleurs : Soin et alimentation des ingénieurs informatique]]>

Préambule

Suite à la lecture du billet "The care and feeding of software engineers (or, why engineers are grumpy)" écrit par Nicholas C. Zakas, Bertrand Tornil et moi-même avons été frappés par sa pertinence et avons décidés de le diffuser autour de nous. Malheureusement, la barrière de la langue n'a pas permis une diffusion aussi large que nous le voulions. C'est pourquoi nous nous sommes attelés à sa traduction que nous vous proposons ici.

Si vous avez des améliorations à y apporter, n'hésitez pas à nous en faire part. Le meilleur moyen étant de proposer une (ou plusieurs) pull request sur le projet github. Bien que nous encouragions la diffusion de ce texte, et que nous mettions cette traduction à disposition librement, nous ne sommes bien sûr pas les détenteurs des droits du texte original. Référez-vous en à l'auteur original pour toute utilisation que vous voudriez en faire.

Mises à jour

Il n'y a pas si longtemps, Jenna Bilotta a écrit un excellent article intitulé "How designers and engineers can play nice" [1] (NdT: Comment faire travailler main dans la main designers et développeurs), dans lequel elle aborde les façons de faire travailler ensemble plus productivement les designers et les ingénieurs. Ayant été confronté aux mêmes soucis en travaillant avec des designers (mais aussi avec des ingénieurs lorsque j'étais du côté interface utilisateur), j'ai apprécié l'approche pragmatique qu'elle suggère. Il est toujours bénéfique de respecter les méthodes de travail des autres intervenants et de comprendre leur façon de penser lorsque l'on travaille ensemble.

Elle préconise notamment aux ingénieurs de ne pas dire "non" si vite. Cela m'a interpellé et m'a trotté dans la tête un moment. Ma première réaction a été "mais vous ne comprenez pas pourquoi nous disons non !". Puis un million d'autres justifications me sont venues à l'esprit. En fait, elle a raison. Nous disons "non" très vite et pas seulement aux designers, mais à tout. Cela m'a amené à réfléchir à la psychologie des ingénieurs informatique et à ce qui fait que nous fonctionnons comme nous le faisons.

Jouons carte sur table, les développeurs ont généralement la réputation d'être arrogants, désagréables et lunatiques. Nous avons aussi la réputation de dire "non", de débattre de détails insignifiants et de prétendre savoir mieux faire le travail de n'importe qui d'autre mieux qu'eux. En général cette réputation est justifiée. C'est exactement ce que nous faisons presque tous les jours, tout comme nous codons tout en surveillant Twitter et Hacker News (NdT : site d'information concernant le développement informatique).

(Note : Certains diront que ce n'est pas vrai de tous les développeurs et ils auront raison. Il y a un petit nombre de développeurs pour qui tout ou partie de ce qui vient d'être dit est faux. Mais s'il vous plaît, avant de descendre en bas de cet article et poster un commentaire pour me dire à quel point tout cela est stupide, continuez la lecture.)

Les réputations ne se font pas aléatoirement, elles sont le fruit de l'expérience des gens. Ce qui me dérange dans cette réputation est que je connais personnellement de nombreux développeurs et qu'ils aiment généralement s'amuser, sont ouverts à la discussion (si il ne s'agit pas de sujet dogmatique) et sont d'une compagnie agréable. Ils font partie des gens avec qui l'on a envie de passer du temps hors du boulot. Alors comment ce fait-il que dans un environnement professionnel une autre personnalité apparaisse ?

J'ai une théorie. Cette théorie est que les développeurs se perçoivent d'une façon très différente de la façon dont les perçoivent ceux avec qui ils travaillent. J'en suis arrivé à cette conclusion après plus d'une décennie de travail dans l'industrie logicielle au sein de grandes et petites entreprises. Les entreprises (chefs de produit, designers, et managers) ont tendance à voir les développeurs comme des ouvriers. C'est le travail du chef de produit d'imaginer quoi fabriquer, le travail du designer de le rendre esthétique et le travail de l'ingénieur de construire l'aboutissement de leurs réflexions. Concrètement, les développeurs sont vus comme les exécutants de cette industrie.

Il s'agit de quelque chose à propos duquel mon tout premier responsable m'a mis en garde. Lorsque la première entreprise dans laquelle j'ai travaillé a fermé, nous avons eu une discussion franche concernant ma carrière. Bien que nous n'ayons pas toujours été en accord, il m'a donné un excellent conseil (que je paraphrase ici) :

Nicholas, tu vaux mieux que ton code. Quelque soit la suite de tes aventures, assure-toi de ne pas être un simple exécutant. N'accepte pas un poste ou l'on te dise exactement ce que tu dois faire et comment le faire. Tu as besoin de travailler dans un environnement qui apprécie tes propositions autant que ta capacité à les réaliser.

Il avait tout à fait raison. De nombreuses sociétés veulent des exécutants, ils veulent des programmeurs et des ouvriers qui marchent au pas et restent dans le rang. A vrai dire je dirais que la plupart des sociétés veulent ça, qu'elles soient grandes ou petites. Je ne pourrais dénombrer la quantité de start-ups qui m'ont contacté pour m'offrir d'être associé en échange du développement de la vision du fondateur. Sous entendu : nous savons déjà exactement ce que nous voulons faire, nous avons juste besoin de quelqu'un pour l'exécuter.

Et c'est bien là que se situe le noeud du problème : les développeurs ne sont pas des ouvriers. Les développeurs sont des créateurs. Construire quelque chose c'est ce que vous faites lorsque vous achetez un meuble chez Ikea et que vous le ramenez à la maison. Les instructions de montage sont écrites sur un papier et si vous les suivez étape par étape, vous obtiendrez la si jolie petite table que vous désiriez tant. Créer est un tout autre processus qui donne naissance à quelque chose sans indication ni instruction. Cela consiste à partir d'une feuille blanche pour aboutir à une toile de maître. Les développeurs ne se mettent pas au développement parce qu'ils veulent que quelqu'un leur dise ce qu'ils doivent faire, ils se mettent au développement parce qu'ils ont découvert qu'ils pouvaient créer des choses utiles. Chaque développeur tombe amoureux du développement parce qu'il a fait un jour un petit programme utile et qu'il y est devenu accro.

Dans le triumvirat du logiciel constitué des chefs de produit, des designers et des développeurs, il n'y a que des développeurs que l'on attend qu'ils fassent taire leur esprit créatif et se contentent de produire. Les développeurs ne sont pas stupides, ils le voient bien et se mettent à éprouver du ressentiment. Les développeurs veulent faire partie du processus créatif et cela leur est refusé. En fin de compte vous vous retrouvez avec la personnalité typique des développeurs agrémentée de mauvaise humeur.

Les chefs de produits sont des gens intéressants. Leurs idées ainsi que leur capacité à comprendre le marché sont impressionnants. Ils ont aussi une certaine tendance à croire que leurs idées sont totalement abouties alors qu'en réalité il y a des trous si grands que l'on pourrait y faire passer des trains complets. Je le dis avec beaucoup d'affection, car j'ai de nombreux amis chefs de produit, mais ils savent bien ce que je pense car je le leur ai déjà dit de vive voix à un moment ou un autre. Il ne s'agit pas là d'une critique des chefs de produit, c'est juste dans leur nature. Leur travail est créatif et les idées n'apparaissent jamais totalement abouties. Mais c'est bien l'un des éléments qui rend les développeurs grincheux.

Les développeurs aussi bien que les chefs de produits ont tendance à croire, à tort, que des spécifications et prérequis équivalent à un manuel de montage de chez Ikea. Dans les faits ces documents contiennent rarement assez d'informations pour concrètement construire le produit et ne sont généralement qu'un point de départ. Et cela pose un problème crucial au développeur.

Pour comprendre le problème, imaginez-vous devoir construire une maison. Quelqu'un a décidé qu'il voulait construire une maison sur un certain terrain. La maison va avoir deux étages et un garage. Il y a même un croquis de la façade gribouillé sur un coin de nappe. Cette personne vient vous voir avec ces informations et son coin de nappe et vous dit "Ça devrait te suffire pour commencer à construire ?". Êtes-vous capable de commencer la construction ?

Normalement, vous ne devriez pas pouvoir commencer à construire la maison avec ces éléments là. Vous ne connaissez pas la superficie, vous ne disposez pas des plans intérieurs, vous ne connaissez même pas le code d'urbanisme à respecter pour la construction d'une maison. Il n'y a vraiment pas assez d'information pour commencer, ne serait-ce qu'à creuser les fondations. A ce moment vous allez dire à votre client qu'il est inconscient et doit savoir exactement ce qu'il veut. Maintenant, imaginez que vous ne puissiez pas le faire car quelqu'un a déterminer une date de livraison que vous êtes responsable de tenir.

"Hé bien", dit le client, "pourquoi ne commencez-vous donc pas à construire et je vous fournirai les détails au fur et à mesure. Comme ça on ne perd pas de temps."

Vous savez qu'il vous manque des informations pour commencer la construction, mais que continuer à questionner le client ne vous fournira pas plus d'éléments dans l'immédiat. Que faites-vous ? Vous commencez à faire des suppositions.

L'adage "when you ASSUME, you make an ASS of U and ME" (NdT: jeu de mot non transposable sur les termes écrits en majuscule qui se traduirait littéralement par "en faisant des suppositions, tu fais de nous deux des imbéciles"), est on ne peut plus vrai. Les suppositions sont dangereuses et souvent fausses. Cependant sans faire de suppositions, vous ne pouvez avancer. Alors c'est ce que vous faites. Vous commencez par supposer que ce que vous savez est vrai, la maison aura deux étages et un garage. Le garage devrait-il être mitoyen ou indépendant. Quelle taille devrait-il faire ? Bon, disons qu'il est indépendant et qu'il puisse contenir une voiture. Cela signifie que vous pouvez commencer le garage comme une structure indépendante et que quand il y aura plus de détails sur la maison vous pourrez continuer à côté du garage.

Après une semaine de travail sur le garage, votre client revient avec plus de détails. En fait la maison doit avoir trois étages (Ouf ! Heureusement que vous n'avez pas commencé par là) et elle aura huit salles de bain. Il n'y a pas plus d'informations concernant le garage, mais la maison sera peinte en bleu. Vous supposez logiquement que le garage indépendant sera également peint en bleu et vous vous y attelez.

Quelques jours plus tard, le garage est presque terminé. Vous êtes plutôt satisfait du résultat avec le peu d'informations dont vous disposiez. Vous êtes maintenant prêt à attaquer la maison lorsque le client revient avec plus de détails. Le garage devra en fait contenir 2 voitures et doit être mitoyen. Cela vous fend le coeur car vous venez juste d'achever une belle construction mais qu'il faut tout raser à la pelleteuse afin de construire ce qui est réellement demandé. Pire encore, il vous reste maintenant moins de temps pour accomplir le projet complet, et cela vous rend grincheux.

Si cette analogie vous semble farfelue, c'est que vous n'avez probablement jamais travaillé en tant que développeur. Nous sommes vraiment confrontés à ce genre de situation chaque jour. Nous essayons de faire avancer les projets en faisant appel à nos capacités de création pour finir par nous rendre compte que nous ne pouvons pas deviner ce que les gens ont en tête et que nous nous trompons à propos de ce que nous devons réellement bâtir. Et pourtant si nous ne le faisions pas nous devrions rester à attendre car personne n'aime le modèle de développement en cascade.

Dans presque toutes les autres industries de fabrication, il est convenu que tous les besoins et détails sont discutés en amont et entérinés avant le début de la fabrication. Sauf dans le logiciel. Dans le logiciel, il n'y a "pas assez de temps" pour mettre au point tous les éléments à l'avance. L'importance d'avancer nous est martelée dès le premier jour. Du coup, les ingénieurs apprennent à remplir les blancs laissés par les chefs de produit afin de faire avancer le projet. Les chefs de produit ont bien sûr la réputation de changer souvent d'avis, ce qui signifie que les suppositions des ingénieurs sont souvent invalidées au cours de la vie du projet.

Est-il surprenant que les développeurs aient tendance à s'user rapidement et à changer fréquemment d'emploi ?

Le changement de contexte est l'ennemi de tout créatif. Une fois plongé dans un mode créatif, "le flux" comme certains l'appellent, le fait d'être dérangé pour se focaliser sur autre chose interrompt totalement le processus. Oui, écrire du code est un processus créatif. C'est à la fois logique et créatif. Nous n'écrivons pas simplement du code, nous le forgeons.

Il semble communément admis chez les gens qui gère le temps de travail de développeurs qu'il est facile de passer d'une tâche à une autre. Après tout, comme certains m'ont déjà dit, du travail c'est du travail. Vous l'orientez dans la direction nécessaire comme un canon et feu. Bien sûr c'est totalement erroné. Si vous consacrez beaucoup de temps à une tâche et qu'il vous est demandé de la laisser de côté pour faire autre chose, il n'est pas simple d'y revenir et de reprendre là ou vous en étiez. Cela nécessite un temps de ré-acclimatation en revenant sur la première tâche pour se remettre dans le contexte, et c'est là le coût du changement de contexte. Même si la nouvelle tâche ne demande que quelques minutes, c'est suffisant pour interrompre le flux et cela rend les développeurs moins productifs.

Il s'agit là de l'une des choses qui rend les développeurs le plus grincheux : changer constamment les priorités. Si quelque chose est prioritaire un jour et qu'autre chose l'est le lendemain, cela signifie immanquablement un changement de contexte. Les créatifs n'aiment pas être interrompus avant d'avoir fini, c'est pourquoi les développeurs sont capables de travailler jusqu'à l'aube pour terminer ce qu'ils sont en train de faire. Interrompre le flux nous rend moins productif.

Les vraies priorités ne changent pas, elles sont figées. La fréquence à laquelle les gens au dessus de nous changent d'avis est incroyablement frustrant pour les développeurs. Nous sommes, la plupart du temps, prêt à monter au front pourvu que l'on nous indique la direction à suivre. Mais si vous nous dites un jour que l'on construit une maison puis le lendemain que l'on construit une voiture, il faut vous attendre à quelques dissensions dans les rangs.

Les développeurs sont mis en position difficile tous les jours, mais nous ne sommes tout de même pas des victimes, même si les plus mélodramatiques d'entre nous ont tendances à agir comme tels. Si nous sommes grincheux c'est en partie à cause de nous même et de quelque chose qui est profondément ancré en la majorité des développeurs. Nous sommes affligés d'un défaut tragique : nous surestimons nos connaissances et nos capacités.

Ce défaut se manifeste de plusieurs manières. La plus fréquente apparaît dans les estimations de temps. Presque tous les ingénieurs que je connais sous-estiment systématiquement le temps qu'il leur sera nécessaire pour accomplir une tâche ou une série de tâches. Seuls les meilleurs des meilleurs sont capables de fournir une estimation de temps précise et de s'y tenir, alors que les autres se trompent parfois d'un facteur 2 voir plus. Le problème est qu'en tant que créatifs, les développeurs n'arrivent pas à prévoir les problèmes qu'ils vont rencontrer.

Même si de nombreux développeurs se plaignent que les chef de produit changent d'avis, presque aucun n'en tient compte dans ses estimations. Aucun temps n'est prévu pour les réunions permettant de détailler les spécifications ou de faire des changements. Les bugs ? Notre code est parfait et ne comporte jamais de bugs, alors pas besoin de s'en préoccuper (et puis après tout la Q&A soulèvera bien ce que nous pourrions avoir raté). Certains des autres développeurs dont nous pourrions avoir besoin seront absents ? Pas de soucis, nous trouverons bien quelqu'un pour compenser.

En cumulant tout cela on en arrive très rapidement à ne pas tenir les délais de livraison, et pourtant je n'ai pas encore comptabilisé la raison principale à nos retards de livraison : la non prise en compte du temps d'apprentissage. Cela nous ramène directement à notre défaut. Nous pensons que nous savons déjà comment accomplir la tâche qui nous est demandée alors que très souvent elle inclut des choses que nous n'avons jamais faites. Les estimations partent d'une hypothèse de parfaite connaissance, comme lorsque vous avez le manuel Ikea et n'avez qu'à vous mettre au travail. En réalité, de nombreuses tâches nous demandent de faire des choses que nous n'avons jamais faites auparavant.

Au cours de leurs études d'informatique les ingénieurs se voient inculqués un sentiment de sécurité tout à fait erroné. Ils en sortent en pensant qu'ils comprennent les logiciels et le processus de développement de logiciel alors qu'en fait, ils ne savent presque rien. Dans mon premier emploi, j'étais ce jeune diplômé arrogant expliquant à tout le monde qu'ils s'y prenaient mal. Ce n'est que plusieurs années après que j'ai enfin compris que je ne savais rien.

Les cours d'informatique durant les études ne vous préparent pas à affronter les problèmes auxquels vous allez être confrontés dans votre vie professionnelle. Ils vous fournissent la connaissance d'un large éventail de concepts afin que vous ne soyez pas totalement désemparés lorsque vous les rencontrerez dans votre travail. Vous y apprenez ce que sont des variables, des fonctions et des objets car ce sont des choses que vous allez rencontrer tout le temps. Vous y apprenez les bases de données et le requétage bien que les formes normales qui vous sont inculquées soient presque totalement inutiles. Vous passez un temps incroyable sur les algorithmes de tri et les structures de données, ce qui est très éloigné de votre activité lorsque vous codez dans votre vie professionnelle. En résumé, les programmes d'informatique vous fournissent les solutions à des problèmes que vous ne rencontrerez pas dans votre activité professionnelle. Si j'ai besoin de trier quelque chose aujourd'hui, j'utilise la méthode sort() (NdT : tri en français). Si j'ai besoin d'une queue ou d'une liste chaînée, j'emploie l'implémentation native du langage que j'utilise. Ces problèmes sont déjà résolus.

Nous sortons donc des études en pensant que nous savons tout faire alors qu'en réalité nous ne savons faire que ce qui a déjà été fait. En fait, nous connaissons une petite partie de ce qui à déjà été fait. Et pourtant nous nous comportons comme si nous connaissions tout, supposant ainsi une connaissance parfaite, et fournissant des estimations de temps qui sont bien trop courtes car nous ne prenons pas en compte l'apprentissage.

Une autre partie du problème est nichée dans nos fragiles egos. Nous avons peur que si nous donnons une estimation "trop longue", nous baissions dans l'estime des gens. Ils nous disent que les "bons développeurs" sont ceux qui travaillent le plus vite, et nous acquiesçons. J'ai toujours été fasciné lorsqu'une estimation est faite sur un projet et qu'un non développeur revient et dit que celle-ci est trop longue. Pour commencer, comme je l'ai mentionné plus haut, elle est déjà probablement trop courte à cause de notre défaut. Ensuite, comment un non développeur pourrait bien savoir combien de temps sera nécessaire pour implémenter quelque chose ? Et cela nous conduit à un autre problème.

Peu de phrases ont le pouvoir d'énerver un ingénieur plus que "J'ai déjà codé". Qu'elle vienne d'un chef de produit, d'un designer ou d'un manager, cette phrase adressée à un ingénieur n'amènera rien de mieux que du dédain. J'imagine que LeBron James me trouverait tout à fait comique, si je venais lui donner des conseils sur la tactique, sous prétexte que j'ai joué au basket dans la cour de récréation (NdT: LeBron James est un célèbre basketteur de NBA). Les développeurs subissent cela tout le temps.

Voici quelques énormités énoncées par des non-développeurs :

  • Je ne comprends pas en quoi c'est si compliqué. Ce ne sont que quelques lignes de code. (Techniquement, n'importe quel développement ne consiste qu'en quelques lignes de code ; cela n'en fait pas un développement facile pour autant).
  • Untel nous dit que cela peut être fait en x jours. (Ceci signifie que Untel a l'expérience sur le problème et a une vision claire de la solution. Moi non ; je dois commencer par me mettre à niveau)
  • Que peut-on faire pour rendre ça plus rapide ? Est-ce qu'il vous faut plus de développeurs ? (Or, ajouter plus de développeurs sur un problème ne fait souvent qu'empirer les choses. La seule façon de développer quelque chose plus vite, c'est de développer quelque chose de plus petit).

La pire chose que vous puissiez faire à un ingénieur, c'est lui dire que vous avez déjà développé. C'est un peu différent pour quelqu'un qui a réellement été ingénieur dans sa carrière. Dans ce cas, la personne dispose d'une crédibilité naturelle, mais limitée dans le temps (disons 5 ans ; au delà, tout aura changé). Mais quelqu'un qui n'a jamais développé professionnellement, ferait mieux de garder pour lui ses talents de bidouilleur, plutôt que de s'en servir pour donner son avis sur un développement.

(Soyons honnêtes, les designers sont également touchés par le problème. Chacun se pense expert en design car tout le monde aime les jolis choses. Ça ne fait pas de nous des experts pour designer quoi que ce soit).

Les développeurs sont en permanence confrontés au problème d'avoir trop de plats sur le feu. Comme nous sous-estimons le temps nécessaire pour finir une tâche, la plupart des développements sont en retard. Cela vaut aussi bien pour les grandes que les petites entreprises, tout le monde a ce problème. Être en retard mécontente la hiérarchie et aboutit à la conclusion qu'il n'y a pas assez de développeurs. Engagez plus de développeurs, disent-ils, et cela améliorera les choses.

Dans certains cas ajouter des ingénieurs fonctionnera. Dans la plupart des cas, cela ne fera qu'empirer le problème. Il est assez difficile de faire communiquer des gens créatifs entre eux, ajouter des développeurs ne fait qu'amplifier le problème. Les développeurs n'ont pas le droit d'être à court de travail en général. Si la hiérarchie découvre que des ingénieurs sont inactifs, elle a tendance à leur créer du travail.

Cela m'est arrivé de façon quasi caricaturale il y a quelques années. Nous concevions la nouvelle page d'accueil de Yahoo, la reconstruisant complètement avec un nombre réduit de gens. Il s'agissait en fait d'une situation idéale où un petit nombre d'entre nous pouvions nous focaliser sur l'architecture à partir de laquelle la future page serait construite. La conception était terminée et nous étions prêt à développer le prototype quand tout à coup on nous a donné huit développeurs. Notre plan de marche ? Ces développeurs devaient immédiatement commencer à écrire du code pour la nouvelle page d'accueil. Sacré casse-tête étant donné que l'architecture n'existait pas encore. Mais les ingénieurs ne pouvaient pas rester sans travail, ils avaient été assignés au projet et devaient commencer à faire quelque chose. Le problème classique de la poule et de l'oeuf.

Dans un monde idéal, nous aurions pu réaliser un prototype de l'architecture et alors reçu des ingénieurs supplémentaires pour nous aider à l'implémentation. Dans cette situation nous étions coincés. Ce que nous avons finalement fait est que nous avons utilisé l'architecture existante d'un autre projet à laquelle nous avons mise une façade simulant l'existence de architecture que nous avions conçue. Les développeurs ont ainsi pu commencer leur travail et nous avons pu travailler à la construction de l'architecture cible en parallèle. C'était une très mauvaise solution à un très mauvais problème et cela a fini par se retourner contre nous lorsque les développeurs ont atteint les limites de la façade que nous avions mise en place avec des fonctionnalités qui auraient du être implémentées dans la nouvelle architecture mais qui n'existaient pas encore. J'ai finalement du dire au manager qu'à moins de nous donner le temps de construire la véritable architecture le château de carte que nous avions bâti allait s'effondrer.

Avoir trop d'ingénieurs sur un projet est un sérieux problème. Ajouter des ingénieurs suppose qu'il existe des tâches à accomplir qui peuvent être parallélisées, alors qu'en réalité le nombre de tâches parallélisables sur un projet est faible et limité. Lorsqu'il y a plus d'ingénieurs que nécessaires sur un projet, le temps de développement effectif diminue pour faire de la planification, de la synchronisation et de la coordination. Pour revenir à ma métaphore précédente, vous ne pouvez bâtir le second étage tant que le rez-de-chaussée n'est pas terminé. De nombreuses tâche dans un projet de développement sont en fait séquentielles et ajouter des ingénieurs n'accélère donc pas les choses. Ou comme le disait souvent l'un de mes précédents collègues, "je m'en fous du nombre de femmes vous me donnez, cela prend toujours neuf mois pour faire un bébé."

Si je résume, sans assez d'information, avec des prérequis qui changent, un socle de connaissances pas suffisamment solide pour faire le travail aisément, et l'obligation de baser notre travail sur des spéculations erronées, nous trouvons toujours le moyen de venir au travail tous les jours. Étant des gens créatifs, nous pouvons nous en accommoder parce que nous savons qu'un jour des personnes utiliserons le fruit de notre travail. Voici ce qui fait avancer les ingénieurs plus que tout autre chose : l'idée que des personnes que nous ne connaissons pas seront affectées par notre travail. Que vous travailliez sur un site web visité par des millions de personnes par jours, ou bien sur un système de point de vente pour restaurants, savoir que cela aura de l'impact sur la vie des gens constitue un puissant stimulant

Traduction : "Je ne le dirai jamais assez : un ingénieur ne s'épuise pas à cause d'un travail trop dur, il s'épuise à cause des changements de direction incessants, ainsi que sur le fait de ne pas livrer."

Quand il y a des retards à cause de changement d'avis, nous devenons grincheux. Incroyablement grincheux. Notre objectif de proposer le fruit de notre travail aux gens s'en trouve différé, et c'est démoralisant. Et pourtant, un développeur n'a rien d'un perfectionniste. Nous sommes souvent partant pour sortir quelque chose de juste bien, plutôt que continuer à travailler sur quelque chose de mieux, mais qui ne sort pas. Nous aimons construire des petites choses afin de les sortir rapidement, pour plus tard pouvoir les combiner ensemble en quelque chose de plus grand. Pourquoi ? Parce que c'est ainsi que nous pouvons toucher les gens.

Maintenant, nous savons tous que les retards font partie intégrante de l'industrie logicielle. Les ingénieurs travailleront comme des malades si leur estimation de temps est dépassée, afin d'essayer, et de parvenir à faire fonctionner leur produit. Les ingénieurs ne détestent pas le dur labeur et les horaires à rallonge ; nous détestons ne pas régler les problèmes.

En tant que développeur, notre travail se déroule selon un rythme très différent des autres. Par exemple, ce n'est pas un designer ou un chef de produit qui devra se lever au milieu de la nuit parce que quelque chose est cassé en production (bien que j'ai connu des chefs de produit qui tenaient à être appelés lorsque cela arrivait). Une fois j'étais sur le point de partir de chez moi avec mon rendez-vous (NdT : rendez-vous galant) lorsque j'ai reçu un appel du travail à propos d'un problème en production. Elle s'est assise et a attendu patiemment durant une heure alors que j'essayais frénétiquement de régler le problème. Elle a fini par partir (et je ne peux l'en blâmer) me laissant à mon travail avec mes collègues compatissant à mon malheur sur IRC.

Pourtant vous entendrez rarement des ingénieurs se plaindre des horaires à rallonge ou de devoir se lever au milieu de la nuit à cause d'un problème en production. Le logiciel est notre bébé et nous aimons en prendre soin. Cela signifie que si il faut le nourrir au milieu de la nuit, nous le faisons. Si il a besoin d'un peu plus d'attention pendant le week-end, nous le faisons aussi et tout cela avec le sourire car notre création grandit.

Les développeurs sont heureux quand ils mettent la touche finale aux derniers octets du code d'une tâche. Je n'ai jamais vu un développeur aussi joyeux que quand il envoie un email pour dire qu'il a fini quelque chose et que c'est prêt à être testé. Pourtant cet joie se volatilise rapidement lorsqu'au cours des dix minutes qui suivent, les rapports de bugs sont envoyés concernant son tout nouveau bébé.

Essayez d'imaginer cela une seconde. Vous avez travaillé pendant une journée, une semaine ou plusieurs semaines sur quelque chose et vous venez de le terminer. Vous êtes fier car vous avez accompli la tâche que l'on vous avait confié, vous avez probablement appris des choses que vous ne connaissiez pas auparavant. Tout ce à quoi vous aspirez c'est de prendre un peu de temps pour admirer votre travail. Peut-être même que quelqu'un vous dise "bon boulot". Et qu'obtenez vous ? Des bugs. Telle chose ne fonctionne pas, telle autre chose n'est pas à sa place et ainsi de suite. Notre bonne humeur s'envole aussi vite que nous nous attelons à réparer ce qui ne va pas.

Compte tenu de tout ce que j'ai déjà mentionné, voici les raisons classiques pour lesquelles les ingénieurs disent non (ou bien semblent grincheux):

  • La demande est venue tardivement au cours du développement et il n'y a pas assez de temps pour s'adapter avant la date de livraison.
  • La demande annule une ou plusieurs hypothèses qui ont été faites dès le début du processus pour avancer le projet.
  • La demande va à l'encontre d'une ou plusieurs demandes précédentes.
  • La demande augmente la quantité de travail qui doit être fait avant la livraison.
  • Nous sommes tellement épuisés que toute demande est perçue comme une tonne de travail supplémentaire et nous ne voulons simplement pas en supporter plus.

Gardez à l'esprit que toutes ces raisons, exceptée la dernière, sont liées au rapport qu'entretient l'ingénieur et la date de livraison de son projet. Nous voulons que les tâches se terminent, et la seule façon d'y parvenir, c'est de ne pas les changer pendant que nous travaillons dessus. Quand un changement survient, c'est là que nous devenons réellement grincheux, et que le "non" arrive, sortant de nos bouches avant même que vous ayez fini votre phrase.

Alors, comment gérez-vous ces grincheux pourtant nécessaires dans votre entreprise ?

Revoyons un instant ce qui fait avancer les ingénieurs :

  • Être créatif
  • Résoudre des problèmes
  • Avoir une incidence sur la vie des gens

Notez une absente dans cette liste. L'argent. Donner bêtement de l'argent à un ingénieur ne le satisfera que rarement. Cela fait cliché, mais ça n'a rien à voir avec l'argent. L'argent permet de s'amuser, mais ce qui nous intéresse vraiment c'est le code et la création. Lorsque nous pouvons le faire dans un environnement sain, nous sommes heureux, et pour très longtemps.

Alors, comment allez-vous créer un environnement sain pour les ingénieurs ?

Les ingénieurs logiciels sont créatifs, à l'instar des chefs de produit, et des designers, c'est pourquoi vous devriez veiller à les inclure dans le processus de création. Les ingénieurs constituent des atouts considérables lors des sessions de brainstorming et pour revoir les conceptions initiales. Donnez à chaque ingénieur l'opportunité de rencontrer l'équipe créative et de travailler directement avec elle (pas nécessairement tous en même temps). Pour faire court, insérez l'ingénieur le plus tôt possible dans le processus de création. Aucun ingénieur n'aime découvrir les spécifications et les maquettes jetées sur un mur, sans les comprendre.

Les ingénieurs sont très logiques. Ainsi, en étant dans ces réunions préliminaires afin de saisir d'où viennent les besoins, ils peuvent permettre d'écarter directement un certain nombre de problèmes. Quand les ingénieurs se sentent comme des ouvriers, ils posent des questions et cela ralentit le processus. Lorsque les ingénieurs sont co-créateurs, il y a moins de questions et donc moins de retards par la suite dans le processus.

De plus, les ingénieurs sont souvent très en avance en termes de connaissance de ce qui est possible. Si vous prenez les développeurs d'interfaces, nous savons ce que les navigateurs peuvent faire bien avant les chefs de produit ou les designers. Quand nous partageons ce savoir, nous donnons en fait à tous de nouvelles idées sur comment construire un projet, partant de ce qu'il est possible de faire. Imaginez si vous essayez de créer un site de partage de photo, sans savoir que vous pouvez maintenant effectuer un glisser-déposer de fichiers depuis votre bureau vers le navigateur, afin d'envoyer le fichier au serveur [2] ? Sans cette information, imaginez à quel point le produit final s'en trouverait modifié.

Donc, invitez les ingénieurs dans le processus de création, le plus tôt possible. Laissez les vous faire un retour et vous donner des informations sur ce qu'il est possible de faire. Moins notre conduite nous est dictée, plus nous sommes à l'écoute et heureux dans notre travail. Nous donner le sentiment d'avoir contribué à la création du produit est le seul moyen d'y arriver vraiment.

Pour faire suite au thème des développeurs vus comme des créatifs, essayez de nous offrir des opportunités d'être créatifs. Il y a une bonne raison si les hackdays et hackweeks (NdT : journées ou semaines de bidouillage, i.e. activité de développement libre regroupant les différents métiers de l'industrie logicielle) sont si populaires ; c'est parce qu'il s'agit de l'échappatoire créatif qui permet aux développeurs de recharger les batteries et redécouvrir leur amour pour le code. Ces événements de bidouillage sont des moments pendant lesquels les développeurs peuvent être complètement créatifs, car libérés des contraintes de leur travail quotidien.

Un hack day chaque trimestre est suffisant pour enthousiasmer les gens. Vous voulez que les gens soient encore plus excités ? Donner un thème au hack day. Donnez des récompenses au plus créatif, à celui qui a le plus de chances de passer en production et ainsi de suite. L'objectif est d'alimenter la créativité des développeurs afin qu'en revenant à leur poste, ils se soient rafraîchis les idées et soient de nouveau prêts à contribuer.

Gardez à l'esprit que les développeurs ne sont pas uniques à cet égard. Tout le monde a besoin de temps pour être créatif. D'après mon expérience, les chefs de produit et les designers ont tendance à l'obtenir plus fréquemment. Ils ont du temps pour des conférences ou des ateliers hors du bureau alors que les développeurs ont tendance à être oubliés.

D'ailleurs, les événements de bidouillage ne sont pas le seul moyen de faire cela, mais ils sont le meilleur moyen de commencer. Vous pouvez aussi allumer la flamme de la créativité en envoyant les ingénieurs à des conférences leur permettant d'améliorer leurs compétences. Permettre aux développeurs d'acheter des livres qui contribuent à leur savoir sur les deniers de la société. Donner l'opportunité aux développeurs d'exprimer leurs idées à propos des projets sur lesquels ils travaillent. Google donne à ses ingénieurs les fameux 20% de leur temps pour travailler à des projets personnels. Tout cela participe grandement à établir une excellente relation avec vos ingénieurs.

Étant donné le volume horaire et les exercices de concentration que nous faisons en général, les développeurs ont besoin de faire des pauses. Malheureusement, nous ne sommes pas très doués pour planifier cela. Nous sommes si pris dans le processus que nous oublions de prendre des vacances. Durant les cinq premières années de ma carrière, je pense avoir pris 7 jours de congés. Je ne sais pas pourquoi, mais nous ne sommes pas très bons pour prendre le temps de décompresser. C'est un problème.

L'usure du développeur a cela de singulier que nous avons l'habitude de passer outre. Quand l'usure devient vraiment trop pénible, nous partons, à la recherche de repos. Le pire c'est que les développeurs ne vous diront probablement jamais qu'ils approchent de ce point ; nous sommes trop fiers pour cela. Dans ma dernière équipe, j'ai dit aux développeurs que dès la première fois où ils se sentent frustrés ils doivent venir me voir et m'en parler. Je ne voulais pas qu'ils attendent et que cela devienne si fort que la seule façon d'en échapper soit de partir. Je ne voulais pas qu'ils partent, je voulais qu'ils soient heureux et la seule façon pour moi d'y parvenir était de savoir quand ils commençaient à ne plus l'être.

Incitez les ingénieurs à prendre du repos. Votre société donne des congés, alors assurez vous que les développeurs utilisent ces jours de vacances pendant l'année. Une fois tous les 4 à 5 mois au minimum. Les managers sont les mieux placés pour gérer cela car ils connaissent les agendas des projets.

Lorsque les ingénieurs prennent des jours à intervalle régulier, cela restaure leur côté créatif en les sortant de la rigueur nécessaire au respect des dates de livraison. Oui, il est possible que nous passions une partie de notre temps de repos à coder, mais il s'agit de nos propres créations et de ce fait c'est assez différent de ce que l'on fait au travail. C'est un élément important pour se changer les idées et se préparer pour la prochaine bataille.

Aussi ironique que cela puisse paraître, de nombreuses sociétés recrutent des développeurs mais ne les laissent pas vraiment coder. Au lieu de cela leurs journées sont remplies de réunions inutiles qui brident la productivité. En général, les développeurs sont plus productifs lorsqu'ils peuvent coder pendant au moins 4 heures d'affilée sans interruption.

Il est difficile de rentrer dans un bon flux de développement lorsque l'on sait que l'on a une réunion dans une heure ou deux, cela vous trotte dans la tête pendant que vous codez. Il est incroyablement improductif de coder pendant une heure, s'arrêter pendant une heure, coder pendant une heure, s'arrêter pendant une heure, etc ... Vous ne pouvez rentrer dans le flux et à peine commencé vous arrêter. Le cerveau des développeurs doit basculer dans le bon état d'esprit pour coder et cette bascule prend du temps.

Assurez vous que vos développeurs ont chaque jour une plage ininterrompue d'au moins quatre heures dédiée au développement. C'est là le secret pour que le travail avance plus vite. Cela semble assez logique : si les gens font habituellement une journée de huit heures, au moins la moitié de leur temps devrait être allouée à l'activité principale. Je m'étais rendu compte que j'étais plus productif entre 13h et 17h. Je savais que si j'avais ce créneau chaque jour je pouvais facilement accomplir mes tâches. Quand ce créneau commençait à être interrompu par des réunions, je savais que je ne produirais pas beaucoup.

Tâchez aussi d'avoir au moins une journée sans réunion par semaine. Pas même de stand-up quotidien (NdT : courte réunion quotidienne au cours de laquelle les participants à un projet disent ce qu'ils sont en train de faire ; cette réunion a lieu debout afin d'en limiter la durée, d'où le nom). Contentez-vous de laisser aux développeurs le soin de gérer leur temps par eux-même ce jour là et de faire ce qui doit l'être. Il est absolument incroyable tout ce que l'on peut faire en une journée lorsqu'il n'y a aucune interruption. A une certaine période de ma carrière, mon responsable m'a imposé de travailler de chez moi deux jours par semaine parce que j'étais constamment interrompu lorsque j'étais au bureau. Résultat : je terminais mon travail très vite.

Il s'agit là de quelque chose qui peut être mis en oeuvre immédiatement et qui est vraiment efficace. J'ai mentionné précédemment la frustration de suer pour terminer une tâche et de ne recevoir comme retour que des rapports de bug. En tant que développeurs nous avons rarement l'opportunité de nous enfoncer dans notre fauteuil, admirer le résultat de notre travail et recevoir une tape dans le dos de quelqu'un.

Quand un développeur termine une tâche, surtout une longue, un petit mot pour dire merci aura un très grand effet. Un simple "Hé, merci d'avoir terminé. On va jeter un oeil" fera disparaître la position défensive qui apparaît typiquement lorsque les rapports de bugs commencent à arriver. Se sentir apprécié est important pour les développeurs car la plupart des retours que nous recevons sont négatifs, sous la forme de bugs, de problèmes d'exploitation ou autre. Un peu de retour positif rend le reste moins pesant.

Si vous voulez faire encore mieux, décidez d'une récompense qui est attribuée chaque trimestre au développeur qui a eu le plus gros impact ou qui a le plus amélioré les choses ou quoique ce soit d'autre. La récompense ne doit pas nécessairement être quelque chose d'important ou désirable comme un iPad (même si nous accepterions avec plaisir cela ainsi que d'autres gadgets), cela peut-être un petit trophée et un email à toute l'équipe ou le département qui reconnait l'effort.

Et s'il vous plaît, lorsque vous remerciez les gens pour leur travail, n'oubliez pas les développeurs. J'ai assisté à de nombreuses réunions sur de nombreux projets lors desquelles les gens remercient ouvertement les équipes produits ou les designers pour leur travail sur le projet sans mentionner les ingénieurs dont le sang, la sueur et les larmes ont produit le travail concret. Le succès ou l'échec de chaque produit est le résultat du travail des trois groupes, aucun ne pourrait le faire seul. Assurez vous que votre entreprise exprime toujours sa reconnaissance envers toute l'équipe et pas seulement une partie.

Nous, les développeurs, sommes une espèce intéressante. Nous sommes dotés d'une personnalité particulière, et désirons vraiment faire les choses du mieux possible. Si vous arrêtez de nous traiter comme des exécutants et commencez à nous traiter comme faisant partie du processus créatif, vous obtiendrez probablement plus et bien plus vite. Les équipes dans lesquelles j'ai travaillé ont toutes connues des frictions à divers degrés par manque de compréhension de l'état d'esprit des développeurs et de ce qui les motive. J'espère sincèrement que cet article permettra une meilleure communication entre les ingénieurs et ceux qui travaillent avec. Ce n'est vraiment pas si difficile. Nous voulons tous faire partie de la solution plutôt que d'être une abeille ouvrière.

Références

]]> http://blog.mandraxe.info/ingenieurs-grincheux.html http://blog.mandraxe.info/ingenieurs-grincheux.html Tue, 04 Feb 2014 11:02:00 +0100 <![CDATA[Traduit ailleurs : Responsive Webdesign – présent et futur de l'adaptation mobile]]>

Design

La problématique du responsive est bien plus complexe que ce qu'on peut lire sur certains blogs qui essaient de nous faire croire qu'il suffit aujourd'hui, pour optimiser un site pour mobile, d'ajouter 2 Media Queries pour l'iPhone et l'iPad et redimensionner toutes les images. Le Responsive Web Design est une technique toute jeune, loin d'être parfaite et en constante évolution. Beaucoup de choses sont aujourd'hui possible, mais hélas il reste encore pas mal de chemin à parcourir dans le domaine.

Article par Stéphanie W. (Designer Web & Mobile spécialisée en UI and UX design, Partout dans le monde :))

Après plusieurs mois de recherche sur le sujet, j'ai enfin publié mon article sur Smashing Magazine qui s'intitule "The State Of Responsive Web Design". Ce qui suit en est la traduction.

Avertissement avant la lecture : Je n'ai pas la prétention de changer le monde, d'avoir la vérité absolue. Dans cet article – qui est long, je le sais – je souhaitais juste rendre attentif le lecteur au reste de ce gigantesque iceberg dont les Media Queries n'en sont que la surface. Le responsive webdesign reste une technique et une infime partie de ce qui est aujourd'hui appelé "Adaptive Webdesign". Le but de l'article n'est pas non plus de décourager les gens qui optimisent des sites pour mobile, mais de mettre le doigt sur ce qui aujourd'hui pose problème, est bancal, pour ensemble, trouver des solutions à ces différents problèmes. Pour un peu plus de détails sur le pourquoi de l'article, je vous renvoie à mon blog.

On entend parler de "Responsive Webdesign" depuis plusieurs années maintenant, et le sujet s'est vraiment démocratisé et popularisé en 2012. Brad Frost, Luke Wroblewski et d'autres grands noms commencent à avoir une certaine expérience du sujet, et aident au quotidien par leurs publications à son amélioration. Cependant, beaucoup reste encore à faire.

Iceberg

Dans cet article, nous allons nous intéresser à ce qui est aujourd'hui déjà possible en terme d'optimisation de sites pour mobiles, mais également à ce qui sera possible dans le futur. Nous parlerons de propriétés non encore standardisées comme CSS level 4, HTML5 et d'APIs, ainsi que de techniques qui restent à être améliorées. Cet article est loin d'être exhaustif et nous n'aurons pas le temps d'approfondir chaque technique mentionnée, mais vous aurez à la fin de la lecture à votre disposition suffisamment de liens pour pouvoir continuer l'exploration par vous-même.

L'état des images dans le responsive webdesign

Quelle meilleure manière d'aborder le sujet que de commencer par ce qui pose un gros souci : la gestion des images. Ce sujet n'est pas nouveau, il prend de plus en plus d'ampleur avec l'arrivée d'écrans dits "haute définition". Par ce terme j'entends des écrans avec un ratio de pixel supérieur à 2; ils sont appelés Retina chez Apple (iOS) ou encore XHDPI chez Google (Android). Quand on commence à s'intéresser aux images dans le domaine du responsive, on se retrouve confronté à deux difficultés : la taille (entendez par là leur poids en octets) et la performance.

Le site screensiz.es fait l'inventaire de la densité de pixels

Beaucoup de designers adorent le "pixel-perfect", mais les images de taille "normale" sont souvent "pixelisées" lorsqu'elles sont affichées sur des écrans haute définition. L'idée plutôt simpliste de proposer des images qui auraient deux fois (voire plus) la taille de départ pour éviter la dégradation visuelle sur ce genre d'appareil semble bien tentante. Mais qu'en est-il des problématiques de performance ? Des images dont les dimensions seraient doublées verraient leur poids multiplé mathématiquement par 4, et mettraient plus de temps à charger. Même si vos utilisateurs ont un écran haute définition, ils n'ont pas forcément, à l'instant où ils consultent votre page, la connexion qui va avec pour télécharger des images plus lourdes. En fonction du pays où se trouvent vos utilisateurs, la bande passante est d'ailleurs plus ou moins coûteuse.

Le second problème est lié aux petits appareils : pourquoi un téléphone mobile devrait avoir à télécharger une image de 750 pixels de large, alors qu'il n'a que 320 pixels physiques sur son écran pour l'afficher ? Et comment faire pour recadrer ces petites images, pour aller à l'essentiel et mettre en avant seulement la partie que l'on juge importante ?

Deux solutions du côté du code : l'élément <picture> et l'attribut srcset

On pourrait trouver dans le code que nous utilisons quotidiennement pour afficher les images un début de solution au sujet épineux des images responsive.

Le Responsive Images Community Group soutient une proposition d'un nouvel élément HTML <picture> plus flexible que ce que l'on utilise pour le moment. L'idée est d'utiliser la syntaxe des Media Queries que l'on commence à bien connaître pour faire télécharger des images différentes en fonction de l'appareil, de sorte que des petits écrans récupéreraient des images plus petites. La syntaxe de l'élément est proche de celle de <video>, chaque image étant référencée dans un sous élément <source>.

Voici à quoi ressemble le code de cette proposition :

<picture width="500" height="500"> <source media="(min-width: 45em)" src="large.jpg"> <source media="(min-width: 18em)" src="med.jpg"> <source src="small.jpg"> <img src="small.jpg" alt=""> <p>Texte accessible</p>
</picture>

On imagine aisément qu'il serait ainsi facile de proposer la même image en différentes tailles, mais on peut aussi imager proposer plusieurs images pour mettre l'accent sur différents éléments en fonction de la taille de l'appareil. Le use-case “Art Direction” du W3C illustre en quelques exemples de ce qu'il serait alors possible de réaliser.

Choix de DA pour la balise picture

Cette proposition est en cours de discussion auprès du W3C Responsive Images Community Group mais n'est à l'heure actuelle utilisable dans aucun navigateur. Un polyfill appelé Picturefill est disponible et permet d'émuler <picture> en JavaScript à l'aide de <div> et de data-attribute pour éviter les conflits de syntaxe le jour où <picture> sera standardisé.

En parallèle, Apple a également fait une proposition pour la syntaxe d'images responsives au W3C : The srcset Attribute. Elle est l'équivalent en HTML de la proposition CSS Level 4 image-set(). D'après les spécifications, le but de cet attribut est de forcer le navigateur (User Agent) à charger la ressource appropriée, plutôt que de lui proposer une liste de différentes ressources. Il ne s'agit donc ici non pas d'une nouvelle balise, mais de conserver <img> et de lui ajouter un nouvel attribut srcset. Voici la syntaxe décrite dans les spécifications : 

<img alt="The Breakfast Combo" src="banner.jpeg" srcset="banner-HD.jpeg 2x, banner-phone.jpeg 640w, banner-phone-HD.jpeg 640w 2x">

Vous l'aurez remarqué, elle est loin d'être intuitive. Les valeurs sont données dans des chaînes de caractère séparées par des virgules. A l'intérieur de ces chaînes on retrouve le chemin vers l'image, une valeur de densité de pixels de l'appareil, et la taille maximum de viewport pour laquelle cette image devrait être utilisée.

En français dans le texte, voici ce que donne le code ci-dessus :

  • Par défaut l'image utilisée est banner.jpeg
  • Les appareils qui ont un ratio de pixel supérieur à 2 utiliseront banner-HD.jpeg
  • Les appareils avec un viewport inférieur à 640px utiliseront banner-phone.jpeg
  • Les appareils avec un viewport inférieur à 640px ET un ratio de pixel supérieur à 2 utiliseront banner-phone-HD.jpeg

La première source donnée dans src est l'image utilisée par défaut si cet attribut n'est pas supporté. Le suffixe 2x pour banner-HD.jpeg signifie que cette image doit être utilisée pour les écrans avec un ratio de pixel supérieur à 2. La valeur 640w pour banner-phone.jpeg représente la taille maximum du viewport pour laquelle cette image sera utilisée. En raison de la complexité technique de sa mise en place, cette syntaxe n'a pas encore été implémentée dans nos navigateurs.

La syntaxe de image-set() en CSS fonctionne de la même manière et permet de charger des images de fond qui vont dépendre des mêmes critères : 

background-image: image-set( "foo.png" 1x, "foo-2x.png" 2x, "foo-print.png" 600dpi );

La proposition pour la version CSS est pour le moment dans l'état Editor’s Draft au W3C et fonctionne dans Safari 6+ and Chrome 21+. Un article sur picture, src-set et image-set est disponible en français sur le blog Creative Juiz.

Format d'image, compression et SVG : changer la façon dont on travail avec les images sur le web

Vous aurez constaté que ces deux propositions de syntaxe pour les images sont encore au stade expérimental. Ce qui pose la problématique du format d'image en tant que tel : un début de solution serait-il à trouver de côté là ?

La première étape serait de jeter un œil du côté des formats alternatifs d'image qui proposent un meilleur taux de compression. Google par exemple a développé de son côté un nouveau format, le WebP qui propose des compressions plus importantes pour des images 26% plus petites que le PNG et 25 à 34% plus petites que le JPEG. Ce format est supporté dans Chrome, Opera, Yandex, le navigateur natif Android et Safari. Il peut être activé pour Internet Explorer en utilisant le plugin Google Chrome Frame . Cependant, Firefox ne prévoit pas d'implémenter ce format. En sachant cela, il est donc peu probable de voir (actuellement) le WebP être massivement utilisé.

Une autre idée qui gagne de plus en plus en popularité est l'utilisation d'images en JPEG progressif. Comme son nom le suggère, l'image est affichée progressivement; le premier rendu est quelque peu flou, puis l'image s'affine et devient plus nette au fur et à mesure de son téléchargement. Par comparaison, les fichiers JPEG non progressifs s'affichent de haut en bas. Ann Robson met en avant dans son article Progressive JPEGs: A New Best Practice le fait que cette compression d'image donne à l'utilisateur une plus grande impression de vitesse que les JPEG classiques. Elle permet à l'utilisateur d'avoir un premier aperçu global de l'image sans avoir à attendre qu'elle soit totalement chargée. Cette technique ne résout en rien les problèmes techniques de performance et poids de chargement des images, mais améliore, d'après son auteur, l'expérience utilisateur.

Une dernière solution (du moins dans cet article) proposée pour tenter d'améliorer l'optimisation des images est de jouer sur leur taux de compression. Pendant longtemps beaucoup pensaient qu'à trop augmenter le taux de compression d'une image, on perdait (trop) en qualité. Daan Jobsis a fait des recherches plus approfondies sur le sujet et partage ses trouvailles dans son article Retina Revolution. Dans cette expérience, il a testé différentes tailles d'image et taux de compression pour arriver à une solution intéressante : en doublant la taille des images de départ tout en utilisant un taux de compression très élevé, l'image finale a un poids plus petit que l'originale et restera nette sur les écrans "normaux" et haute définition. Avec cette technique, il a été capable de réduire à 75% du poids des images qu'il a testé.

La démonstration de la compression de Daan Jobsis

Vu le casse-tête que représente l'optimisation des images pour un site responsive, devenir indépendant des pixels absolus est une idée qui séduit de plus en plus les designers et intégrateurs. Le format SVG propose par exemple une excellente alternative, et permet de créer des éléments d'interface vectoriels qui vont s'adapter à n'importe quelle résolution d'écran. Les éléments créés en SVG vont être facilement réduits et agrandis sans perte pour les écrans à haute résolution. À cette tendance s'ajoute celle des font-icons qui permet de remplacer les glyphes d'une police d'écriture par des icônes, tout en conservant la flexibilité de la police.

Ces solutions n'étant cependant pas envisageables pour des photos, un meilleur format d'image, ou une syntaxe plus flexibles sont donc attendus avec impatience pour le futur.

Défis de mise en page : réarranger le contenu sans toucher au HTML c'est possible ?

Pour commencer, arrêtons de nous voiler la face plus longtemps : les grilles fluides construites en flottants et éléments en inline-block que l'on utilise aujourd'hui ne sont que des patchs plus ou moins solides, dans l'attente d'une meilleure solution. Jouer avec la mise en page et totalement réarranger les blocs d'une page pour un écran plus petit sans recourir au JavaScript est à l'heure actuelle cauchemardesque. Toutes les solutions à notre disposition manquent cruellement de flexibilité. Et c'est encore plus vrai quand on commence à travailler avec des sites créés sous un CMS : il est impensable de devoir modifier le HTML pour chaque taille d'écran, alors comment peut-on améliorer tout ça ?

Une mise en page plus flexible grâce à 4 solutions utilisant des propriétés CSS3

La solution flexbox

La première solution qui nous vient à l'esprit lorsque l'on pense au concept de mise en page est le module CSS3 flexible box layout model aussi connu sous le nom de flexbox. Pour le moment il a le statut de "Candidate Recommendation" au W3C mais est déjà supporté par la plupart des navigateurs récents (y compris à partir de IE10). Le support des navigateurs mobiles est d'ailleurs particulièrement bon pour ce module. Ce modèle de boîte permet de réordonner les éléments à l'écran de manière simple et totalement indépendante de leur placement dans le code HTML. Il est également possible de changer l'orientation des boîtes (box orientation), la façon dont elles se suivent (box flow) et distribuer l'espace restant et les alignements en fonction du contexte sur la page.

L'image ci-dessous présente ce qui peut être accompli pour une mise en page sur mobile à partir de la version desktop (navigateur classique de "bureau"). Et la syntaxe pour y parvenir ressemblerait à quelque chose comme ceci :

.parent { display: flex; flex-flow: column; /* afficher les éléments en colonne */
} .children { order: 1; /* modifie l'ordre des éléments */
}

Illustration de flexbox

L'article en anglais CSS3 Flexible Box Layout Explained ainsi que l'article CSS3 Flexbox Layout module devraient vous aider à creuser un peu le sujet. Une autre solution proche de flexbox existe en JavaScript pour ré-ordonner les blocs dans une page : Relocate.

La solution Multi Column Layout

Une seconde technique CSS3 qui est utilisable aujourd'hui pour une mise en page responsive est le CSS3 Multi Column Layout. Ce module est passé en "Candidate Recommendation" et fonctionne pour la majorité des navigateurs récents, à l'exception de IE9 et versions inférieures. L'atout principal de ce module est la possibilité d'avoir du contenu qui va automatiquement glisser d'une colonne à une autre de manière très flexible en fonction de la taille du parent. Pour une optimisation mobile, il est donc très facile de changer la taille de la police en fonction de la taille du viewport.

Il est possible de donner une taille fixe à chaque colonne, et laisser au navigateur le soin de calculer le nombre de colonnes qui vont pouvoir rentrer dans l'espace disponible. Il est également possible de faire l'inverse : fixer un nombre de colonnes prédéfini, avec ou sans espace entre et laisser au navigateur le soin de calculer la largeur optimale pour chacune d'entre elles.

CSS multi colonnes

Voici à quoi ressemble la syntaxe :

.container { column-width: 10em ; /* le navigateur crée des colonnes de 10em, le nombre dépend de l'espace disponible */
}
.container { columns: 5; /* Le navigateur crée 5 colonnes dont la taille dépend de l'espace disponible */ column-gap: 2em;
}

Pour en savoir plus sur ce module je vous conseille l'excellent article de David Walsh : CSS Columns et retrouvez également un article en français sur Alsacreations : Les multicolonnes en CSS3.

La solution Grid Layout

Une troisième propriété qui mériterait plus d'attention dans le futur est le module CSS3 grid layout qui propose aux designers et développeurs un système de grilles flexibles avec lesquelles ils peuvent travailler pour construire différentes mises en page. Les éléments peuvent être affichés en colonnes et en lignes sans avoir besoin de définir une structure au préalable. La première chose à faire est de déclarer une grille sur le parent, puis de placer les éléments enfants sur cette grille "virtuelle". Il est ensuite très facile de changer la grille pour des écrans plus petits, ou de changer la position de ces éléments sur la grille. Combiné à des Media Queries, ceci permettrait une gigantesque flexibilité pour l'optimisation mobile mais également les changements d'orientation.

La syntaxe du Working Draft est la suivante (à la date du 2 avril 2013) :

.parent { display: grid; /* déclarer la grille */ grid-definition-columns: 1stgridsize 2ndgridsize …; grid-definition-rows: 1strowsize 2ndrowsize …;
}
.element { grid-column: 1; grid-row: 1
} .element2 { grid-column: 1; grid-row: 3;
}

Comme précisé dans les spécifications, plusieurs unités sont utilisables pour exprimer la taille des lignes et colonnes de cette grille virtuelle. Pour placer les éléments sur la grille on va spécifier le numéro de colonne (grid-column) dans lequel on veut le placer, puis le numéro de la ligne (grid-row). Si l'élément s'étend sur plusieurs lignes, il est possible d'utiliser la valeur span pour préciser le nombre de lignes à étendre.

Ce système à l'air prometteur, mais il n'est hélas supporté pour le moment que sur IE10. Si vous souhaitez néanmoins en savoir plus sur cette mise en page, vous pouvez lire l'article de Rachel Andrew intitulé Giving Content Priority With CSS3 Grid Layout. Notez également que les spécifications pour cette syntaxe ont changé le 2 avril 2013 et que Rachel a rédigé une mise à jour se son article intitulée CSS Grid Layout: What Has Changed? Retrouvez également en français un article de Raphaël Goetter : CSS3 Grid layout.

La solution Template layout

La dernière technique de mise en page qui pourrait devenir intéressante dans le futur si un navigateur se décidait à l'implémenter est le module CSS3 template layout. Il permet d'associer un élément avec une zone de mise en page que l'on aura au préalable pris la peine de nommer, puis d'organiser visuellement ces éléments sur une grille invisible, encore une fois. Cette grille peut être soit fixe, soit flexible en fonction de la taille du viewport.

Voici ce à quoi ressemble la syntaxe pour le moment :

.parent { display: "ab" "cd" /* créer la grille invisible */
}
.child1 { position: a;
}
.child2 { position: b;
}
.child3 { position: c;
}
.child4 { position: d;
}

Ce qui visuellement donnerait ceci : 

CSS grid layout en action

Hélas, comme vous l'aurez deviné à mon introduction, le support de cette propriété est pour le moment inexistante. Si des designers, développeurs et intégrateurs montrent de l'intérêt pour cette syntaxe, peut-être sera-elle un jour implémentée (avec des préfixes navigateurs ?), mais en attendant vous pouvez toujours, si elle vous intéresse, la tester avec un polyfill.

De nouvelles unités relatives au viewport et la fin de la mise en page basée sur des pixels ?

Les unités comme vw, vh, vm, vmin et vmax sont proposées dans la partie "Viewport-based percentage lengths" des spécifications et sont des unités de mesure relatives à la dimension du viewport.

Un vw est par exemple égal à 1% de la largeur du conteneur initial. Si la largeur du viewport est de 320px, 1vw est égal à 1x320/100 soit 3,2pixels.

L'unité vh fonctionne de la même manière mais est relative à la hauteur du viewport. 50vh sont donc équivalents à 50% de la hauteur du document. Vous vous demandez sans doute maintenant ce qu'est la différence avec le fait d'utiliser directement une hauteur en pourcentage. Les unités en pourcentage sont relatives à la taille de leur parents, alors que vh et vw seront toujours relatives à la taille du viewport, quelle que soit la taille de leurs éléments HTML parents.

Cela devient particulièrement intéressant si vous souhaitez par exemple créer une boîte et être sûr qu'elle ne pourra jamais passer sous la hauteur du viewport (la ligne de flottaison), pour faire en sorte que l'utilisateur n'ait jamais besoin de faire défiler le contenu pour la voir. Cela permettrait également en théorie de créer des mises en page avec des éléments qui feraient 100% de la taille du navigateur mobile (donc viewport) sans avoir besoin de passer par des hacks de 100% sur tous leurs parents.

L'unité vmin est quant à elle égale à la plus petite d'entre vm ou vh, alors que vmax est égale à la plus grande. Ces unités sont donc flexibles aux changement d'orientation de l'appareil.

Hélas pour le moment ces unité ne sont pas supportées pour les mobiles sur les navigateurs Android natifs. Il va donc peut-être falloir attendre un peu avant de pouvoir les utiliser correctement.

Retrouvez quelques tests de ces unités (sur des éléments textuels et un bloc flexible) en français sur Creative Juiz.

À propos d'une typographie qui s'adapte

Au final, la mise en page d'un site reste très dépendante du contenu que l'on va y mettre. Je ne pouvais donc pas conclure une section dédiée aux possibilités de mise en page sans vous parler de typographie. CSS3 propose une nouvelle unité particulièrement utile pour la gestion de la typographie : l'unité rem. Là où la taille d'une police exprimée en em est relative à la taille de la police de ses ancêtres, la taille d'une police exprimée en rem est, et sera toujours relative à la taille de la police de l'élément racine (à savoir <html>). Pour un site responsive, il est donc possible d'écrire le code suivant, puis d'adapter la taille de toutes les polices du site d'un coup en changeant la taille de police de l'élément html :

html { font-size: 14px;
}
p { font-size: 1rem /* 14px */
} @media screen and (max-width:380px) { html { font-size: 12px; /* rendre les polices plus petites pour mobile */ } p { font-size: 1rem /* cet élément est désormais équivalent à 12px */ } }

En dehors d'IE8 et Opera mini, le support pour rem est plutôt bon. Si en savoir plus sur les unités rem vous intéresse, l'article de Matthew Lettini In Defense of Rem Units est une excellente ressource. Retrouvez également une ressource sur le sujet en français chez Pompage.net : dimensionner ses fontes avec rem.

Trouver un meilleur moyen de gérer d'autres types de contenus complexes

Nous commençons tout doucement à trouver de meilleures solutions pour gérer les images et les mises en page responsive, mais il faut encore trouver d'autres solutions pour les contenus plus complexes.

Gérer les formulaires sur un site responsive

De manière générale la gestion de formulaire, et tout particulièrement de longs formulaires, est un défi en "mobilité" (entendez par là "dans l'univers du mobile"). Plus long sera le formulaire, plus il sera compliqué à adapter pour des petits appareils. L'adaptation physique visuelle n'est pas bien compliquée ; la plupart des designers vont simplement placer les éléments les uns sous les autres en une seule colonne et élargir les champs pour qu'ils prennent toute la taille de l'écran. Mais rendre ces formulaires visuellement attractifs n'est pas suffisant : il nous faut également les rendre facile d'utilisation sur mobile.

Luke Wroblewski conseille d'éviter les champs texte quand c'est possible, et de proposer des cases à cocher, boutons radios et menus déroulants de sélection de sorte que l'utilisateur ait à entrer le moins d'informations possible au clavier. Un autre conseil important est de proposer à l'utilisateur les retours quant à la validité des champs avant qu'il appuie sur le bouton "envoyer". Vérifier les erreurs au fur et à mesure de la saisie est important sur mobile, car la plupart des formulaires dépassent la hauteur de l'écran. Si l'utilisateur a mal rempli un champ et doit attendre l'envoi pour le savoir, il y a de fortes chances qu'il ait du mal à retrouver où se trouve le(s) champ(s) mal rempli(s).

Les nouveaux types de champs et attributs HTML5 vont être d'une grande aide dans le futur pour construire des formulaires faciles d'utilisation, sans besoins d'avoir recours à (trop) de JavaScript. Il est par exemple possible d'utiliser l'attribut HTML required pour proposer un retour à l'utilisateur sur un champs qu'il doit obligatoirement remplir. Hélas le support mobile de cet attribut est pour le moment très limité.

L'attribut autocomplete peut également être utilisé pour améliorer l'expérience utilisateur lors de la saisie des champs. Dans la mesure où un appareil mobile (de type smartphone) est un objet personnel, on peut imaginer que des données comme le nom, ou encore l'adresse postale ne changeront pas souvent pour son propriétaire. En utilisant l'attribut autocomplete, il serait donc possible d'améliorer la saisie de ces champs pour que l'utilisateur n'ait pas besoin de taper encore une fois en entier ce genre de données.

Il existe également une liste entière de nouveaux types d'inputs HTML5 qui pourront être utilisés dans un futur plus ou moins proche pour aider à l'optimisation des formulaires.

Le cas des dates est un bon exemple de ce qui peut être amélioré à l'aide de HTML5. Nous avons longtemps mis en place des datepickers (calendriers) en JavaScript, facilement utilisables sur navigateur de bureau, mais très difficiles à manier pour un appareil tactile. Appuyer sur la bonne date avec un doigt peut s'avérer assez difficile voire impossible si les zones sont très petites.

Date-picker ou selecteur de date

Comment suis-je supposée arriver à ne toucher qu'une date quand la zone est si petite ?

Les nouveaux types de champs HTML5 input type="date", input type="datetime", etc qui permettent de créer une chaîne de caractère au format de date/heure offrent des possibilités prometteuses ici. Le gros avantage de ces nouveaux types de champs est que leur rendu visuel est contrôlé par le navigateur et le système. De cette manière, leur UI (apparence graphique pour l'utilisateur) est automatiquement optimisée au mieux pour le périphérique utilisé.

Rendu de l'input date

Rendu de input type="date" dans différents navigateurs

Notons également que l'UI s'adapte également à la langue du navigateur. Utiliser des composants natifs permet donc également une adaptation linguistique automatique de certains contenus.

Pour le moment le support de input type="date" est presque absent pour les navigateurs de bureau, à part Opera et Chrome. Les navigateurs natifs Android ne le supportent pas non plus, par contre Chrome pour Android et Safari sur iOS le font. Il va donc falloir encore attendre un peu avant de pouvoir utiliser totalement le potentiel de ces nouveaux champs pour une solution mobile. Si vous êtes impatients, vous pouvez cependant utiliser un polyfill comme Mobiscroll qui va imiter le comportement natif de ces champs en JavaScript.

Au-delà des solutions natives de champs HTML5 d'autres expériences ont été menées pour proposer des patterns de designs plus adaptées comme "Mobile Design Details: Hide/Show Passwords" ou encore "Input Masks Design". Notons ne qu'il s'agit encore une fois que de solutions expérimentales et que là encore, la solution parfaite pour gérer les formulaires en responsive webdesign n'existe pas pour le moment. Il reste encore beaucoup de chemin à parcourir de ce côté.

Consultez également l'article les éléments de formulaire HTML5 sur Alsacréations pour aller plus loin.

La gestion des tableaux sur un site responsive.

Les tableaux sont un autre type de contenu qui reste difficilement gérable. La plupart des tableaux ont une orientation verticale pour présenter le plus de données possibles, il est donc difficile de faire rentrer toutes ces données sur un petit écran. Les tableaux HTML sont plutôt flexibles, il est possible d'utiliser des pourcentages pour la largeur des colonnes. Cependant le contenu en devient très vite illisible.

Personne n'a pour le moment trouvé la solution idéale pour gérer les tableaux sur un site responsive, mais quelques suggestions intéressantes ont été faites.

Une première approche consisterait à cacher ce qui pourrait être considéré comme des colonnes "moins importantes", et proposer un système de checkboxes à l'utilisateur pour qu'il puisse choisir lesquelles il souhaite afficher. Toutes les colonnes seraient affichées sur un navigateur de bureau, alors que sur mobile, leur nombre déprendrait de la taille disponible à l'écran. Le Filament Group explique et propose une démonstration de cette approche dans un de leurs articles. C'est également cette solution qui est proposé dans le module table column toggle de jQuery Mobile.

Quelques exemples de tableaux responsive.

Une seconde approche est basée sur l'idée de tableaux qui défilent. Elle consiste à fixer une seule colonne à gauche, et laisser une barre de défilement sur une petite partie du tableau à droite pour que l'utilisateur puisse afficher le reste des données. David Bushell implémente cette idée  dans un article en utilisant du CSS pour afficher tout le contenu du <thead> sur la partie gauche du tableau, laisse l'utilisateur faire défiler le reste sur la partie de droite. Zurb utilise la même idée dans leur plugin  mais au lieu de coller le header à gauche, c'est la première colonne qui est dupliquée en JavaScript et le reste du tableau passe en dessous de sorte que l'utilisateur voit à gauche une colonne fixe, et à droite le reste des colonnes qu'il peut encore une fois faire défiler.

Deux exemples de tableaux que l'on peut faire défiler

Deux exemples de tableaux que l'on peut faire défiler

Le gros problème avec la propriété CSS overflow:auto est que la barre de défilement créée n'est pas visible sur certains appareils mobiles et tablettes. L'utilisateur peut toujours faire défiler la partie de droite, mais il n'a aucune indication visuelle qu'il peut s'y cacher plus de contenu que ce qu'il voit. Il faut donc, si on utilise ces techniques, trouver un moyen d'indiquer visuellement à l'utilisateur qu'il peut faire défiler le contenu à droite.

Une troisième approche est de ré-agencer les tableaux et de découper les colonnes en ce qui ressemble à des listes avec des titres. Cette technique est utilisée pour le “reflow mode” de jQuery mobile et est expliquée par Chris Coyier dans son article “Responsive Data Tables.”

Des tableaux ré-agencés

Il existe encore plusieurs autres techniques et l'utilisation de l'une ou de l'autre dépendra de votre projet. Aucun projet n'est identique, donc je peux seulement vous montrer ici ce que d'autres personnes ont créé pour contourner le problème des tableaux. Si vous avez vous aussi une solution à proposer, partagez-la avec tout le monde, dans les commentaires, sur Twitter, Github ou n'importe où. Nous sommes dans cette galère ensemble, les tableaux en mobilité sont une plaie, à nous de les améliorer !

Encapsuler des contenus tiers : le problème des iframes

Le contenu de beaucoup de sites dépend aujourd'hui d'applications et services tiers : Youtube ou Vimeo pour les vidéos, des présentations Slideshare, des widgets Facebook, des flux Twitter, des cartes Google maps, etc. Beaucoup de ces services tiers utilisent aujourd'hui des iframes pour proposer leur contenu sur d'autres sites. Mais ne nous voilons pas la face : les iframes sont encore une fois une plaie à utiliser dans un contexte de mobilité. Les largeurs et hauteurs sont fixées en direct dans le code HTML. Forcer une largeur de 100% sur <iframe> pourrait marcher, mais cela voudrait dire perdre le ratio du contenu embarqué. Les vidéos sont souvent en 16:9 par exemple, pour garder ce ratio il va falloir trouver des solutions alternatives.

Du bricolage HTML et CSS

Thierry Koblentz a écrit un très bon article intitulé “Creating Intrinsic Ratios for Video” dans lequel il propose une méthode pour avoir des vidéos dans des iframes tout en préservant le ratio 16:9 de départ. Cette solution peut être étendue à toutes sortes d'iframe : vidéos, présentations SlideShare et même cartes GoogleMaps.

Koblentz entoure son iframe d'un conteneur auquel il va donner une classe pour lui appliquer ensuite du CSS. Ce conteneur permet d'avoir un iframe fluid, même si les valeurs de largeur et hauteur sont données en pixels et en dur dans le HTML. Voici à quoi ressemble ce code adapté par Anders M. Andrers :

.embed-container { position: relative; padding-bottom: 56.25%; /* 16:9 ratio */ padding-top: 30px; /* IE 6 workaround*/ height: 0; overflow: hidden;
} .embed-container iframe,
.embed-container object,
.embed-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%;
}

Ce code va fonctionner pour tous les iframes, à partir du moment où vous les aurez entourées de <div class="embed-container">iframe</div>.

Même si cette solution peut-être facilement mise en place sur un site sur lequel on a un contrôle total, il est difficilement envisageable de demande à un client sans compétences techniques d'ajouter ce HTML à chaque fois qu'il va récupérer une vidéo sur Youtube. Il serait bien sûr possible d'utiliser du JavaScript pour détecter tous les iframes de la page et les encapsuler automatiquement dans notre code. Mais il s'agit hélas encore une fois de bricolage et non pas d'une solution pérenne.

La gestion des vidéos responsive dans le futur

HTML5 propose de nouvelles possibilités pour les vidéos avec l'élément video. La bonne nouvelle : son support est étonnamment bon pour les mobiles. En dehors d'Opera Mini, la majorité des navigateurs supportent la balise <video>. L'autre bonne nouvelle : cette balise est très flexible en CSS. Pour présenter une vidéo responsive, il suffirait d'écrire :

video { max-width: 100%; height: auto;
}

Et là vous vous demandez : où est le problème alors ?

Le problème vient tout simplement des plateformes qui vont proposer les contenus. Même si Youtube ou encore Vimeo supportent la balise video, ils produisent toujours cet horrible <iframe> lorsque l'on veut afficher la vidéo sur son site. Nous sommes donc condamnés à trouver des bidouilles et des bricolages comme ceux évoqués plus hauts tant que Youtube, Vimeo ou Dailymotion ne se décident pas à proposer un moyen plus propre d'afficher leurs vidéos sans utiliser d'iframe. En attendant ce jour, Chris Coyier propose un plugin jQuery appelé FitVids.js qui utilise la technique proposée plus haut et se charge de faire l'encapsulage de l'iframe dans un conteneur pour améliorer sa fluidité tout en préservant le ratio de la vidéo.

Afficher les cartes Google Maps (ou équivalent)

Si vous décidez à afficher pour votre site une carte Google Maps, la technique décrite plus haut avec le conteneur va fonctionner. Mais encore une fois, c'est une bidouille pas propre du tout. En plus dans le cas des cartes, elles vont se redimensionner en gardant leurs proportions ce qui veut dire que sur un petit écran, vous risquez de vous retrouver avec une carte toute petite qui aura perdu le focus sur l'endroit que vous vouliez montrer à l'utilisateur. La documentation officielle de Google Maps pour mobile stipule qu'il vaut mieux utiliser l'API de cartes statiques pour un affichage sur mobile. Et en effet, utiliser une carte statique (via une balise <img>) fera disparaitre notre souci d'iframe. Brad Frost a écrit un excellent article sur le sujet intitulé adaptive maps dans lequel il propose une démonstration qui illustre cette technique. Un JavaScript détecte la taille de l'écran et en fonction va remplacer l'iframe par une carte statique sur les petits écrans. Et encore une fois en l'absence de meilleure solution native (proposée par Google par exemple), nous avons recours à une bidouille pour pouvoir nous débarrasser de notre problème d'iframe.

Il nous FAUT de meilleures APIS !

J'ai jusque là parlé de bidouille, de bricolage : existe-t-il une meilleurs solution ? Le plus gros souci des iframes est notre manque de contrôle en tant que designers et intégrateurs sur le code et design qu'elles vont générer. Nous sommes totalement dépendants de ces services tiers et par extension, du HTML et CSS qu'ils veulent bien nous fournir. Dans la mesure où le nombre de services et sites qui proposent ce genre de contenus tierces est en constante augmentation, il va rapidement nous falloir de meilleures solutions que les iframes pour afficher leur contenus sur nos sites.

Soyons réalistes deux secondes : utiliser le widget Facebook pour afficher les likes sur son site est une plaie. Le peu de contrôle sur le CSS généré par Facebook rend notre travail hasardeux et peut aller jusqu'à ruiner un joli design. Le web est un endroit libre et ouvert, il est donc peut-être enfin temps de commencer à penser en terme d'APIs! Dans le futur, nous aurons à la fois besoin de plus d'APIs (Application Programming Interface) pour récupérer ces contenus, mais enfin et surtout, besoin d'APIs plus flexibles et surtout d'APIs plus simples d'utilisation pour récupérer ces contenus sans les iframes. Mais jusqu'à ce que ces grands services se décident à nous créer ces APIs, nous sommes coincés avec des iframes hasardeux et condamnés au bricolage et à la bidouille.

La navigation responsive: tour d'horizon des techniques actuelles

Un autre gros défi quand on parle de responsive et d'optimisation est la navigation du site. Point souvent critique pour l'utilisateur, plus elle est complexe et dense, plus il va falloir ruser d'inventivité pour proposer une expérience agréable et simple d'utilisation.

Lorsque le Responsive Web Design n'en était qu'à ses débuts, une première solution était de transformer la navigation en listes déroulantes. Cette solution est hélas loin d'être idéale. Elle devient très compliquée dès que l'on a plusieurs niveaux de navigation, et peut poser des soucis d'accessibilité. Je vous conseille de lire l'excellent article Stop Misusing Select Menus pour en apprendre un peu plus sur cette technique et les problèmes liés.

Quelques personnes comme Brad Frost ou encore Luke Wroblewski ont alors essayé de proposer différentes solutions à ce casse tête. Brad Frost compile quelques techniques de navigation responsive sur son site This Is Responsive.

La navigation qu'il appelle "Toggle" consiste à cacher la navigation pour les petits appareils sous un lien "menu". Quand l'utilisateur clique sur ce lien, le reste de la navigation apparait sous forme de blocs juste en-dessous, poussant le contenu plus bas dans la page.

Une variante de cette technique a été inspirée par les navigations d'applications natives comme celle de Facebook et est appelée off-canvas. Encore une fois on cache la navigation sous une icône "menu". Quand l'utilisateur clique sur cette icône, la navigation sort d'un panneau à gauche ou à droite du site, poussant le contenu de l'autre côté.

Exemples de navigation toggle

Le "problème" de ces techniques est que la navigation reste en haut de l'écran. Dans son article “Responsive Navigation: Optimizing for Touch Across Devices,” Luke Wroblewski illustre de manière visuelle les zones faciles d'accès sur différents appareils. La partie en haut à gauche est la plus compliquée à atteindre sur mobile.

Les zones de l'ecran plus ou moins facilement accessibles

En se basant sur ces recherches, Jason Weaver créa quelques démonstrations de navigations avec les boutons en bas de l'écran. Une des solutions proposées est d'avoir la navigation en pied de page, et d'y renvoyer l'utilisateur lorsqu'il clique sur le bouton "menu" à l'aide d'un système d'ancres HTML.

Bien d'autres solutions ont été proposées pour tenter de régler le problème de la navigation responsive. Comme vous pouvez le voir, encore une fois, il n'existe pas de solution idéale et cela va là encore dépendre non seulement de votre projet, mais également du niveau de profondeur de votre navigation. Heureusement qu'il existe des gens comme ceux cités plus haut qui expérimentent et partagent les expériences avec la communauté.

Il nous faut également encore trouver quelles icônes choisir pour montrer à l'utilisateur de manière pertinente qu'il y a un menu, et qu'il se cache des éléments supplémentaires en dessous. Certains sites utilisent le symbole (+), d'autres une grille, d'autres encore utilisent un symbole de liste ordonnée, ou encore le symbole des 3 lignes (ou burger icon).

icône de menu

Pour voir ces icônes en utilisation je vous conseille l'excellent article “We Need a Standard ‘Show Navigation’ Icon for Responsive Web Design.”

Reste à trouver laquelle de ces icônes est la plus facilement identifiable par un utilisateur comme étant un menu. Si tout le monde s'accordait sur l'utilisation d'une d'entre elles, les utilisateurs (de tous pays) seraient-ils capables de la comprendre ? Et laquelle choisir ? Je suis très curieuse de savoir quelle icônes vous utilisez sur vos sites, donc n'hésitez pas à partager votre expérience dans les commentaires ci-dessous.

Les spécificités du mobile : "Mon utilisateur est-il sur un appareil mobile? Et que peut-il y faire?"

Le monde des mobiles et tablettes est tout nouveau pour nous, loin des navigateurs de bureaux, et avec ses propres règles, comportements et capacités. Il va donc nous falloir penser à adapter nos design à toutes ces nouvelles possibilités.

Détecter la possibilité d'évènement "touch" en JavaScript natif

Je pense que si vous demandez dans la rue à quelqu'un de vous donner la différence entre un navigateur de bureau et mobile, en dehors de la taille, il y a fort à parier que cette personne va vous répondre l'utilisation avec les doigts. Il n'y a pas de souris sur les mobiles (ha bon ? ;)) et en dehors de quelques rares appareils hybrides et ajouts en bluetooth sur des tablettes, il n'est pas possible d'avoir des évènements de souris sur un mobile ou une tablette. Cela implique qu'en fonction du navigateur, la pseudo-classe :hover fonctionnera différemment. Certains navigateurs sont sympatiques et "émulent" cette fonctionnalité, traduisant un effet au survol par un effet au touch. Hélas tous ne sont pas aussi flexibles. Créer un design dont une partie des éléments ne sont révélés qu'au survol de la souris peut s'avérer compliqué sur mobile.

Récupérer les évènements au touch est une solution envisageable. Le W3C a un groupe de travail sur le projet de spécifications touch event. Dans le futur, nous serons donc capables de détecter directement en JavaScript et sans librairie tierce comme Hammer.js ou jGestures des évènements comme touchstart, touchmove ou encore touchend.

JavaScript est une chose, mais qu'en est-il du CSS ?

CSS Level 4 "pointer media query"

Le CSS Level 4 propose une nouvelle Media Query appelée “pointer”. Elle peut être utilisée pour détecter la présence d'un dispositif de pointage comme une souris, et prend 3 valeurs possibles :

  • none : l'appareil n'a pas de dispositif de pointage
  • coarse : l'appareil a un dispositif de pointage avec une précision limitée (un mobile ou une tablette où le dispositif de pointage est un doigt)
  • fine : l'appareil dispose d'un dispositif de pointage précis comme une souris, ou encore un track pad ou le stylet d'une tablette graphique

En utilisant cette requête, on peut imaginer ce genre de code pour élargir la taille des boutons pour des appareils "touch" :

@media (pointer:coarse) { input[type="submit"], a.button { min-width: 30px; min-height: 40px; background: transparent; } }

Cette Media Query n'est pour le moment supportée nulle part et est à l'état de proposition. Le potentiel n'en reste pas moins très intéressant puisqu'elle permettrait de détecter des appareils supportant le touch sans devoir passer par une librairie comme Modernizr.

La Media Query CSS Level 4 "hover"

Les spécifications CSS Level 4 proposent également une nouvelle Media Query appelée hover,qui est capable de détecter si le dispositif de pointage de l'appareil peut supporter les effets au survol. Elle renvoie un booléen 1 si l'appareil supporte le survol, 0 si ce n'est pas le cas. Notez ici que cela n'a RIEN à voir avec la pseudo-classe :hover.

En utilisant cette syntaxe, nous pourrions par exemple améliorer les interfaces et ne masquer des fonctionnalités que pour les appareils qui supportent le survol d'éléments. Le code pourrait ressembler à ça :

@media (hover) { .hovercontent { display: none; } /* cacher le contenu uniquement pour les appareils qui supporent le survol */ .hovercontent:hover { display: block; } }

On pourrait imaginer l'utiliser pour créer des menus déroulants au survol uniquement pour les appareils le supportant, et proposer une alternative plus facilement pour les autres sans avoir besoin de détection des capacités de l'appareil.

La Media Query CSS Level 4 "luminosity"

Les appareils mobiles sont aujourd'hui équipés de détecteurs leur permettant de mesurer la luminosité ambiante. CSS Level 4 propose une media-query " luminosity" qui aura accès aux données de ces capteurs. Voici comment la décrivent les spécifications du W3C :

 La Media Query luminosité est utilisée pour récupérer des données sur la luminosité ambiante dans laquelle l'appareil se trouve et permet à l'auteur d'ajuster le style du document en fonction.

Dans le futur nous serons donc capables de créer des sites qui vont réagir à la luminosité ambiante. Nous allons pouvoir grandement améliorer l'expérience utilisateur en leur proposant par exemple plus de contrastes dans un environnement très lumineux avec la valeur "washed". La valeur "dim" est utilisée pour les environnements sombres, et la valeur "normal" si le niveau de luminosité ne requiert pas d'ajustement.

Voici à quoi pourrait ressembler le code :

@media (luminosity: washed) { p { background: white; color: black; font-size: 2em; }
}

Si vous êtes curieux et souhaitez en savoir plus sur les nouveautés CSS level 4 pas forcément liées au responsive, vous pouvez lire l'article Sneak Peek Into the Future: Selectors, Level 4.

Plus de capacité mobiles détectables en utilisant les APIs et JavaScript

Beaucoup d'autres fonctionnalités peuvent être détectées pour améliorer l'expérience utilisateur et proposer un site responsive digne de ce nom. Par exemple il serait possible d'accéder nativement au gyroscope, à la boussole ou à l'accéléromètre pour détecter l'orientation de l'appareil en utilisant DeviceOrientationEvent. Le support de cette API s'améliore pour Android et iOS mais elle reste pour le moment à l'état de brouillon. Les possibilités pour les jeux HTML5 qui exploiteraient l'orientation directement dans le navigateur n'en restent pas moins prometteuses.

Une autre API qui commence à être beaucoup utilisée et particulièrement utile est la Géolocalisation. Cette API est d'ailleurs très bien supportée. Elle permet de positionner l'utilisateur en utilisant son GPS, l'adresse IP ou encore les réseaux Wi-Fi ou la triangulation d'antennes relais. On peut imaginer utiliser la géolocalisation sur un site responsive pour proposer des informations contextuelles à l'utilisateur. Une grosse chaîne de restaurants pourrait pas exemple améliorer l'expérience en montrant à l'utilisateur géolocalisé les restaurants de la chaîne qui se trouvent autour de lui.

Le W3C propose également un brouillon pour l'API Vibration. Le navigateur peut alors proposer des retours tactiles sous forme de vibrations à l'utilisateur. Néanmoins on sort là quelque peu du domaine du responsive pour entrer un peu plus dans le domaine du jeu et de l'applicatif web.

Une autre API qui a fait couler beaucoup d'encre est Network Information. La possibilité de pouvoir optimiser des images et un site en fonction de la bande passante de l'utilisateur a de quoi séduire plus d'un développeur. Nous serions en théorie alors capables de proposer des images en haute résolution pour les appareils avec une grosse bande passante, et vice et versa. Avec l'attribut bandwith de l'API network, il serait possible d'estimer la bande passante d'un utilisateur en Mb/s. Le second attribut metered est un Boolean qui nous indique si l'utilisateur a une connexion mesurée, comme c'est le cas pour des mobicartes pré-payées par exemple. Ces deux attributs sont accessibles en JavaScript.

Hélas la mesure de la connexion d'un utilisateur est une chose techniquement complexe. En outre, la connexion peu changer à tout moment. Un utilisateur passant sous un tunnel peut perdre sa connexion, et la vitesse de téléchargement va subitement chuter. Il est donc totalement hypothétique d'imaginer à l'heure actuelle une Media Query "magique" qui permettrait de mesurer la bande passante. Yoav Weiss a écrit un excellent article sur le problème qu'une telle Media Query pourrait engendrer et sur la mesure de la bande passante en général intitulé Bandwidth Media Queries? We Don’t Need ’Em!.

Il existe encore beaucoup d'autres APIs liées aux fonctionnalités mobiles que je ne vais pas détailler ici. Si vous souhaitez en savoir plus, Mozilla a une liste très détaillée. La plupart d'entre elles sont loin d'être standardisées, et beaucoup sont plus orientées vers de l'applicatif web que vers le site responsive. Il n'en reste pas moins passionnant de voir à quel point la mobilité va devenir complexe dans le futur et toutes les possibilités qui vont s'ouvrir à nous.

Repenser la façon dont nous, et nos clients/utilisateurs gérons le contenu.

Il reste encore bons nombres de défis techniques à relever pour gérer du contenu de manière efficace sur mobile. La philosophie "mobile-first" commence à faire de plus en plus d'émules dans la communauté de designers et d'intégrateurs. Il serait par exemple techniquement possible d'envoyer à un mobile le minimum de HTML et données nécessaires, puis d'utiliser du JavaScript et des chargements en AJAX pour charger plus de contenu et d'images de manière conditionnelle pour les navigateurs de bureau, voire les tablettes. Mais pour faire cela, il nous faut d'abord repenser la manière dont nous allons gérer notre contenu. Il nous faut être capable de prioriser et hiérarchiser les contenus pour les générer de la manière la plus flexible et adaptive possible. Un bon exemple ici serait la carte responsive décrite plus haut : nous chargeons pour le mobile une simple image, et améliorons progressivement l'expérience avec une "vraie" carte pour les utilisateurs de navigateur sur bureau. Plus nous allons vouloir rendre un site responsive, et plus la gestion du contenu va se complexifier.

Du code plus flexible peut nous aider à formater un contenu qui s'adapte. Certaines personnes ont suggéré de créer des phrases responsive en morcelant les éléments de balises HTML et de classes pour pouvoir n'en afficher que certaines parties en fonction de la taille de l'écran. L'idée est de masquer certaines parties pour les petits appareils en utilisant des Media Queries. Vous pouvez voir cette technique en action sur le blog de 37signal's Signal vs. Noise ainsi que dans l'article de Frankie Roberto intitulé Responsive Text. Même si cette technique peut être utilisée pour améliorer l'affichage de petites parties du site comme un slogan dans un pied de page, il est totalement impensable de l'appliquer à grande échelle à l'ensemble d'un site web.

On commence ici à mettre le doigt sur un problème qui va prendre de plus en plus d'importance dans le futur : la nécessité de parser son contenu textuel de métadonnées pour lui donner une plus grande structure sémantique. Rappelons-nous, le contenu de notre site ne vient plus uniquement de nos rédacteurs de contenus en interne. Si nous souhaitons à terme, être capable de réutiliser le contenu d'autres site sur le notre, il va falloir préparer la structure de ce contenu pour qu'il soit facilement réutilisable. Les nouveaux éléments HTML5 comme article, section sont un bon point de départ pour faire gagner de la valeur sémantique à nos contenus. Dans le futur, il ne faudra plus penser et structurer le contenu comme une seule entité (une page web) mais le penser comme l'assemblage de multiples blocs réutilisables que l'on va pouvoir afficher dans différents formats sur différents appareils.

Le plus grand défi sera de faire en sorte que la structuration en métadonnées soit facile d'accès et compréhensible par toutes les personnes qui font partie de la chaîne de création d'un site web. Nous allons devoir les éduquer, et leur expliquer comment ces données peuvent être utilisées pour prioriser le contenu et assembler de manière pragmatique différents éléments tout en restant indépendant de la plateforme utilisée. Le grand challenge sera de les aider à penser en terme de blocs réutilisables plutôt qu'en terme de "grosse zone de texte que l'on peut copier/coller depuis Word vers l'éditeur WYSIWYG du CMS". Notre travail sera de les aider à comprendre que le contenu et sa mise en forme sont deux choses séparées et indépendantes, tout comme nous en tant que designers et intégrateurs avons compris que le contenu (HTML) et sa présentation (CSS) sont plus simples à gérer une fois séparés.

Écrire un contenu orienté vers une seule et unique plateforme n'est plus une option. Qui sait sur quels appareils votre contenu sera affiché demain ? Dans 6 mois ? Dans un an ? Il nous faut préparer ce contenu pour l'inattendu. Mais pour arriver à cela, il va nous falloir également créer de meilleurs outils de publication. Karen McGrane a donné une conférence intitulée Adapting Ourselves to Adaptive Content. Elle y parle d'exemples concrets tirés de l'industrie de la publication. Elle détaille le processus pour créer des contenus réutilisables et introduit l'idée de COPE (create once and publish everywhere - en français "créer une fois, publier partout"). Il va nous falloir construire de meilleurs CMSs qui seront capables de générer les métadonnées nécessaires à cette priorisation des contenus. Nous allons également devoir expliquer à nos collègues et rédacteurs de contenu comment ces CMSs fonctionnent et comment penser en terme de contenus réutilisables et non pas de pages WYSIWYG.

Karen McGrane écrit :

"Vous serez peut-être amenés à écrire trois versions différentes de votre titre; deux versions du sommaire, et ajouter plusieurs images dans différentes tailles, différentes coupes, et vous ne serez même pas la personne qui décidera quelle image ou quel titre sera affiché sur telle ou telle plateforme. Cette décision sera faite par une métadonnée. Elle sera faite par les règles de l'industrie […] les métadonnées sont la nouvelle direction artistique."

Masquer des contenus pour des appareils n'est plus une stratégie de gestion de contenu pérenne. Il nous faut des CMS qui puissent nous fournir la structure pour créer du contenu réutilisable. Il nous faut également des meilleurs workflows de publication dans ces CMSs. Les interfaces hasardeuses et complexes font peur aux utilisateurs, et la plupart des personnes qui vont générer les contenus ne sont pas particulièrement à l'aise avec des outils trop compliqués. Il va nous falloir leur fournir des outils qui sont faciles d'accès et de compréhension pour les aider à publier du contenu propre, sémantique et indépendant de la présentation finale.

Content is like water

Conclusion

Cet article peut vous paraître long, mais il n'est que le sommet de l'iceberg. Aujourd'hui notre profession commence à comprendre que le responsive webdesign c'est bien plus que balancer quelques Media Queries dans une feuille de style, choisir des points de rupture et doubler les dimensions des images pour ces nouveaux jouets haute résolution qui nous servent de mobile. Vous l'avez lu, vu, le chemin est long, et nous sommes loin d'être arrivés à destination. Il y a encore tellement de choses à faire et de problèmes à résoudre que la solution responsive magique et miraculeuse n'existe pas encore aujourd'hui.

Nous avons découvert des solutions techniques, d'autres viendront dans le futur en utilisant des nouvelles technologies présentées dans cet article avec l'aide d'organisations comme le W3C, le WHATWG ou encore le Filament Group.

Mais gardons une chose importante à l'esprit : c'est également à nous, designers, nous intégrateurs, nous développeurs d'aider à trouver de meilleures solutions. Des gens géniaux comme Luke Wroblewski, Brad Frost, toutes les femmes et les hommes cités dans cet article et ceux que j'ai oublié œuvrent au quotidien, testent et expérimentent différentes techniques et solutions. Succès ou échecs, la chose la plus importante reste le partage ce que nous, designers, développeurs, rédacteurs de contenus et membres de la communauté webdesign créons au quotidien pour aider à surmonter ces défis présentés par le concept de responsive webdesign.

Nous sommes tous dans le même bateau, autant faire ensemble du web un endroit meilleur, non ?

Ressources

]]> http://www.alsacreations.com/article/lire/1559-responsive-web-design-present-futur-adaptation-mobile.html http://www.alsacreations.com/article/lire/1559-responsive-web-design-present-futur-adaptation-mobile.html Tue, 28 Jan 2014 11:01:00 +0100 <![CDATA[Traduit ailleurs : Apprendre les mises en page CSS]]>

Ce site vise à vous apprendre les bases de CSS utilisées pour structurer n'importe quel site web.

Je suppose que vous savez déjà ce que sont les sélecteurs, les propriétés et les valeurs. Et vous connaissez probablement une ou deux choses sur les mise en page, même si ça peut vous donner envie de vous arracher les cheveux. Si vous voulez apprendre le HTML et le CSS depuis le début, vous devriez allez faire un tour sur ce tutoriel. Sinon, voyons si nous pouvons vous éviter de vous énerver sur votre prochain projet.

]]> http://fr.learnlayout.com/ http://fr.learnlayout.com/ Tue, 21 Jan 2014 11:01:00 +0100 <![CDATA[Traduit ailleurs : Comment fonctionnent les navigateurs]]>

Firefox dispose de deux arbres suppl�mentaires pour un calcul plus facile du style, l'arbre des r�gles et l'arbre de contexte de style. Webkit a aussi des objets de style, mais ils ne sont pas stock�s dans un arbre, comme l'arbre de contexte de style, seul le n�ud DOM pointe sur son style.

Les contextes de style contiennent des valeurs finales. Les valeurs sont calcul�es en appliquant toutes les r�gles d'appariement dans le bon ordre et en effectuant les manipulations qui les transforment de valeurs logiques � valeurs concr�tes. Par exemple, si la valeur logique est le pourcentage par rapport � l'�cran, il sera calcul� et transform� en unit�s absolues. L'id�e derri�re l'arbre des r�gles est tr�s intelligente. Elle permet de partager ces valeurs entre les n�uds pour �viter de les calculer � nouveau. Cela �conomise aussi de l'espace.

L'ensemble des r�gles adapt�es sont stock�es dans un arbre. Les n�uds du bas d'un chemin sont prioritaires. L'arbre contient tous les chemins pour la correspondance de r�gles qui ont �t� trouv�es. Le stockage des r�gles se fait paresseusement. L'arbre n'est pas calcul� au d�but de chaque n�ud, mais � chaque fois qu'un style de n�ud doit �tre calcul�, le chemin calcul� est ajout� � l'arbre.

L'id�e est de voir l'arbre des chemins comme des mots dans un dictionnaire. Disons que nous avons d�j� calcul� cet arbre r�gle :

Supposons que nous devions faire correspondre des r�gles pour un autre �l�ment dans l'arborescence de contenu et que nous trouvons que les r�gles appari�es (dans le bon ordre) sont B - E - I. Nous avons d�j� ce chemin dans l'arbre, car nous avons d�j� calcul� le trajet A - B - E - I - L. Nous avons maintenant moins de travail � faire.

Voyons comment cet arbre nous permet d'�conomiser du travail.

Les contextes de style sont divis�s en structures. Ces structures contiennent des informations de style pour une certaine cat�gorie comme la bordure ou la couleur. Toutes les propri�t�s dans une structure sont h�rit�es ou non h�rit�es. Les propri�t�s h�rit�es sont des propri�t�s qui ne sont pas d�finies par l'�l�ment, elles sont h�rit�es du parent. Les propri�t�s non h�rit�es (appel�es propri�t�s � remise � z�ro �) utilisent des valeurs par d�faut si elles ne sont pas d�finies.

L'arbre nous aide en mettant en cache les structures (contenant les valeurs finales calcul�es) dans l'arborescence. L'id�e est que si le n�ud du bas n'a pas fourni une d�finition pour une structure alors une structure mise en cache pour un n�ud sup�rieur peut �tre utilis�e.

Lors du calcul du contexte de style pour un �l�ment donn�, on calcule d'abord un chemin dans l'arbre des r�gles ou on en utilise un existant. Nous commen�ons alors par appliquer les r�gles dans le chemin pour combler les structures dans notre nouveau contexte style. Nous commen�ons � la partie basse du chemin, celui avec la plus haute priorit� (g�n�ralement le s�lecteur le plus sp�cifique) et parcourir l'arborescence jusqu'� ce que notre structure soit pleine. S'il n'y a pas de sp�cification pour la structure dans ce n�ud r�gle, alors nous pouvons grandement optimiser, on remonte l'arborescence jusqu'� ce qu'on trouve un n�ud qui satisfait pleinement et nous pointons tout simplement dessus, c'est la meilleure optimisation, la structure enti�re est partag�e. Cela permet d'�conomiser le calcul des valeurs finales et la m�moire.

Si nous trouvons des d�finitions partielles, nous remontons l'arbre jusqu'� ce que la structure soit compl�te.

Si nous n'avons pas trouv� de d�finitions de notre structure, alors, dans le cas o� la structure est de type � h�rit� �, nous pointons vers la structure du parent dans l'arborescence des contextes, dans ce cas, nous avons �galement r�ussi � partager la structure. Si c'est une structure � remise � z�ro �, alors les valeurs par d�faut sont utilis�es.

Si le n�ud le plus sp�cifique ajoute des valeurs, alors nous devons faire quelques calculs suppl�mentaires pour la transformer en valeurs r�elles. Ensuite nous mettons en cache le r�sultat dans le n�ud de l'arbre de sorte qu'il puisse �tre utilis� par des enfants.

Dans le cas o� un �l�ment a un fr�re qui pointe vers le n�ud de l'arbre, alors le contexte de style complet peut �tre partag� entre eux.

Voyons un exemple, supposons que nous ayons ce HTML :

Et les r�gles suivantes :

Pour simplifier les choses, disons que nous devons remplir seulement deux structures, la structure couleur et la structure marge. La structure couleur contient un seul membre, la couleur. La structure marge contient les quatre c�t�s.

L'arbre de r�gles r�sultant ressemblera � ceci (les n�uds sont identifi�s par le nom du n�ud et le num�ro de la r�gle sur laquelle ils pointent) :

Figure 15 : The rule tree
Figure 15 : l'arbre des r�gles

L'arbre des contextes ressemblera � ceci (le nom de n�ud est le nom de r�gle g�n�rale vers laquelle il pointe) :

Figure 16 : The context tree
Figure 16 : l'arbre des contextes

Supposons que nous analysions le code HTML et que nous arrivions � la deuxi�me balise <div>. Nous devons cr�er un cadre de style pour ce n�ud et remplir ses structures style.

Nous allons faire correspondre les r�gles et d�couvrir que les r�gles correspondantes pour le <div> sont 1, 2 et 6. Cela signifie qu'il y a d�j� un chemin d'acc�s existant dans l'arborescence que notre �l�ment peut utiliser, nous avons juste besoin d'ajouter un autre n�ud pour la r�gle 6 (le n�ud F dans l'arbre de r�gles).

Nous allons cr�er un contexte de style et le mettre dans l'arbre des contextes. Le nouveau contexte de style va pointer vers le n�ud F dans l'arbre de r�gles.

Nous avons maintenant besoin de remplir les structures du style. Nous allons commencer par remplir la structure de marge. Puisque la r�gle du n�ud F ne modifie pas la structure de marge, nous pouvons remonter dans l'arbre jusqu'� ce qu'on trouve une structure en cache calcul�e dans un n�ud d'insertion pr�c�dent et l'utiliser. Nous allons la trouver avec le n�ud B, qui est le n�ud le plus �lev� avec les r�gles de marge sp�cifi�es.

Nous avons une d�finition de la structure couleur, donc on ne peut pas utiliser une structure en cache. Puisque la couleur n'a qu'un attribut, nous n'avons pas besoin d'aller dans l'arbre pour en remplir d'autres. Nous allons calculer la valeur finale (convertir la cha�ne en RVB, etc.) et mettre en cache la structure calcul�e sur ce n�ud.

Le travail sur le deuxi�me �l�ment <span> est encore plus facile. Nous faisons correspondre les r�gles et arrivons � la conclusion qu'il pointe sur la r�gle G, comme le <span> pr�c�dent. Puisque ce sont des fr�res qui pointent vers le m�me n�ud, nous pouvons partager le contexte de style tout simplement en pointant dans le contexte du <span> pr�c�dent.

Pour les structures qui contiennent des r�gles qui sont h�rit�es du parent, la mise en cache se fait sur l'arbre de contexte (la propri�t� de couleur est en fait h�rit�e, mais Firefox la traite comme � remise � z�ro � et la met en cache sur l'arbre de r�gles).

Par exemple, si nous ajoutons des r�gles de polices dans un paragraphe :

  1. p {font-family:Verdana;font size:10px;font-weight:bold}

Alors, l'�l�ment de paragraphe, qui est un enfant de <div> dans l'arbre de contexte, aurait pu partager la structure de police de son parent. Cela serait le cas si aucune r�gle de police n'avait �t� sp�cifi�e pour le paragraphe.

Avec Webkit, qui ne dispose pas d'un arbre de r�gles, les d�clarations correspondantes sont travers�es quatre fois. En premier, les propri�t�s non importantes (propri�t�s qui doivent �tre appliqu�es d'abord parce que d'autres d�pendent d'elles, comme l'affichage) sont appliqu�es, ensuite, les propri�t�s importantes, puis les propri�t�s normales et enfin les propri�t�s normales pour les r�gles importantes. Cela signifie que les propri�t�s qui apparaissent plusieurs fois seront r�solues selon l'ordre de cascade correct. C'est le dernier qui l'emporte.

Donc, pour r�sumer, le partage des objets style (tout ou partie des structures � l'int�rieur) r�sout les probl�mes 1 et 3. L'arbre de r�gles Firefox contribue �galement � l'application des propri�t�s dans le bon ordre.

]]> http://web.developpez.com/tutoriels/web/how-browsers-work/ http://web.developpez.com/tutoriels/web/how-browsers-work/ Wed, 12 Jun 2013 01:06:00 +0200 <![CDATA[Traduit ailleurs : Apprendre à apprécier les parties les moins sexy de CSS]]>

Le futur des CSS nous donne beaucoup d’occasions de nous enthousiasmer : d’un côté il y a un paquet de nouvelles méthodes qui vont révolutionner notre façon de mettre en page le web, et de l’autre il y a un ensemble d’effets graphiques qui vont permettre d’appliquer des filtres et shaders 3Ds « à la volée ». Tout le monde aime ce genre de nouveautés : les magazines et les blogs débordent d’articles à ce propos.

Mais si ces outils font figure de chiens savants des CSS, je crois cependant qu’il est temps de s’intéresser aux figurants : les rouages du langage tels que les sélecteurs, les unités et les fonctions. Je les appelle souvent « les parties les moins sexy de CSS », mais c’est toujours avec beaucoup d’affection – affection qu’à mon sens vous devriez partager.

Pour découvrir pourquoi, faisons rapidement le tour de ces parties pas très sexy qui sont conçues dans des laboratoires sombres, loin de la lumière et de l’éclat de celles que l’on expose fièrement dans la vitrine. Certains composants existent depuis longtemps mais méritent plus de reconnaissance, tandis que d’autres font tout juste leur apparition dans les navigateurs. Tous révolutionneront nos méthodes de travail, même si ce sera parfois bien discrètement et modestement.

Unités de taille relatives

En tant que développeur intelligent et consciencieux, il est fort probable que vous ayez déjà travaillé avec les dimensions relatives – unités em ou pourcentages. Du coup, vous avez certainement déjà été confronté aux problèmes d’héritage qui vous ont forcé à sortir votre calculette.
De nos jours, il est relativement commun de définir une taille de police de base pour le document, puis d’utiliser des unités relatives pour régler la taille des polices dans le reste de la page. En CSS, cela donne quelque chose comme ça :

1
2

html { font-size: 10px; }
p { font-size: 1.4em; }

C’est très bien, et ça ne pose aucun problème… jusqu’à ce que vous vouliez donner une taille différente à un élément enfant. Par exemple, dans un code tel que celui-ci :

1

Le chat s’est assis sur le <span>tapis</span>.

Si vous voulez que ce span soit d’une taille de police plus petite, par exemple 1.2em, que devez-vous faire ? Sortir votre calculette et diviser 1,2 par 1,4 pour obtenir le résultat suivant :

1

p span { font-size: 0.85714em; }

Bien sûr, le problème ne se limite pas à l’utilisation des em.
Lorsque vous construisez un site fluide en utilisant des pourcentages, vous savez que le pourcentage est relatif à son conteneur. Donc si vous souhaitez fixer la largeur d’un élément à 40 % de celle de son parent (qui est de 75 %), alors la largeur de l’élément enfant doit être réglée à 53.33333%.

Pas top.

Longueurs relatives à la racine

Pour combattre ce problème de dimensionnement des polices, nous avons dorénavant accès à l’unité rem (root em). Il s’agit toujours d’une unité relative, mais qui dépend d’une valeur de base fixe : la taille de la police de l’élément racine du document (l’élément html). En supposant que la taille de la police de l’élément racine soit de 10px comme dans l’exemple précédent, les règles CSS nécessaires dans notre cas sont :

1
2

p { font-size: 1.4rem; }
p span { font-size: 1.2rem; }

Ces deux règles sont relatives à la taille de police de l’élément racine, ce qui est beaucoup plus élégant et simple à manipuler, surtout si vous avez des valeurs de base qui sont 10px ou 12px. C’est un peu comme si on utilisait à nouveau les valeurs en pixels, mais de manière extensible cette fois.

C’est l’une des fonctionnalités CSS les mieux supportées de toutes celles présentées dans cet article. Elle est implémentée par tous les navigateurs modernes, y compris IE9, et seulement absente sur Opera Mobile.

Longueurs relatives au viewport

Si vous trouvez que l’unité rem est cool (c’est mon cas), vous allez adorer la nouvelle panoplie d’unités de longueur destinées à combattre le problème des pourcentages. Elles fonctionnent de manière similaire à l’unité rem, si ce n’est qu’elles sont relatives à la taille du viewport de l’appareil du navigateur 1 plutôt qu’à une taille définie par l’auteur sur la racine du document.

Les deux unités principales sont vh et vw, qui sont relatives (respectivement) à la hauteur et à la largeur du viewport. Chacune prend comme valeur un nombre qui est équivalent au pourcentage de la longueur spécifiée. Comme je me souviens de mes leçons d’écriture de scénario, je vais plutôt vous montrer un exemple :

Dans cet exemple, la hauteur du div serait exactement la moitié de la hauteur du viewport ; 1vh = 1 % de la hauteur du viewport, donc il est logique que 50vh soit l’équivalent de 50 % de la hauteur du viewport.

Quand la taille du viewport change, celle de la valeur de l’unité aussi. Mais l’avantage par rapport aux pourcentages est de ne pas avoir à se soucier des éléments parents : un élément avec une largeur de 10vw sera toujours de cette largeur quelle que soit celle de son conteneur.

Il existe aussi une unité vmin, équivalent à la valeur minimale de vh ou vw, et une unité correspondante vmax devrait être ajoutée aux spécifications (ce n’est pas encore le cas au moment où j’écris cet article 2).

À l’heure actuelle, ces unités sont disponibles dans IE9+, Chrome et Safari 6.

Valeurs calculées

Quand vous travaillez avec des mises en pages fluides ou responsive, vous rencontrerez certainement un problème de mélange d’unités – comme une grille aux dimensions en pourcentage avec des marges fixes.
Par exemple :

1
2
3
4

div { margin: 0 20px; width: 33%; }

Si votre mise en page utilise uniquement des padding et des border, vous pouvez utiliser box-sizing pour vous aider à contourner ce problème de mélange, mais ça ne vous aidera pas avec les margin. Une meilleure approche, plus flexible, consiste à utiliser la fonction de valeur calc(), qui vous permet de réaliser des opérations mathématiques comportant différentes unités, comme par exemple :

1
2
3
4

div { margin: 0 20px; width: calc(33% - 40px);
}

Vous n’êtes pas tenu de l’utiliser seulement sur les largeurs ; vous pouvez l’utiliser partout où des unités de longueur sont permises – et si vous souhaitez vraiment passer de l’autre côté du miroir vous pouvez utiliser calc() dans calc().

IE9+ supporte cette fonction sans préfixe (!), Firefox utilise le préfixe -moz- (a priori jusqu’à la version 16 ou 17), et Chrome et Safari l’implémentent avec le préfixe -webkit-. Par contre il n’est apparemment toujours pas disponible dans une version mobile de Webkit.

Charger un sous-ensemble de caractères

La réactivité a toujours été un paramètre important, mais le grand nombre de mobiles sur le marché – chacun apportant son lot de variabilité et d’incertitudes quant aux vitesses de connexion – accentue le trait. Une façon d’accélérer le chargement des pages est de limiter la taille des fichiers externes, ce qui rend une nouvelle propriété de @font-face permettant de réaliser cette opération particulièrement appréciable.

La propriété en question est unicode-range qui prend comme valeur un ensemble de références de caractères Unicode. Lors de l’appel d’éléments externes, seuls les caractères spécifiés sont chargés depuis le fichier de police au lieu de l’ensemble complet. Voici le code qui explique comment ne charger que trois caractères depuis le fichier foo.ttf :

1
2
3
4
5

@font-face { font-family: foo; src: url('foo.ttf'); unicode-range: U+31-33;
}

Ceci est particulièrement utile si vous utilisez des polices d’icônes et souhaitez seulement en montrer un sous-ensemble dans une page donnée. Lors d’un test que j’ai effectué, l’utilisation de unicode-range a permis d’économiser 0,85 seconde sur le chargement d’un fichier de police, ce qui n’est pas sans conséquences. Bien entendu, ce résultat peut varier suivant le contexte.

Cette propriété est actuellement implémentée dans IE9+ et les navigateurs Webkit tels que Chrome et Safari.

Nouvelles pseudo-classes

Les unités et valeurs sont bien sympas, mais ce sont les sélecteurs et les pseudo-classes qui m’enthousiasment le plus. Trouver une combinaison de sélecteurs astucieuse, même si elle reste cachée en un lieu que seuls quelques intrépides aventuriers pourront découvrir, me fait me sentir tel un artiste. Comme le disait le père de Steve Jobs : vous devriez vous assurer que la face arrière de la barrière est aussi bien peinte que la face avant même si personne ne la verra, parce que VOUS vous le saurez.

La première fois que j’ai utilisé :nth-of-type(), j’ai eu une révélation, comme si j’avais abattu les portes de la perception. OK, j’exagère un peu. Mais certaines nouvelles pseudo-classes méritent qu’on s’extasie.

La pseudo-classe de négation

Vous ne réaliserez probablement pas à quel point la pseudo-classe :not() est utile jusqu’à ce que vous l’utilisiez. L’argument passé à :not() est un sélecteur simple, pas une combinaison. Quand une liste d’éléments est construite par un sélecteur qui inclut :not(), tous les éléments correspondant à l’argument seront exclus de cette liste. Je sais, ça m’a paru compliqué aussi, mais en fait c’est assez simple.

Imaginez ceci : vous avez une liste d’éléments et vous souhaitez appliquer une règle à tous ses éléments impairs mais jamais au dernier élément. Pour l’instant, vous devriez faire quelque chose comme ça :

1
2
3

li { color: #00F; }
li:nth-child(odd) { color: #F00; }
li:last-child { color: #00F; }

Grâce à la pseudo-classe de négation, vous pouvez exclure le dernier élément de la liste en utilisant :last-child comme argument, ce qui réduira le nombre de règles nécessaires et simplifiera un peu l’entretien du code :

1
2

li { color: #00F; }
li:nth-child(odd):not(:last-child) { color: #F00; }

Rien de très novateur, et comme je l’ai montré on peut travailler sans, mais ça reste assez utile. J’ai eu l’opportunité d’utiliser cette pseudo-classe dans un projet reposant sur un Webkit embarqué, et elle a démontré son utilité de manière constante. C’est honnêtement l’une de mes pseudo-classes favorites.

Tout à fait, j’ai des pseudo-classes favorites.

C’est la fonctionnalité la plus largement implémentée de cet article : elle est présente dans IE9+ et tous les navigateurs modernes, sans préfixe. Et si vous êtes familier avec jQuery, vous avez probablement l’habitude de l’utiliser : elle y est présente depuis la version 1.0, ainsi que la méthode not() équivalente.

La pseudo-class :matches() accepte comme argument un sélecteur simple, un sélecteur composé, une liste séparée par des virgules, ou une combinaison de ces éléments.
Super ! Mais elle fait quoi ?

Elle est surtout utile pour éliminer les redondances dans les sélecteurs multiples. En guise d’exemple concret, imaginez que vous ayez des éléments p dans différents containers mais que vous souhaitiez n’en sélectionner que certains ; vous écrirez peut-être une règle de style ressemblant à ça :

1
2
3
4
5

.home header p,
.home footer p,
.home aside p { color: #F00;
}

Avec :matches() vous pouvez considérablement raccourcir cette règle en trouvant les éléments communs à ces sélecteurs ; dans notre exemple tous débutent par .homeet finissent par p, nous pouvons donc utiliser :matches() pour agréger tous les éléments intermédiaires. Déroutant ? Voici à quoi cela ressemblerait :

1

.home :matches(header,footer,aside) p { color: #F00; }

Cette pseudo-classe fait actuellement partie de CSS4 (Sélecteurs CSS Niveau 4, pour être précis), et dans la même spécification il est mentionné que l’on pourra utiliser la même syntaxe (sélecteurs composés séparés par des virgules) dans les futures versions de :not(). Passionnant !

Aujourd’hui, :matches() est disponible dans Chrome et Safari avec le préfixe -webkit- et dans Firefox sous son ancien nom, :any(), avec le préfixe -moz-.

Aimez-vous enfin les figurants ?

La meilleure chose à propos de toutes les nouvelles fonctionnalités de cet article, c’est qu’elles règlent des problémes réels, depuis la simple répétition de sélecteurs jusqu’aux nouveaux défis de la construction de sites responsive à haute-performance. En fait, je peux tout à fait imaginer utiliser toutes ces fonctionnalités de manière parfaitement récurrente.

Les nouvelles fonctionnalités comme les filtres sont peut-être plus visibles, mais il est bien plus probable que celles présentées ici vous soient utiles dans tous vos projets.

Chacune d’entre elles facilitera votre vie professionnelle tout en élargissant le champs des possibles, et c’est assez sexy finalement, non ?

Notes

]]> http://letrainde13h37.fr/25/traduction-apprendre-a-apprecier-les-parties-les-moins-sexy-de-css/ http://letrainde13h37.fr/25/traduction-apprendre-a-apprecier-les-parties-les-moins-sexy-de-css/ Sat, 25 May 2013 11:05:00 +0200 <![CDATA[Traduit ailleurs : Comprendre z-index et les contextes d'empilement]]>

Cet article est une traduction de What No One Told You About Z-Index écrit par Philip Walton le 22 décembre 2012.

Ce que personne ne vous a dit sur z-index

Le problème avec z-index, c’est que très peu de personnes ont réellement compris son fonctionnement. Ce n’est pas très compliqué, mais si vous n’avez jamais pris le temps de lire la spécification, il y a certainement des aspects cruciaux qui vous ont échappé.

Vous ne me croyez pas? Ok, voyons si vous pouvez résoudre ce problème?

Le problème

Dans le HTML suivant, vous avez trois <div>, et chaque <div> contient un seul élément <span>. Chaque <span> a sa propre couleur d’arrière-plan, respectivement rouge, vert et bleu. Chaque <span> est positionné de manière absolue près du coin haut gauche du document, de manière à chevaucher légèrement un autre élément <span>, ce qui permet de bien distinguer l’empilement. Le premier <span> a une valeur de z-index de 1, alors que les deux autres non pas de z-index défini.

Voici à quoi ressemble le HTML et le CSS. J’ai également inclus une démo du rendu (via CodePen)

<div> <span class="red">Red</span>
</div>
<div> <span class="green">Green</span>
</div>
<div> <span class="blue">Blue</span>
</div>

.red, .green, .blue { position: absolute;
}
.red { background: red; z-index: 1;
}
.green { background: green;
}
.blue { background: blue;
}

See the Pen ksBaI by philipwalton (@philipwalton) on CodePen

Le challenge: essayez de faire passer le <span> rouge derrière les éléments bleu et vert en respectant ces règles:

  • Ne pas modifier le code HTML
  • Ne pas ajouter ni modifier la propriété z-index, sur aucun élément
  • Ne pas ajouter ni modifier la propriété position, sur aucun élément

Pour vérifier que vous avez bien compris, cliquez sur «Edit on CodePen» et jouez un peu avec. Le résultat doit être identique à l’exemple ci-dessous:

Attention: Ne cliquez pas sur l’onglet CSS dans l’exemple ci-dessous au risque de dévoiler la solution.

See the Pen dfCtb by philipwalton (@philipwalton) on CodePen

La solution

La solution est d’ajouter une valeur d’opacité inférieure à 1 sur la première <div> (le parent du <span> rouge). Voici le CSS du CodePen ci-dessus: 

div:first-child{ opacity: .99;
}

Si vous êtes perplexe et n’aviez jamais pensé que l’opacité avait un impact sur l’ordre d’empilement des éléments, bienvenue au club. J’ai eu la même réaction quand je suis tomber pour la première fois sur ce cas.

Heureusement, la suite de l’article va clarifier les choses.

Ordre d’empilement (Stacking order)

z-index semble très simple: les éléments avec un z-index plus élévé apparaissent devant les éléments avec un z-index plus faible. Et bien en fait, non. Et c’est bien là le problème de z-index. Ça parait tellement simple, que beaucoup de développeurs ne prennent pas le temps de lire les détails.

Chaque élément HTML peut être devant ou derrière un autre élément du document. C’est ce que l’on appelle l’ordre d’empilement. Les règles qui définissent cet ordre sont plutôt bien définies dans la spécification, mais comme je l’ai déjà mentionné, elles ne sont pas bien comprises par la plupart des développeurs web.

Quand les propriétés z-index et position ne sont pas utilisées, les règles sont plutôt simples: l’ordre d’empilement est identique à l’ordre d’apparition dans le HTML. (OK, c’est en fait un peu plus compliqué que cela, mais tant que vous n’utilisez pas des marges négatives pour superposer des éléments en ligne, vous ne rencontrerez jamais ce genre de cas là)

Quand vous commencez à utiliser la propriété position, les éléments positionnés (et ses enfants) sont affichés devant les éléments non-positionnés. (Un élément est considéré «positionné» lorsque que la valeur de la propriété position est différente de static, comme par exemple relative, absolute, etc.)

Enfin, lorsque z-index est associé, les choses deviennent plus délicates. D’abord, il est naturel de penser que les éléments avec un z-index plus élevé apparaissent devant les éléments avec un z-index plus faible, et que les éléments qui ont un z-index sont affichés devant les éléments qui n’en ont pas, mais ce n’est pas si simple. Premièrement, le z-index ne fonctionne que sur les éléments positionnés. Si vous tentez d’appliquer un z-index sans position définie, il ne se passera rien. Deuxièmement, les valeurs de z-index peuvent créer un contexte d’empilement, et subitement les choses deviennent légèrement plus compliquées.

Contextes d’empilement (Stacking contexts)

Un groupe d’éléments qui ont un parent commun qui se déplace d’avant en arrière dans l’ordre d’empilement est ce que l’on appelle un contexte d’empilement. Une bonne compréhension des contextes d’empilement est la clé pour vraiment saisir la manière dont le z-index fonctionne.

Chaque contexte d’empilement a un élément HTML unique comme racine. Lorsque un nouveau contexte d’empilement est créé sur un élément, cela contraint ses enfants à apparaître à un endroit précis dans l’ordre d’empilement. Cela signifie qu’un élément au sein d’un contexte d’empilement, qui est le plus bas dans l’ordre d’empilement, ne peut pas être affiché devant un élément qui est dans un autre contexte d’empilement affiché plus haut, même avec un z-index très important.

De nouveaux contextes d’empilement peuvent êtres créés:

  • Lorsque un élément est la racine du document (l’élément <html>)
  • Lorsque un élément dont la valeur de la propriété position est différente de static et lorsque z-index est différent de auto.
  • Lorsque un élément à une opacité inférieure à 1

La première et la seconde façon de créer un contexte d’empilement sont plutôt claires et sont généralement connues des développeurs web (mêmes s’ils ne savent pas forcément que ça a un nom).

La troisième façon (l’opacité) n’est presque jamais évoquée hors des spécifications du W3C.

Note personnelle de traduction: Il existe d’autres règles qui crée un contexte d’empilement (en CSS3):

  • Lorsque un élément dont la valeur de la propriété transform est différente de none
  • Lorsque un élément dont la valeur de la propriété transform-style vaut preserve-3d
  • Lorsque un élément dont la valeur de la propriété filter est différente de none
  • Lorsque un élément, enfant d’un Flexbox, dont la valeur de la propriété z-index est différente de auto (même si la valeur de la propriété position est static)
  • Lors de l’utilisation des propriétés clip-path, mask ou mask-image
  • et d’autres…

Définir l’ordre d’empilement d’un élément

Réussir à déterminer l’ordre d’affichage pour chaque élément d’une page (y compris les bordures, les arrière-plans, les textes, etc.) est très difficile et très loin du cadre de cet article (je vous renvoie une nouvelle fois à la spécification).

Mais dans la plupart des cas, une compréhension de base peut permettre de prévoir plus facilement le développement CSS. Commençons donc par définir l’ordre d’affichage au sein de chaque contexte d’empilement.

Ordre d’empilement au sein du même contexte d’empilement

Voici les règles qui définissent l’ordre d’affichage pour un contexte d’empilement (du bas vers le haut):

  • L’élément racine du contexte d’empilement
  • Les éléments positionnés (et ses enfants) avec un z-index négatif (les valeurs les plus hautes sont affichées devant les plus basses; les éléments avec le même z-index sont affichés en suivant l’ordre du HTML)
  • Les éléments non-positionnés (en suivant l’ordre du HTML)
  • Les éléments positionnés (et ses enfants) avec un z-index dont la valeur est auto (en suivant l’ordre du HTML)
  • Les éléments positionnés (et ses enfants) avec un z-index positif (les valeurs les plus hautes sont affichées devant les plus basses; les éléments avec le même z-index sont affichés en suivant l’ordre du HTML)

Note: les éléments positionnés avec un z-index négatif sont affichés en premier dans le contexte d’empilement, ce qui signifie qu’ils apparaissent derrière tous les autres éléments. Grâce à cela, il devient possible qu’un élément soit affiché derrière son parent, ce qui est normalement impossible. Cela fonctionne uniquement si le parent est dans le même contexte d’empilement et si ce parent n’est pas l’élément racine du contexte d’empilement. Un très bon exemple de cette technique est la création d’ombres sans images par Nicolas Gallagher.

Ordre d’empilement global

Avec une solide compréhension sur la création de nouveaux contextes d’empilement ainsi qu’une maîtrise de l’ordre d’empilement au sein d’un contexte d’empilement, il devient assez facile de déterminer l’ordre d’empilement global des éléments.

La clé de la réussite est d’être capable de repérer quand de nouveaux contextes d’empilement sont créés. Si vous appliquez un z-index d’un milliard sur un élément et que l’ordre de cet élément n’est pas affecté, vérifiez si l’un de ses parents ne crée pas un contexte d’empilement. Si c’est le cas, votre z-index ne vous sera pas d’une grande aide.

Pour conclure

Revenons au problème initial, j’ai recréé la structure HTML en ajoutant des commentaires pour chaque balise qui indique son ordre d’empilement. Cet ordre se base sur le CSS d’origine.

<div><!-- 1 --> <span class="red"><!-- 6 --></span>
</div>
<div><!-- 2 --> <span class="green"><!-- 4 --></span>
</div>
<div><!-- 3 --> <span class="blue"><!-- 5 --></span>
</div>

Lorsque nous appliquons la propriété opacité sur la première <div>, l’ordre d’empilement est modifié de cette façon: 

<div><!-- 1 --> <span class="red"><!-- 1.1 --></span>
</div>
<div><!-- 2 --> <span class="green"><!-- 4 --></span>
</div>
<div><!-- 3 --> <span class="blue"><!-- 5 --></span>
</div>

Le span.red, initialement en position 6, se retrouve en 1.1. J’ai utilisé ici la notation avec un point pour bien symboliser la création d’un nouveau contexte d’empilement où span.red devient le premier élément au sein de ce contexte.

C’est donc maintenant un peu plus clair sur pourquoi l’élément rouge est affiché sous les autres éléments. L’exemple original contenait seulement deux contextes d’empilement, le contexte racine et celui formé par le span.red. Avec l’ajout de l’opacité sur le parent de span.red, nous avons créé un troisième contexte, et donc, le z-index du span.red est uniquement actif au sein de ce nouveau contexte. Du fait que la première <div> (celle où l’opacité est appliquée) et ses éléments frères ne sont ni positionnés ni n’ont de z-index, leur ordre d’affichage est celui du HTML, ce qui signifie que la première <div>, et tous ses enfants contenus dans le contexte d’empilement, sont affichés sous la deuxième et la troisième <div>.

Ressources complémentaires

Je me permets également de vous proposer mon article complet sur les subtilités de CSS:

]]> http://iamvdo.me/blog/comprendre-z-index-et-les-contextes-dempilement http://iamvdo.me/blog/comprendre-z-index-et-les-contextes-dempilement Sun, 17 Feb 2013 03:02:00 +0100 <![CDATA[Traduit ailleurs : Outline none]]> ]]> http://www.outlinenone.fr/ http://www.outlinenone.fr/ Wed, 14 Nov 2012 11:11:00 +0100