Les articles du mois de mars 2012

Lu chez plasmasturm, repris lui même d’ailleurs : Les 6 étapes du débogage.

1. Ça ne peut pas arriver.
2. Chez moi ça marche.
3. Ça ne devrait pas arriver.
4. Pourquoi est-ce que ça arrive ?
5. Oh, je vois.
6. Comment est-ce que ça a pu marcher ?

S’il y a un livre qui a profondément changé ma compréhension du monde et la façon dont je conçois des sites Internet, c’est très certainement « The Design of Everyday Things » de Donald Norman. Le livre traite de la conception des objets de la vie de tous les jours, d’ergonomie et de facilité d’utilisation, avec pleins d’anecdotes et d’exemples comme je les aime. Dans les premiers chapitres du livre, l’auteur prends l’exemple des portes. Cet exemple est devenu tellement célèbre qu’il est désormais courant de désigner une porte mal conçue comme une « porte de Norman ».

Quand nous approchons une porte, nous devons trouver le côté qui s’ouvre et l’endroit à manipuler. En d’autres termes, nous devons arriver à comprendre ce que l’on doit faire et où le faire. Nous nous attendons à trouver un signal visible pour réaliser la bonne manipulation : une plaque, une prolongation, un creux, un renfoncement – quelque chose qui permette à la main de toucher, saisir, tourner ou s’insérer. Ceci nous dit où agir. L’étape suivante est de comprendre comment : nous devons déterminer quelles opérations sont permises, en partie en se basant sur l’affordance, en partie guidés par les contraintes.

Il y a une variété incroyable de portes. Certaines ne s’ouvrent que si un bouton est appuyé, et certaines ne semblent pas s’ouvrir du tout, n’ayant aucun bouton, aucun matériel, ni aucun autre signe de leur fonctionnement. La porte s’ouvre peut être à l’aide d’une pédale. Ou peut être qu’elle est activée par une commande vocale, et que nous devons prononcer la phrase magique (« Sésame ouvre toi !« ). En outre, certaines portes ont des étiquettes sur elles : tirez, poussez, glissez, portez, sonnez, insérez votre carte, entrez votre mot de passe, souriez, tournez, saluez, dansez, ou peut-être juste, demandez. D’une manière ou d’une autre, quand un appareil aussi simple qu’une porte doit être utilisé avec un manuel d’utilisation – même s’il s’agit d’un manuel d’un seul mot – alors c’est un échec, mal conçu.

Je pense que c’est tout aussi valable pour le web. Si vous devez expliquer à l’internaute comment se servir de votre page, même avec une simple phrase, vous avez raté votre travail.

Que vous soyez graphiste, développeur ou chef de projets, je vous recommande vraiment très chaudement la lecture de « The Design of Everyday Things« . Le livre, bien que datant de 1988, n’a jamais été traduit en français. Mais même en étant très précis et très détaillé, il se lit relativement facilement et se divise en pleins de sections assez courtes et souvent illustrées. Et il ne coûte que 10€ chez Amazon (et si vous utilisez ce lien, vous contribuerez à mon bien être personnel).

Dans la même veine, cette galerie de photos de panneaux sur des panneaux créée par Jason Fried me fait toujours autant sourire.

Le piratage n’existe pas parce qu’il y a des mauvaises personnes ici et là qui sont des voleurs et/ou qui détestent le capitalisme et/ou se sentent dans leur droit. Bien sur, il y a des mauvaises pousses, mais ce sont les exceptions, pas la règle. Le piratage existe parce que c’est souvent un moyen plus facile d’obtenir du contenu que les moyens légaux. Et parfois, c’est le seul moyen.

MG Siegler, dans son très bon article « Winter And The Wall » (repartant du même exemple de l’offre légale inexistante pour la série Game Of Thrones, déjà brillamment illustré il y a quelques semaines chez l’excellent The Oatmeal).

Depuis un petit moment, je n’arrête pas d’entendre parler de pré-processeurs CSS, comme Sass, LESS, ou Stylus. Ces outils ajoutent de nouvelles fonctionnalités à vos CSS (comme des variables, des fonctions ou des snippets) en générant votre code côté serveur. Parfois ça donne un peu envie, mais la plupart du temps vraiment pas (voire pire encore).

Lea Verou résume parfaitement mes appréhensions sur ce genre d’outils :

• Les pré-processeurs faussent notre perception de la taille finale d’une feuille de style, et ça peut être difficile d’optimiser correctement le tout
• Les pré-processeurs rendent plus difficile la routine classique de débuggage, où les numéros de lignes visibles dans Firebug (ou équivalent) ne correspondent pas à votre CSS
• L’utilisation de pré-processeurs en équipe nécessite que toute l’équipe maîtrise l’outil
• Les fonctionnalités apportées par les pré-processeurs finiront par arriver dans les spécifications officielles de CSS (c’est déjà le cas pour les variables). Comme le dit Lea, « coder pour un pré-processeur CSS aujourd’hui c’est un peu comme construire un chateau de sable ».

Ceci dit, je n’ai jamais utilisé de pré-processeur CSS. Il est donc possible qu’avec certains d’entre eux, mes craintes ne soient pas justifiées. Pour autant, j’ai énormément de mal à me pencher sur ce sujet et m’y intéresser réellement. Peut-être parce que je suis un vieil intégrateur. Mais peut être aussi parce que j’ai tendance à préférer les choses simples.

Il y a quelques mois, j’étais tombé sur « The MicroPHP Manifesto« , un excellent article dans lequel un développeur PHP revendique son amour pour coder en PHP, sans frameworks. La comparaison donnée dans son introduction est pile poil comme je les aime :

La ligne standard de l’histoire du Punk est qu’il s’agissait d’une réaction aux excès du rock moderne, en particulier le rock progressif de l’époque. La réalité est indéniablement plus compliquée, mais je suspecte qu’il y a en ça une part de vérité. Le rock’n’roll semblait être dans son âge d’or à la fin des années 60s et 70s, inaccessible pour le grand public. Le contraste entre des groupes comme Rush et Black Flag, tous les deux supposés jouer du « rock », était extrême.

Pour rigoler, regardons la batterie du batteur de Rush Neil Peart :

Et maintenant, voici les Black Flag en train de jouer à Los Angeles en 1979 :

Vous pouvez faire tenir la totalité de Black Flag dans l’espace de la batterie de Neil Peart. Et ils joueraient quand même de manière impressionante et déchireraient tout.

Cet exemple colle parfaitement à l’utilisation de pré-processeurs en CSS. Dans l’absolu, CSS est un langage simple à utiliser. Vous n’avez pas besoin d’un compilateur. Vous n’avez pas besoin d’un éditeur particulier. Vous pouvez aller sur n’importe quel ordinateur, coder dans le bloc-notes, et faire des sites « qui déchirent ». Pour moi, une CSS doit être agnostique de tout éditeur et de tout autre langage.

Le manifeste du micro PHP cité ci-dessus s’applique alors parfaitement ici. Et si je devais résumer ma pensée en une phrase, je détournerais le fameux dicton pour donner le manifeste du CSS pur et dur suivant :

Ce qui se passe en CSS, reste en CSS.

Je déteste l’expression « surfer sur Internet ». Je ne surfe pas. Je suis assis comme un gros porc au fond de ma chaise en train de fixer un écran d’ordinateur. Je n’ai jamais fait de surf, mais je pense que ça n’a pas grand chose à voir. J’ai toujours imaginé que le terme venait d’un fournisseur d’accès ou d’une grosse boîte de com’ des années 90 qui a voulu rendre le web super cool. Mais sur le web français, les réponses sont plutôt évasives quand on cherche d’où vient l’expression. Voici par exemple l’explication de Wikipedia :

L’expression surfer sur le Web signifie « consulter le Web ». Elle a été inventée pour mettre l’accent sur le fait que consulter le Web consiste à suivre de nombreux hyperliens de page en page.

Okay. Il va falloir m’expliquer le rapport entre suivre des liens de pages en pages et des grands blonds musclés qui glissent sur des grandes vagues en Californie.

Heureusement, une petite recherche en anglais nous amène droit à la réponse. La première personne associée à l’utilisation de cette expression est Jean Armour Polly, une bibliothécaire et auteur américaine. En juin 1992, elle publie dans le bulletin de la bibliothèque de l’Université du Minnesota un article intitulé « Surfing the internet« . Sur son site personnel, elle raconte comment lui est venue l’idée de cette expression.

J’étais sous contrat avec le Wilson Library Bulletin pour écrire un article adressé aux débutants à propos d’Internet, à soumettre au journal en mars 1992. L’article a été imprimé dans l’édition de juin 1992.

En écrivant cet article, je savais que ce serait un des premiers du genre. « Zen and the Art of the Internet » était publié sur le net par Brendan Kehoe en janvier 1992, et c’était devenu un phénomène du net à petite échelle. Jusque-là il n’y avait que des RFCs (Requests for Comments) et d’autres écrits techniques à propos d’Internet. L’article de Kehoe innova pour les nouveaux utilisateurs universitaires, et j’étais décidée à faire la même chose pour les bibliothécaires.

En cherchant un titre pour l’article, j’évaluais plein de métaphores possibles. Je voulais quelque chose qui exprimait le plaisir que j’avais à aller sur Internet, tout en évoquant la compétence et l’endurance nécessaire pour bien l’utiliser. J’avais aussi besoin de quelque chose qui évoque un sens de l’aléatoire, du chaos et même du danger. Je voulais quelque chose qui fasse mouche, qui fasse mordre à l’hameçon, quelque chose de nautique.

A cette époque j’utilisais un tapis de souris de la bibliothèque d’Apple à Cupertino, en Californie, célèbre pour inventer et s’approprier des expressions savoureuses et les faire imprimer sur des survêtements et des tapis de souris (par exemple, « Un mois au laboratoire peut vous éviter une heure à la bibliothèque »). Celui que j’avais présentais un surfeur sur une grande vague. « Surfeur de l’information », ça disait. « Eureka », me suis-je dis. Et j’avais ma métaphore.