HTeuMeuLeu

Je suis tombé récemment sur cet article initialement intitulé « Quand ne devrait-on pas utiliser WordPress ? ». J’ai d’abord cru à un article satirique, puis j’ai vite réalisé que l’auteur était sérieux. Parmi les arguments avancés pour justifier une utilisation systématique de WordPress, j’ai sursauté sur le suivant.

• Il ne sert à rien de réinventer la roue.

C’est un argument que je n’aime pas trop, mais que j’ai déjà entendu de la part de clients. Pour commencer, je n’aime pas la comparaison avec la roue. Je ne suis pas un travailleur à la chaîne qui assemble des pneus. Je suis intégrateur. Je me vois plus comme un artisan que comme un ouvrier sur une chaîne de montage.

Alors prenons une autre métaphore. Par exemple, la cuisine. Si vous allez dans un supermarché, vous trouverez certainement de quoi vous nourrir jusqu’à la fin de vos jours sans avoir jamais à cuisiner. Plats préparés, surgelés, conserves. Rien de telle qu’une bonne ratatouille surgelée, non ? Non ? Non ?

Mais alors, à quoi bon réinventer la ratatouille ?

Le premier argument qui me vient à l’esprit, c’est bien entendu la qualité. En cuisinant moi même une ratatouille, je connais la qualité de mes ingrédients.

Le second argument, c’est la facilité de personnalisation. Vous n’aimez pas les poivrons ? Aucun problème, je vous fait une ratatouille sans poivron.

Le dernier argument, c’est le plaisir. Découper soi même amoureusement ses aubergines, courgettes et tomates, et les faire revenir langoureusement à la poêle, c’est quand même autre chose que jeter un sachet plastique surgelé dans le micro-onde.

Le parallèle avec l’intégration, ou même le développement au sens large, n’est pas bien difficile à faire. Je suis un codeur dans l’âme. J’aime savoir comment fonctionne quelque chose avant de l’utiliser. J’ai besoin de m’assurer de la qualité de ce que j’utilise. J’aime aussi concevoir des pages et interfaces sur mesure, correspondant à un besoin précis. Et j’éprouve beaucoup de plaisir à faire tout ça, même si ça nécessite que j’y passe beaucoup de temps ou que j’y laisse quelques cheveux.

De la même manière que je pourrais me contenter de manger du surgelé tous les soirs, je pourrais me contenter de claquer du WordPress sur tous mes projets. Mais j’y perdrais surement vite goût.

Toute la subtilité de mon métier réside alors mon propre jugement de ma capacité à réinventer la ratatouille. Si on est vendredi à dix-sept heures et qu’il faut impérativement que je livre une page avec un carousel en 3D pour dans trente minutes, il y a des chances pour que je me jette sur la première bibliothèque faisant ça proprement que je trouverais.

Et ça ne signifie pas non plus que je vais systématiquement réessayer de réinventer la roue. J’aurais peu d’intérêts à créer mon propre pré-processeur CSS, mon propre langage de programmation, mon propre système d’exploitation, etc.

Pour citer Carl Sagan (dans un moment de télévision tel qu’on ne ferait plus de nos jours) :

Si vous souhaitez faire une tarte aux pommes à partir de zéro, vous devez d’abord inventer l’univers.

La semaine dernière, je suis tombé sur cet autre article intitulé « Je sais comment programmer, mais je ne sais pas quoi programmer ». Ce passage m’a apporté un autre argument pour réinventer la roue :

Dans la communauté du logiciel, l’attitude générale est de ne pas réinventer la roue. C’est presque mal perçu si vous réécrivez une bibliothèque quand une option mature et stable existe. Si c’est une bonne règle en général, les débutants ne devraient pas avoir peur de réinventer la roue. Quand c’est fait pour apprendre et pour s’entraîner, c’est très bien de faire une roue. C’est une partie importante de l’apprentissage. Par exemple, écrivez votre propre version de ls, mv, wget ou cowsay. Si vous souhaitez partir sur un jeu, alors faites un clone de Pong, Tetris ou Space Invaders. Vous n’avez pas besoin de reprendre toutes leurs fonctionnalités ou d’en faire une réplique exacte, mais vous démarrez avec votre objectif et une feuille blanche, et vous faites en sorte d’y arriver.

Il s’avère que Jeff Atwood avait écrit sur ce thème en 2009 :

« Ne réinventez pas la roue » devrait être utilisée comme un appel aux armes pour s’enrichir de toutes les solutions existantes, et pas comme une matraque pour affaiblir ceux qui voudraient légitimement construire quelque chose de mieux ou améliorer ce qui existe déjà. De ma propre expérience, malheureusement, c’est plus souvent ce dernier cas que le premier.

Donc, non, vous ne devriez pas réinventer la roue. À moins que vous ne prévoyiez d’en savoir plus sur les roues.

Les métiers du Web nécessitent un constant réapprentissage (« Les bonnes pratiques d’aujourd’hui seront les mauvaises pratiques de demain », disais-je il y a quatre ans). Réinventer la roue, c’est aussi une façon de s’assurer de rester dans la course plutôt que de regarder la roue tourner.

Vu sur Hacker News, le concept de « dette d’idées » présenté par Jessica Abel.

La dette d’idées est quand vous passez trop de temps à vous représenter à quoi un projet va ressembler, trop de temps à penser à quel point ça va être génial de l’avoir terminé et livré au monde entier, trop de temps à imaginer à quel point vous aurez l’air cool, à quel point tout le monde va vous demander, combien d’argent vous allez vous faire. Et beaucoup trop peu de temps à faire le projet.

C’est tout moi, ça. J’ai des tas d’idées de projets, d’articles, de choses vers lesquelles j’aimerais me lancer. Mais je passe une bonne partie de mon temps à rêvasser et imaginer les suites de ces idées une fois lancées plutôt que n’en réaliser ne serait-ce qu’une seule.

Parfois même, j’en parle à des gens, peut-être en espérant avoir des retours me motivant davantage. Je me suis rendu compte après ma conférence à Paris Web en 2014 que j’avais déjà parlé de l’idée de cette conférence à quelqu’un en 2012. C’est dans ce cas plutôt satisfaisant de se rendre compte qu’on a réussi à passer à l’action, même s’il a fallu du temps.

Et j’aime vraiment l’écho que l’expression « dette d’idées » fait à l’expression de « dette technique ». La façon dont je vois les choses, la dette technique nous freine dans le présent à cause du passé. La dette d’idées nous freine dans le présent à cause du futur.

Aujourd’hui, Brendan Eich (co-fondateur de Mozilla et créateur de JavaScript) a présenté sa nouvelle société et un nouveau navigateur basé sur Chromium : Brave. Et j’ai tiqué en lisant une partie de son annonce.

Tout le monde parle du blocage de publicité. Les bloqueurs peuvent rendre l’expérience utilisateur du Web bien meilleure. Mais comme l’a noté Marco Arment, ça ne semble pas juste pour de nombreuses personnes. C’est comme du parasitisme, ou même comme le début d’une guerre. Vous ne cliquez peut-être jamais sur une publicité, mais même réaliser l’affichage d’une publicité peut avoir une petite valeur. Avec suffisamment de personnes qui bloquent des publicités, le modèle de financement principal du Web est en péril.

Selon moi, la publicité n’est pas le modèle économique du Web. À vrai dire, je pense que le Web n’a pas de modèle économique. Dire que la publicité est le modèle économique du Web, c’est comme dire que la prostitution est le modèle économique de l’Amour.

Cependant, certaines sociétés ont effectivement fait le choix de la publicité comme principal modèle économique sur le Web. C’est le cas notamment de certains sites de presse, dont le financement tient désormais à un énième article sur Nabilla, Apple, ou je ne sais quel sujet qui va pouvoir générer un maximum de pages vues. D’autres ont toutefois eu le courage de dire merde à la pub.

Ça va faire près de vingt ans que j’ai accès au Web. Et quasiment autant de temps que j’écris, partage, et publie gratuitement du contenu en ligne. Je n’ai pas vraiment de modèle économique dans tout ça. Je le fais parce que ça me plaît. Je le fais parce que j’apprends du retour des autres. Je m’enrichis, mais pas financièrement. Et ça vaut largement la quarantaine d’euros annuelle en hébergement que me coûte ce présent blog.

Et je crois que depuis le début, ce qui m’a toujours plu dans le Web, c’est de lire le blog de monsieur et madame tout le monde. De lire une page écrite par quelqu’un il y a des années. C’est ce « petit tricot universel », comme le dit si bien Marie Guillaumet, auquel chacun peut participer, que ce soit à travers un tweet, un article, une vidéo, une chanson…

Je fais le rapprochement de tout ça avec ce dernier article de Mike Monteiro sur les quinze ans de Wikipedia.

Un bourdon ne peut pas voler.

On m’a énoncé ce fait par les soeurs de Saint Joseph en grandissant à l’école catholique. Comme de nombreux autres enfants. C’est dit comme un témoignage de Dieu au dessus de la science. Selon l’histoire, les scientifiques et experts en aérodynamisme se sont rassemblés, ont fait des calculs et ont réalisé qu’avec sa masse et son envergure, un bourdon n’était pas capable de générer la poussée nécessaire pour s’élever. En d’autres termes : un bourdon ne peut pas voler. Il est trop gros et ses ailes sont trop petites.

Wikipedia ne peut pas exister.

Une collection du savoir humain. Rassemblée par les humains. Pour les humains. À travers le monde. De manière décentralisée. Une organisation à but non lucratif auto-policée fondée par la bonté des autres. Impartiale. Et construite sur un wiki. Où chaque décision est infiniment débattue en comité. En d’autres termes: Wikipedia ne peut pas exister. C’est trop ouvert et ça ne rapporte pas d’argent.

Sauf que ça existe. Et ça existe depuis quinze ans. Quinze merveilleuses années d’humains rassemblant l’histoire de tout ce que l’on sait, de sorte à ce que d’autres humains ne l’oublient pas. Quinze ans de gestion de notre mémoire collective. Quinze ans où l’on s’assure que l’on puisse raconter nos propres histoires. Quinze ans où votre voie a autant d’importance que celle d’un autre. Quinze ans où le peuple rassemble l’histoire du peuple. 28% de la planète vivant aujourd’hui n’ont jamais connu un monde sans Wikipedia.

C’est l’histoire de Twitch Plays Pokemon encore et encore.

Il y a une réplique dans Scrubs où le Dr. Cox dit :

Je suis sur pratiquement sûr que si on enlevait tout le porno sur internet, il ne resterait plus qu’un seul site web, et il s’appellerait « Qu’on nous ramène le porno ! ».

Je suis pratiquement sûr que si on enlevait toute la publicité du Web, il resterait plein de sites très bien.

Lu en fin d’année dernière sur le Wall Street Journal :

M. Forrest, un manager chez Freebirds World Burrito à Thousand Oaks, en Californie, était en train de couper de la viande quand le minuteur de sa montre a commencé à vibrer et sonner. Avec ses mains recouvertes de jus de viande, M. Forrest a flairé une solution :il a arrêté l’alarme avec son nez.

« Ça marche vraiment », déclare M. Forrest. « Parfois il faut faire ce qu’il faut. »

L’illustration de l’article est vraiment chouette.

Lu sur le New York Times, « A Quick Puzzle to Test Your Problem Solving », un article interactif sur le biais de confirmation (qui reprend un exemple que j’avais lu il y a quelques mois sur le blog de DrLoser).

Un petit jeu permet de comprendre la politique gouvernementale, l’Amérique des entreprises, et pourquoi personne n’aime avoir tort.

Voici comment ça fonctionne :
Nous avons choisi une règle que certaines suites de trois chiffres respectent, et d’autres pas. Le but est de trouver quelle est la règle.

Nous commencerons par vous dire que la séquence 2, 4, 8 respecte cette règle.

Maintenant c’est à votre tour.

J’adore la façon dont le New York Times a rendu cet article interactif et dynamique avec un formulaire en tout début et les résultats intégrés dans une phrase un peu plus loin.

Ces explications dans le reste de l’article m’interpellent.

Ce puzzle met en avant une sorte particulière de biais de confirmation qui hante les entreprises, gouvernements et individus chaque jour :la tendance du yes-man (et yes-woman). Il est plus probable que nous pensions à des situations positives que négatives, à pourquoi quelque chose pourrait bien se passer plutôt que mal, et à des questions dont la réponse est oui plutôt que non.

Parfois, la réticence à penser négativement n’a rien à voir avec des opinions politiques ou une peur consciente de s’entendre dire « non ». Souvent, les gens ne pensent même pas à poser des questions qui pourraient produire une réponse négative en cherchant à résoudre un problème — comme celle-ci. Au lieu de ça, ils réduisent l’univers possible de questions à celles qui pourraient potentiellement produire un « oui ».

C’est ma hantise en tant que concepteur web : m’assurer que je pose les bonnes questions, et surtout ne pas me satisfaire de voir un client acquiescer à mes propositions.

La dernière conférence de Maciej Cegłowski, « The Website Obesity Crisis », est pleine de citation et d’exemples bons à partager.

Voici un article didactique sur les bonnes pratiques pour augmenter sa performance en ligne qui pèse 3,1 Mo.

Cet article mentionne que Google était capable d’augmenter l’engagement utilisateur dans Google Maps en réduisant le poids des pages de 100 Ko à 80 Ko.

Vous vous souvenez quand Google Maps, la web app la plus sophistiquée de son époque, était trente-cinq fois plus petite qu’un article d’actualité moderne ?

Ou encore :

Les gens ont inventé des mesures créatives pour se persuader que leurs sites mélasses se chargent vite.

Google en a une populaire appelée SpeedIndex. (Vous savez que ça vient de Google quand ils balancent une intégrale dans la définition comme si de rien n’était.)

Mais surtout, j’adore sa pyramide alimentaire du Web.

Les nutritionnistes étaient à fond sur ce concept de pyramide alimentaire. Je pense qu’on a besoin d’une pour le web, pour se rappeler ce à quoi un site sain devrait ressembler.

Voici ce que je recommande pour un site équilibré en 2015 :

• Une base solide de texte qui vaille la peine d’être lu, formaté avec une bonne dose de balises.
• Quelques images, avec modération, pour illustrer le design visuel.
• Un gros morceau de CSS.
• Et puis, avec parcimonie et seulement si besoin, du JavaScript.

Je suis tombé hier soir via reddit sur ce fantastique compte-rendu d’une conférence de Fred Hébert, « The Little Printf ». C’est beau, c’est poétique, et ça énonce assez joliment des vérités sur les différentes facettes du métier de développeur. Je pourrais citer l’histoire dans son intégralité. Mais voici mes deux extraits favoris.

Quand (chapitre 7), le Petit Printf rencontre un développeur super fier de connaître tous les derniers frameworks à la mode :

— Quels problèmes est-ce que tu résous avec tous ces frameworks ?

— Oh, je m’assure que nous n’utilisons pas quelque chose qui ne va pas avoir du succès, comme ça cette société ne parie pas sur des technologies qui n’ont pas d’avenir. C’est un travail très important, car si tu ne fais pas ça, tu ne pourras trouver personne à embaucher à part des vieux barbus grisonnants en retard, alors que tu veux des fonceurs autonomes qui sont aussi des adopteurs précoces, dit le monsieur.

— C’est amusant, répondit notre ami.

— C’est très difficile ! Dans le monde des startups, si tu veux les meilleurs joueurs, tu dois utiliser les bonnes technologies pour les attirer ! Sinon tu restes coincé avec des retardataires rigides. Personne ne veut être un retardataire rigide.

Le Petit Printf s’exclama : « Non, ce n’est pas ce que je voulais dire », et puis il ajouta « Je trouve ça amusant que les outils sont censés résoudre des problèmes pour nous, mais pour toi, les outils eux-mêmes sont devenus un problème. »

Et pendant que l’homme resta là en silence (sur son nouveau bureau trop cool avec tapis de course), le Petit Printf sauta hors de la pièce.

Chapitre 10, le Petit Printf rencontre un architecte logiciel.

— Ton système est très impressionnant. Est-ce qu’il est rapide ?

— Je ne saurais pas te dire, dit l’architecte. Il devrait, cependant.

— Et comment est le code alors, est-ce qu’il est bon ?

— Je ne saurais pas te dire.

— Est-ce que les utilisateurs en sont contents ?

— Je ne pourrais pas te dire non plus, j’en ai bien peur.

— Mais tu es un architecte logiciel !

— Exactement ! Mais je ne suis pas un développeur. Ce n’est pas l’architecte qui va écrire les modules et les classes, assembler les bibliothèques. L’architecte logiciel est bien trop important pour faire le tour et toucher du code. Mais il parle avec les programmeurs et développeurs, leur pose des questions, leur fournit des conseils. Et si le problème a l’air suffisamment intéressant, l’architecte prend en charge le planning.

— Et pourquoi ça ?

— Parce que nous avons plus d’expérience. Nous en savons plus sur les systèmes et ce qui fonctionne et ce qui ne fonctionne pas. Les développeurs peuvent être une extension de notre savoir pour produire des bons systèmes !

— Mais comment sais-tu si les choses se passent bien sans jamais être impliqué dans le code ?

— Nous faisons confiance aux développeurs.

— Donc vous leur faites confiance pour implémenter vos idées correctement, mais pas assez pour qu’ils trouvent leurs propres idées ?

L’architecte logiciel était visiblement secoué par ce commentaire. « Je suppose que j’ai été un peu déconnecté, admet-il finalement. Le problème est qu’au bout d’un moment, on vous demande tellement de travailler sur des idées que vous n’avez plus de bon moyen de les faire tester ou vérifier. » Il fixa le sol, pensif. «Parfois un architecte logiciel ne fait ni de l’architecture, ni du logiciel, il semblerait.»

Le Petit Printf quitta la pièce, et achevant ainsi sa visite, quitte le bâtiment.

Cette histoire est géniale et vous devriez la lire.

Samedi dernier, j’ai eu la chance de participer à l’atelier « Tester l’accessibilité de son site Web avec NVDA » présenté par Denis Boudreau à Paris Web. Après une présentation très intéressante (où j’ai appris notamment qu’il y avait 39 000 000 de non-voyants dans le monde, mais seulement 22 000 utilisateurs de NVDA), les participants ont été invités à faire des tests à l’aide d’un lecteur d’écran sur le site de la Fnac par petits groupes. Je me suis donc retrouvé à faire la connaissance de @ouik_web et @joellechong avec qui nous avons testés les formulaires de la création de compte du site. N’ayant pas de PC sous la main, nous avons fait des tests avec VoiceOver sous OS X. Et j’ai trouvé nos trouvailles particulièrement intéressantes. En voici un compte-rendu.

Afin de créer un compte, nous avons sélectionné le lien « Me connecter » du header du site. Celui-ci ouvre un sous-menu qui contient un lien « Créer mon compte ». En cliquant sur ce lien, on arrive sur la page suivante.

• Le premier point surprenant, c’est que cette page contient également un formulaire d’identification (alors que je viens pourtant explicitement de cliquer sur un lien « Créer mon compte »). Et le problème, c’est que cette colonne d’identification se trouve en premier dans le code HTML. Avec un lecteur d’écran, on doit donc traverser toute cette zone avant d’atteindre le formulaire de création de compte qui nous intéresse.
• Les étoiles après les libellés de chaque champ n’ont pas de libellés correspondants. En fait, même pour un utilisateur voyant, nulle part sur le reste de la page il n’y a d’indication de ce que à quoi correspondent ces étoiles. Est-ce que ce sont les champs obligatoires ? Est-ce que ce sont les champs facultatifs ?
• Le lien « oublié ? » après le libellé « Mot de passe* » n’est pas très explicite. Si on navigue sur la page avec la touche tabulation, on tombe directement sur ce lien sans avoir aucune idée qu’il concerne le mot de passe.
• Le champ d’adresse e-mail utilise un <input type="text" /> plutôt qu’un <input type="email" />. L’avantage, c’est qu’un lecteur d’écran pour restituer cette précision sur le type de contenu attendu, et c’est une aide précieuse sur des formulaires. La version mobile de la création de compte de la Fnac utilise bien un champ <input type="email" />.
• La balise <title> de la page est vide. Dans ce cas, quand on prends le focus sur la fenêtre, VoiceOver va lire l’URL de la page. Je vous laisse imaginer l’horreur d’entendre https://secure.fnac.com/Account/Logon/Logon.aspx?LogonType=StandardCreation&PageAuth=X&pagepar=LogonType%3dStandardCreation%26PageRedir%3dhttp%253a%252f%252fwww4.fnac.com%252f&PageRedir=https%3a%2f%2fsecure.fnac.com%2fAccount%2fProfil%2fAccountInfos.aspx.
• Avant le formulaire de création de compte, il y a un petit texte d’introduction « Bonjour cher inconnu, on ne se connait pas encore. Aucun problème, continuez c’est tout droit. » Les deux phrases sont chacune sur une ligne. Sauf qu’il n’y a pas de point à la fin de la première. VoiceOver lit donc les deux phrases d’une seule traite. C’est le genre de détails presque insignifiant visuellement, mais assez pénible quand on utilise un lecteur d’écran.
• Sous le champ « Mot de passe », il y a une indication « 8 caracètres minimum dont au moins 1 chiffre et 1 lettre ». J’ai bien dit « caracètres ». C’est encore une fois une faute à côté de laquelle on peut facilement passer visuellement, mais qui saute aux oreilles en utilisant un lecteur d’écran.
• Lorsqu’on valide le formulaire mais qu’il y a des erreurs, la page se recharge complètement, et on se retrouve à devoir renaviguer à travers toute la page. C’est assez déroutant, et un focus sur le message d’erreur aurait été le bienvenu.

Une fois ce formulaire dûment complété, on arrive sur la deuxième étape suivante.

On y retrouve plus ou moins les mêmes écueils, mais avec quelques suppléments :

• Les titres « Mon compte » et « Vos données personnelles : identifiez-vous » sont tous les deux dans des balises <h2>. Il n’y a aucun titre de niveau <h1> sur la page. À l’écoute, on a l’impression de passer d’une section à une autre, plutôt que de rentrer dans le coeur de la page.
• Les diminutifs de civilité « Mlle », « Mme » et « M » n’ont pas d’alternatives complètes. VoiceOver lit donc littéralement « Mleu », « AimeAimeEuh », et « Aime ».
• Les <label> des champs Nom, Prénom et « Combien avez-vous d’enfants ? » ont bien un attribut for, mais celui-ci est vide. Quand on arrive dans ces champs, on n’a donc aucune idée d’où est-ce qu’on est. De la même manière, les deux listes déroulantes et le champ texte pour la date de naissance n’ont aucun label associés. On navigue donc de l’un à l’autre sans trop savoir où l’on est.

Et tout ça, ça ne concerne que les formulaires de la création de compte du site. Les autres groupes participant à cet atelier se sont concentrés sur d’autres points (textes, images, …) et ont répertorié tout autant de retours sur l’accessibilité du site. (J’ai surtout retenu que le lien « Mon panier » du header est totalement inaccessible, que ce soit en naviguant au clavier ou pour un lecteur d’écran, car il ne s’agit pas d’une balise <a> mais d’un ensemble de <div> dont le comportement est géré en JavaScript.)

Alors je ne cherche pas ici à jeter la pierre aux équipes responsables du site de la Fnac. Mais ce qui me fascine, c’est la facilité avec laquelle nous avons pu identifier des problèmes d’accessibilité importants, en quelques dizaines de minutes de tests, avec des outils à la portée de tout le monde. Je suis un adepte de la maxime « Si vous voyez quelque chose, dites quelque chose ». Et ça me chagrine de lire des tweets comme celui-ci. Alors j’espère que ces quelques retours ne tomberont pas dans l’oreille d’un sourd, et que la Fnac pourra mettre les moyens nécessaires pour améliorer l’accessibilité de son site.

 

Je l’ai tweetée le mois dernier, mais cette conférence m’est vraiment restée en tête. Une excellente présentation, tant sur le fond que la forme, sur l’appréhension de parler en public.

On m’a fait remarqué à deux reprises hier que ça faisait un petit moment que je n’avais rien posté ici depuis un moment. C’est en partie parce que j’étais tout récemment aux chouettes conférences de Paris Web ou que j’organise la nouvelle édition de 24 jours de web. Mais aussi parce que j’ai consacré un peu plus de temps ces derniers mois à écrire sur mon blog consacré à l’intégration d’e-mails (notamment pour expliquer comment j’ai créé un e-mail qui se transforme en le transférant). Et je suis toujours bien vivant sur Twitter. Il faut juste que je trouve un peu plus de temps pour écrire sur ce blog sur pleins de sujets qui me restent en tête depuis un moment.

J’aime bien James Victore. Et dans cette conférence du mois dernier, j’aime particulièrement cette réponse (à 7:07) face à un argument que j’entends ou prononce parfois trop souvent :

Je donnais une conférence il y a quelques années. Il y avait des questions/réponses à la fin. Et j’étais particulièrement déchaîné ce jour là. Je parlais des gens assumant et défendant leur créativité. Et puis un jeune a levé la main dans le fond.

— J’ai une question ! M. Victore, j’entends bien ce que vous dites. Mais j’ai un loyer à payer.
— C’est une histoire intéressante. Comment tu t’appelles ?
— Thomas…
— Thomas. Voici ta pierre tombale : « Ci-gît Thomas. Il aurait fait du super travail, mais il avait un loyer à payer. »

On laisse nos situations s’imposer. Vous avez besoin d’une révolution. Thomas a besoin d’une révolution. Il n’avait probablement que trente ans et il avait déjà abandonné. Il était déjà abattu.

Voici une autre pierre tombale. « Ci-gît Thomas. Il aurait fait du super travail, mais son patron ne le laissait pas faire. »

Il y a quelques semaines, j’ai tweeté un excellent article de la série « Dear Design Students » sur les développeurs et les designers. L’une des dernières phrases m’est particulièrement restée en tête :

Tout le monde pense que la personne en aval (plus proche de l’échéance) est un bloqueur, et tout le monde pense que la personne en amont est un trou du cul.

Ça m’a rappelé un sketch de George Carlin, « Idiot and maniac » :

Avez-vous déjà remarqué quand vous conduisez que n’importe qui roulant moins vite que vous est un imbécile, et n’importe qui roulant plus vite que vous est un cinglé.

Cette semaine est sorti Her Story, un jeu iOS, PC et Mac rappelant la grande époque des FMV. Vous avez accès à une base de données vous permettant de visualiser des vidéos d’interrogatoires d’une femme. Le but est de comprendre son histoire. Vous saisissez un mot, et vous pouvez visualiser les cinq premières vidéos où ce mot est prononcé. À aucun moment on ne vous dira si vous êtes sur la bonne voie ou pas. J’adore la simplicité du concept. Et même si j’étais un peu perdu au tout début, je me suis vite pris au jeu. Et j’ai trouvé que c’était une formidable manière de raconter une histoire. Mon seul reproche est que j’ai eu l’impression d’avoir compris le gros de l’histoire en moins d’une heure.

En février dernier, Aaron Gustafson expliquait sur son blog que les variables CSS sont une mauvaise idée. Ses principaux arguments sont que le support est pour l’instant mauvais et que la syntaxe est atroce. Et il n’a pas totalement tort. Les variables CSS ne fonctionnent pour le moment que sur Firefox. Et voici à quoi ressemble la déclaration et l’utilisation d’une variable en CSS.

body {
	--main-color: #333;
}

h1 {
	color: var(--main-color);
}

Si vous êtes habitué à la syntaxe habituelle des pré-processeurs, c’est sûr que la syntaxe à base de double tirets et la fonction var() sont plutôt rebutantes. Et pourtant, ces derniers mois, je suis tombé sur plusieurs intégrations qui m’ont fait dire à chaque fois : vivement les variables CSS !

Lire la suite de « Vivement les variables CSS ! »

La série d’articles « Dear Design Student » de Mule Design Studio est vraiment intéressante. Le dernier article en date, « Working  With Aluminium », l’est encore plus :

N’importe quelle discipline de design a une composante technique. Les designers graphiques ont besoin de l’imprimerie, les designers industriels ont besoin d’ingénierie, et les designers numériques ont besoin de code. Les designs élégants et efficaces prennent en compte les propriétés et limites de leurs matériaux. Les designers qui font de l’excellent travail étudient leurs matériaux pour comprendre les contraintes auxquelles ils répondent.

Allez regarder une vidéo de Jony Ive qui parle d’aluminium. Il adore clairement ce truc. Il a passé des heures à y penser et à expérimenter avec. Je parie que certains soirs il rentre chez lui et fait tomber des copeaux de métal en secouant son t-shirt. Personne ne lui dit que son enthousiasme pour la métallurgie implique qu’il devrait enfiler une combinaison et opérer un routeur CNC à l’usine. Il apprend ce qu’il doit apprendre pour obtenir le maximum de ses matériaux, et la qualité de son travail reflète ce soin et cette attention.

Cela devrait être votre attitude vis à vis du code en tant que designer. Apprenez tout ce que vous pouvez, et appliquez le constamment dans le but d’améliorer vos designs. Vous ne devez pas être un développeur pour y trouver un intérêt et y acquérir en compétences. Parfois avoir suffisamment de connaissances pour poser les bonnes questions est tout ce dont vous avez besoin. C’est votre responsabilité d’être impliqué dans la globalité du processus de design par tous les moyens possibles.