pompage.net

De l'audit de contenu aux idées de design :

Evren Kiefer, Frank Taillandier — 2015-10-21T08:40:29Z

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.

Concevoir un design sans la couleur

Frédéric Chotard, Nicolas Contant — 2014-09-09T10:30:00Z

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.

Cet article fait partie de l'ouvrage « Five Simple Steps : Designing for the Web » écrit par Mark Boulton en 2006. La suite de l'article est disponible en anglais sur son site : deuxième et troisième partie.

Écrire du JavaScript véloce et à faible empreinte mémoire

2014-08-26T10:30:00Z

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 :

Que puis-je faire pour rendre mon code plus efficient ?
Quelles optimisations communes sont faites par les moteurs JavaScript ?
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 :

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é.
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.
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]).
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).
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.
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 :

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

utilise une source de donnée locale contenant des éléments avec un identifiant numérique,
affiche un tableau contenant ces données,
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 = $(''); for (var j = 0; j < this.data.length; j++) { $tr.append('' + this.data[j]['id'] + ''); } $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.

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.
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);

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

Si vous souhaitez stocker un paquet de nombres ou une liste d'objets de même nature, utilisez les tableaux.
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.
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.
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

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().
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 :

Mesurer : repérer les points les plus lents de votre application ( 45%)
Comprendre : trouver ce qui provoque cette lenteur ( 45%)
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 . 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 :

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.
trace-deopt : enregistre dans un fichier les portions de code qui ont été déoptimisées pendant l'exécution.
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.

Inline-block est-il un substitut aux floats ?

Augustin Chassine, Didier De Vos, Fabien Basmaison, Goulven Champenois — 2014-08-05T10:30:00Z

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

Introduction à l'accessibilité de JavaScript

Bertrand Keller, Frank Taillandier, Frédéric Chotard — 2014-08-04T08:00:00Z

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.

Votre application me fait grossir

Blandine Proust, Frédéric Chotard — 2014-07-24T10:30:00Z

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.

D'abord la structure. Le contenu suivra.

2014-07-08T10:30:00Z

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 :

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

D'abord la structure. Le contenu suivra.

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.

Principes à connaître pour améliorer vos feuilles de styles

2014-06-19T15:37:51Z

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 :

Ne pas se ruer sur le code et faire simple
Apprendre les bases et quelques astuces
Ne pas se répéter
CSS orienté objet
CSS3 : apprendre ce que l'on peut faire et ce que l'on peut utiliser
Amélioration progressive et dégradation élégante
Les préprocesseurs CSS
Garder un œil sur l'avenir
Lire le code des autres
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

DRY CSS, don't repeat your CSS par Steven Bradley
DRY CSS: a don't-repeat-yourself methodology for creating efficient, unified and scalable style sheets par Jeremy Clarke

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) :


  Foo Bar 
  Suivez-moi sur twitter 

 Suivez-moi sur twitter
 /* 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 . 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

An introduction to OOCSS par Louis Lazaris
Object Oriented CSS par Nicole Sullivan
OOCSS.org
Don't use IDs in CSS selectors? par Oli Studholme

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 :

Comment vais-je faire cela ?
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.
Quelle est la qualité du rendu par les navigateurs ?
1. Bonne : fastoche, fin de l'histoire.
2. Mauvaise, passez à l'étape 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.
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.

Comment vais-je faire cela ?
D'accord, je comprends. Fait-il partie de la spécification CSS2.1 ?
- Non, les dégradés appartiennent à CSS3.
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.
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.
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 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.

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

Progressive enhancement and graceful degradation sur DevOpera
Understanding progressive enhancement par Aaron Gustafson

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

Sass vs. LESS vs. Stylus par Johnathan Croom
Musing on preprocessing par Chris Coyier
Deep Dive Into CSS Preprocessors par Jonathan Verrecchia
Guidelines using OOCSS and CSS preprocessors par Chris Webb

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 :

Page d'accueil du W3C pour les CSS
CanIUse.com pour la compatibilité navigateur
Mozilla Developer Network pour la documentation
HTML5 Rocks pour les les tutoriels et les articles les plus récents et les plus pointus

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 :

Page d'accueil du W3C pour les CSS
Les spécifications actuelles des CSS
Comment assigner des valeurs aux propriétés ; la cascade ; l'héritage (W3C)
Les CSS sur Wikipedia EN et sur Wikipédia FR
CSS 2.1: le modèle de boîte
WebPlatform.org
Modernizr
CanIUse
z-index And The CSS Stack: Which Element Displays First? par Steven Bradley
DRY CSS, don't repeat your CSS par Steven Bradley
DRY CSS: a don't-repeat-yourself methodology for creating efficient, unified and scalable style sheets par Jeremy Clarke
Progressive enhancement and graceful degradation sur DevOpera
Understanding progressive enhancement par Aaron Gustafson
Sass
LESS
Stylus
Crush
Sass vs. LESS vs. Stylus par Johnathan Croom
Musing on preprocessing par Chris Coyier
Deep Dive Into CSS Preprocessors par Jonathan Verrecchia
Guidelines using OOCSS and CSS preprocessors par Chris Webb
Mozilla Developer Network
HTML5 Rocks
CodePen
CSS Deck
Dabblet
TheCodePlayer

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.

Quelles mesures CSS, pour quel usage ?

Frédéric Chotard, Goulven Champenois — 2014-04-09T10:00:00Z

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.

Les pixels (`px`)

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

Tests de contenu

2014-03-26T11:00:00Z

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 ?

Le conte de deux publics

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.

pompage.net

De l'audit de contenu aux idées de design :

Le Projet

Le processus

Identifier et documenter le volume et le type des contenus

Identifier et documenter la structure actuelle du contenu

Déterminer si le contenu est utilisé

Documenter la présentation incohérente du contenu

Les résultats

Une conscience aiguë des priorités

Contraintes opérationnelles et commerciales

Un langage commun

Un vrai sens de l'échelle

Concevoir un design sans la couleur

On baisse d'un ton

Faisons sans la couleur

D'abord du gris

Vers des palettes mono- et duo-tonales

Écrire du JavaScript véloce et à faible empreinte mémoire

Comment fonctionne JavaScript au sein de V8 ?

Le ramasse-miette

Les mythes du déréférencement

Quelques règles générales

Les fonctions

Les closures

Les timers

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

Quelques astuces d'optimisation pour V8

Objets vs Tableaux : que dois-je utiliser ?

Quelques astuces pour l'utilisation des objets

Clonage d'objets

Les fonctions en cache grâce aux modules

Quelques astuces pour l'utilisation des tableaux

Représentation littérale des tableaux

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

Tableaux à clés consécutives ou non

Tableaux « troués » contre tableaux « pleins »

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

Optimiser vos applications

Mesurer la performance

Le profilage

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

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

Eviter les réagencements

Détecter les fuites de mémoires dans JavaScript

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

Mesures temporelles précises : HRT et Navigation Time API

About:memory et about:tracing

Conclusion

Inline-block est-il un substitut aux floats ?

Qu'est ce qu'un inline-block ?

La différence entre float et inline-block

Régler le problème de l'espace blanc

Quand utiliser les inline-blocks et quand utiliser les floats ?

Les floats, les inline-blocks et les grilles d'images

Les inline-blocks pour la navigation

Conclusion

Introduction à l'accessibilité de JavaScript

Ce que nous réserve l'avenir

Aujourd'hui

Le cœur de l'accessibilité

Les utilisateurs de technologies d'assistance

Les utilisateurs qui naviguent au clavier

Les utilisateurs sensibles au clignotement ou aux limites de temps

Conclusion

Votre application me fait grossir

D'abord la structure. Le contenu suivra.

Le contenu comme structure

Les concepteurs en tant que directeurs de contenu

D'abord la structure. Le contenu suivra.

Principes à connaître pour améliorer vos feuilles de styles

1. Ne vous ruez pas sur le code et faites au plus simple

Ne vous ruez pas sur le code

Faites simple

2. Connaître les bases et apprendre les astuces

Les bases de CSS

Les astuces

3. DRY

Plus d'informations sur DRY CSS

4. OOCSS

`About:memory` et `about:tracing`

Les pixels (`px`)

Les pourcentages (`%`)

`em` et `ex`

Unités relatives à la surface d'affichage (`vh` et `vw`)

Les pouces (`in`) et les centimètres (`cm`)

Les caractères (`ch`)

Grille de texte (`gd`)