artwaï exprimons votre différence
Aller au contenu
La simplicité absolue est
la meilleure manière de se distinguer.
– Charles Beaudelaire –
A la lecture de “le Culte de la complexité”, j’avoue n’avoir pu retenir une larme. Donc je vous partage cette traduction. Certains diront que coder c’est politique ; pour le texte ci-dessous il s’agit plus de principes qu’on oublie trop souvent sur l’autel des appellations marketing censées nous simplifier la vie.
Mais qui en fait, la complexifie à tous développeur et utilisateur.
Bonne lecture.
C’est un cadeau d’être simple. De plus en plus, dans notre travail, c’est un cadeau rare.
Dans une industrie qui prône l’innovation plutôt que la satisfaction client, et qui préfère l’algorithme au jugement humain (oubliant que chaque algorithme a un travers humain dans son ADN), peut-être ne devrions-nous pas nous étonner que les chaînes d’outils aient remplacé le savoir-faire.
De même, dans un domaine où les jeunes cadres blancs hétérosexuels prennent une écrasante majorité des emplois (y compris la plupart des emplois de gestion), on pouvait s’attendre à ce que le web soit récemment devenu une sorte de « compétition de mesure de bite » (NDT : tel quel dans l’article original).
Ça n’a pas toujours été comme ça et n’a pas besoin de rester comme ça. Si nous voulons revenir à notre travail d’améliorer tranquillement la vie des gens, avec une interaction réfléchie à la fois, nous devons nous débarrasser du culte de la complexité. Admettre que le problème existe est la première étape pour le résoudre.
En 2001, de plus en plus d’entre nous ont commencé à utiliser CSS pour remplacer les mises en page de tableaux HTML non sémantiques avec lesquelles nous avions conçu les premiers sites Web. J’ai vite remarqué quelque chose sur plusieurs de nos nouveaux sites construits en CSS. Je l’ai surtout observé dans les sites construits par les codeurs backend experts de l’époque, dont beaucoup considéraient HTML et CSS comme du babillage pour non-développeurs.
À l’époque, que ce soit par mépris pour les limitations intentionnelles (et conçues) du langage HTML et CSS ou par ignorance des intentions des concepteurs HTML et CSS, de nombreux codeurs qui passaient des mises en page aux CSS écrivaient des balisages composés principalement de divs et de spans. Là où ils voulaient dire item de liste, ils ont écrit span. Là où ils voulaient dire paragraphe, ils ont écrit div. Là où ils voulaient un titre de niveau deux, ils écrivaient div ou span avec un nom de classe h2, ou, évitant même ce geste tragicomique vers la structure du document, écrivaient un div ou un span avec un style en ligne verbeux. Ce div était suivi par un autre, et un autre. Ils ont grandi comme des sauterelles, dépouillant notre contenu de la signification structurelle.
En tant que précurseur et promoteur du CSS par le biais de mon travail dans The Web Standards Project (les enfants, demandez à vos parents), je me suis réjoui de voir plus de personnes utiliser ce nouvelle langage. Mais en tant que concepteur qui comprenait, au moins à un niveau de base, comment le HTML et le CSS étaient censés fonctionner ensemble, je me suis irrité.
Tous ceux qui ont écrit le genre de code que je viens de décrire pensaient qu’ils faisaient avancer le web simplement en s’éloignant des mises en page. Ils avaient de bonnes intentions, mais leurs exécutions étaient erronées. Mes collègues et moi, à A List Apart, étions donc obligés d’expliquer certaines choses.
Prioritairement, nous avons fait valoir que le HTML composé principalement de divs, de spans et de noms de classe n’était en aucun cas mieux que les mises en page de tableaux pour la découverte de contenu, l’accessibilité, la portabilité, la ré utilisabilité, ou l’avenir du Web. Si vous voulez construire pour les internautes et sur le long terme, avons-nous dit, alors le HTML simple, structurel et sémantique est mieux – en utilisant chaque élément pour l’usage auquel il est destiné. N’utilisez pas de div quand vous voulez dire p.
Cette idée basique, et j’utilise l’adjectif à bon escient, ainsi que d’autres concepts tout aussi rudimentaires et évidents, ont constitué la base de mon livre de 2003, Designing With Web Standards , que l’industrie a traité comme une révélation quand c’était seulement du bon sens.
Lorsque nous séparons les idées des conditions dans lesquelles elles apparaissent, le résultat est le dogme et la désinformation – deux choses qu’Internet est bon à amplifier. D’une manière ou d’une autre, au fil des années, dans les conversations de conception front-end, la prémisse « ne pas utiliser un div quand vous voulez dire p » a été corrompue en « les divs sont mauvais ».
Un retour de bâton en défense des divs suivit cette descente vide de sens, comme si le W3C avait créé la div comme un fruit défendu. Alors, soyons clairs. Aucun élément HTML n’est mauvais. Aucun élément HTML n’est bon. Un tournevis n’est ni bon ni mauvais, sauf si vous essayez de l’utiliser comme un marteau. Le bon usage est une question de pertinence.
Les divs ne sont pas mauvaises. Si aucun élément HTML5 n’est mieux adapté à l’objectif d’un élément, les divs sont le meilleur choix et le plus approprié. C’est du bon sens, non? Et encore.
D’une manière ou d’une autre, les deux phrases simples précédentes ne sont jamais que le fruit de ces discussions. D’une façon ou d’une autre, au fil des ans, une défense vigoureuse des divs a conduit à leur surexploitation provocante (voire même ignorante). Étrangement, la marche arrière issue d’un rejet dénué de sens a ouvert la porte à de nébuleux frameworks qui en abusent.
Remarque: nous ne nous inquiétons pas tellement de l’abus de divs. Après tout,ce sont pas des choses vivantes. Nous ne sommes pas puristes. Ce sont les gens qui utilisent les interfaces que nous avons conçues qui souffrent de notre dépendance excessive ou paresseuse à l’égard de ces obscurs frameworks exploitant des divs. C’est contre cette souffrance que nous protestons. La surexploitation des divs via des frameworks surchargés de « nourriture mystérieuse » offrent au développeur une énorme puissance, en particulier le pouvoir de construire des choses rapidement. Mais cette puissance a un prix que vos utilisateurs paient : une centaine de tonnes de choses dont votre projet n’a probablement pas besoin, mais que vos utilisateurs doivent quand même télécharger. Et ce gonflement n’est pas le seul problème. Car qui sait quel mal se cache dans le code de quelqu’un d’autre ?
Si vous êtes entré dans la conception et le développement Web au cours des dix dernières années, vous avez probablement appris à pouvoir vous fier aux frameworks. La plupart d’entre eux sont construits sur des tableaux sans signification de « divs et span-structures » pas mieux que le mauvais HTML que nous écrivions en 1995, cependant les pages résultantes peuvent apparaître plus avancées. Et qu’est-ce qui fait marcher l’ensemble de ces travaux de singe? JavaScript, et plus de JavaScript. Sans cela, votre contenu peut ne pas s’afficher. Avec lui, vous pouvez fournir plus de services que vous ne le souhaitiez.
Il n’y a rien de mal à utiliser les frameworks pour créer et tester rapidement des prototypes de produits, surtout si vous faites ce test dans un espace non-public. Et théoriquement, si vous savez ce que vous faites, et si vous êtes prêt à éditer le code dont votre produit n’a pas besoin, il n’y a rien de mal à utiliser un framework pour lancer un site public. Remarquez les phrases opératoires: si vous savez ce que vous faites, et si vous êtes prêts à éditer le code dont votre produit n’a pas besoin .
Hélas, de nombreux nouveaux concepteurs et développeurs (et même de nombreux développeurs expérimentés) ont l’impression de ne pas pouvoir lancer un nouveau projet sans faire glisser des paquets de NPM, Composer ou autre, sans aucune idée précise de ce que fait le code. Les résultats peuvent être dangereux . Pourtant, nous sommes là, en train de former toute une génération de développeurs pour construire et lancer des projets avec du code non fiable.
En effet, beaucoup de concepteurs et de développeurs avec qui je parle préfèreraient danser nus en public que de consentir à publier un site codé à la main, construit avec du code HTML, CSS et JavaScript amélioré , qu’ils comprennent et écrivent eux-mêmes. Pour eux, c’est une question de sécurité d’emploi et de viabilité. Il y a presque une crainte que si vous n’avez pas maîtrisé une douzaine de nouveaux frameworks et d’outils chaque année (et par maîtrisé, je veux dire utilisé), vous glissez dans l’insignifiance. Les recruteurs qui écrivent des offres d’emploi énumérent ainsi les dix mille outils que vous êtes censés connaitre en amont et en aval pour obtenir un poste de développeur front-end junior. Ce qui n’améliore pas la situation.
Comme nos bidules conçus à la va-vite, avec quinze couches de code que nous ne comprenons pas et que nous n’avons pas écrit, commencent à partir en vrille, nous accusons HTML et CSS pour les fautes des développeurs. Cette recherche de fautes donne naissance à des cultes de plus en plus complexes de CSS spécialisés, dont les critiques mutuelles font partie du charme. De nouvelles sectes surgissent, déclarant que le CSS est inexploitable, seulement pour briller en société, car les membres ne sont même pas d’accord sur la façon dont il est devenu obsolète, ou sur quelle technologie externe non destinée à contrôler la disposition doit être utilisée pour « réparer » CSS. (Indice: ils choisissent principalement JavaScript.)
Mais enfin, le CSS n’est pas inexploitable, et ce n’est pas si compliqué. (Vous savez ce qui est compliqué ? Poursuivre les mirages du prochain truc tendance.) Mais ne me croyez pas sur parole. Consultez ces liens :
CSS Grid est ici, c’est logique et assez facile à apprendre. Vous pouvez l’utiliser pour accomplir toutes sortes de mises en page qui nécessitaient JavaScript et des frameworks, ainsi que de nouveaux types de mise en page que personne n’a encore jamais essayé. Ce genre de pouvoir exige un certain apprentissage, mais c’est un bon apprentissage, le genre qui stimule la créativité, et son pouvoir ne se fait pas au détriment de la sémantique, de la performance, ou de l’accessibilité. Ce qui en fait une technologie web qui vaut la peine d’être maîtrisée.
On ne peut pas dire la même chose de notre déluge de frameworks et de plates-formes alternatives basées sur JavaScript. En tant que designer qui aimait créer des expériences web en code, je suis déconcerté et engourdi par la préférence croissante pour la complexité plutôt que pour la simplicité. La complexité est bonne pour convaincre les gens qu’ils ne pourraient pas faire votre travail. La simplicité est bonne pour tout le reste.
Une bonne communication vise à la clarté. Le design n’est jamais plus brillant que quand il apparaît le plus évident – le plus simple. La question pour les concepteurs de sites Web ne devrait jamais être aussi complexe que nous pouvons le faire. Mais c’est ce que c’est devenu. De même que, dans la poursuite du « délice », nous oublions la vraie joie que des interfaces fiables et invisibles peuvent apporter, ainsi que, en poursuivant la sécurité de l’emploi, nous rajoutons des exigences de plate-formes, oubliant que le design consiste à résoudre les problèmes commerciaux et clients … et que les compétences de base ne se démodent jamais. Comme Brandon Gregory d’ALA, l’explique ailleurs :
Je parle avec beaucoup de développeurs qui listent Angular, Ember, React, ou d’autres bibliothèques JavaScript sophistiquées parmi leurs compétences techniques. C’est génial, mais pouvez-vous transformer ce fouillis de fonctions que le développeur junior a écrit en un objet extensible personnalisé que nous pouvons utiliser sur d’autres projets, même si nous n’avons pas la place supplémentaire pour des bibliothèques lourdes ?
Pouvez-vous coder un diaporama d’images avec du Javascript classique pour que nous n’ayons pas besoin d’ajouter jQuery à un site Web plus ancien juste pour une fonctionnalité ?
Pouvez-vous me dire ce qu’est la récursivité et me donner un exemple concret ?
« J’interviewe les développeurs web. Voici comment m’impressionner. »
Il y a beaucoup de complexité dans la conception. Complexité technique. Complexité UX. Défis de contenu et de microscopie. Défis de performance. Cela n’a jamais été et ne sera jamais un travail facile.
La simplicité n’est pas facile – pas pour nous, de toute façon. La simplicité signifie faire le travail difficile qui fait que l’expérience apparaît sans efforts – la sueur, les tests tortureux et l’éventuel échec qui a finalement, avec un effort suffisant, rendu des expériences qui semblent « juste fonctionner ».
En déplorant que notre industrie se détourne des principes de base et des technologies résilientes, je ne suggère pas que les CDN et Git soient inutiles. Ou souhaiter que nous puissions revenir au FTP – même si j’ai apprécié les débuts du web design, quand un designer pouvait tout faire. Je suis content d’avoir vécu ces moments plus simples.
Mais j’aime bien ces moments-là. Et je pense que vous aussi. Notre médium grandit, et cela reste notre grand privilège d’aider à façonner son futur tout en créant de grandes expériences pour nos utilisateurs. N’oublions jamais à quel point nous sommes chanceux, et ne perdons pas de vue le peuple et le but que nous servons en poursuivant des mirages.
Article original : The Cult of the Complex
ISSN: 1534-0295 Copyright © 1998-2018
A List Apart Magazine and the authors.Translated with the permission of A List Apart Magazine and the author[s].
Traduit avec l’authorisation d’A List Apart Magazine et de l’auteur.
Photo de Jeffrey Zeldman par John Morrison
Photo d’entête par Mitchel Boot via Unsplash
De l'intérêt d'un design system pour la web performance 26 mars 2024 
Design et Performance pour 2022 15 décembre 2021 
Il est temps de renouer le dialog 27 septembre 2022 
Panorama Web de décembre 2021 8 janvier 2022 
L'expérience utilisateur sonne la fin de Google AMP ! 2 décembre 2021 
