HTeuMeuLeu

L’excellent Jeff Atwood (de Stack Overflow) a rassemblé sur son blog quelques exemples de jargon de développeurs, ces expressions inventées qui collent parfaitement à une situation souvent rencontrée en développement. J’avais déjà twitté un article basé sur le même sujet il y a 2 ans, et j’aime bien découvrir de nouvelles expressions de ce type.

Voici mes cinq préférées.

1) Les conditions de Yoda

Utiliser if(constant == variable) au lieu de if(variable == constant), comme par exemple if(4 == foo). C’est comme dire « si bleu est le ciel » ou « si grand est le monsieur ».

2) Les accolades égyptiennes

Désignent des accolades écrites avec l’accolade ouvrante sur la même ligne que le bloc d’instruction, comme ceci :
if (a == b) {
alert("hello");
}


3) Bugfoot

Un bug qu’une seule personne a vu, et qui n’a jamais été revu depuis.

4) Moustache

Vu chez apgwoz, la moustache est tout simplement un petit nom pour désigner une accolade.

5) Bébé ours, Maman ours et Papa ours

Vu chez CSS-Tricks, c’est une autre façon de nommer les versions responsives d’un site.

// Papa ours
@media (max-width: 1600px) { }
// Maman ours
@media (max-width: 1250px) { }
// Bébé ours
@media (max-width: 650px) { }

Le week-end dernier, le Wall Street Journal annonçait que Digg allait être racheté par le groupe betaworks pour 500 000$. À peine 2 ou 3 ans plus tôt, le site était estimé à plus de 160 millions de dollars.

Avant cette annonce, j’avais complètement oublié Digg. Pourtant, entre 2006 et 2010, j’étais un gros visiteur de Digg. Je ne postais pas, mais j’adorais venir sur le site tous les jours et découvrir du nouveau contenu. C’était probablement le premier réseau social pour lequel j’avais un réel engouement. Avec cette annonce, des tas de souvenirs me sont remontés d’un seul coup.

Son fondateur, Kevin Rose, et ses shows à l’Américaine. MrBabyMan, le membre du site le plus actif dont le moindre post atteignait la page d’accueil. L’histoire de 09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0. Et puis en 2010, il y a eu la V4, ses plantages fréquents, son algorithme modifié pour pousser davantage de contenus promotionnels, la DiggBar, et la fuite d’une très grande partie de ses utilisateurs vers Reddit.

Et puis des souvenirs encore plus anciens me sont remontés. En 2003, j’avais regardé la première « émission » de Kevin Rose sur le hacking et le social engineering : The Broken. Et je me souvenais particulièrement de la séquence Hacking with Ramzi :

http://www.youtube.com/watch?v=fDFXaqDf8kk

Le rachat de Digg aurait pu me laisser totalement indifférent. Sauf qu’hier, la nouvelle équipe du site chez betaworks a présenté son projet : Rethink Digg.

Comme l’ont annoncé betaworks et Digg sur leurs blogs, nous allons prendre le contrôle de Digg et en refaire à nouveau une startup. Ce qu’ils n’ont pas mentionné, c’est que nous allons le reconstruire de zéro. En six semaines.

Le 1er août, après six semaines pleines de caféine et d’adrénaline, nous allons sortir une nouvelle v1.

Je suis sceptique, mais j’ai hâte de voir ce que ça va donner.

Vous connaissez cette sensation lorsque vous répétez un mot tellement de fois à la suite qu’il finit par perdre tout son sens et devenir incompréhensible ? C’est une sentation qu’on appelle la satiété sémantique :

La satiété sémantique arrive brusquement, quand votre langue trébuche sur chaque syllabe, le mot n’étant plus qu’un assemblage hétéroclite de lettres dénué de toute signification. Il faut alors quelques secondes – parfois même quelques minutes – pour désinhiber notre cerveau et lui faire admettre à nouveau que « placard » n’est pas un néologisme ! À lui seul, le terme de satiété sémantique explique parfaitement le concept : on n’a littéralement « plus faim du sens », notre cerveau est rassasié du contenu.

Récemment, j’ai eu le même sentiment en travaillant sur l’intégration d’un champs de recherche, et en regardant l’icône de loupe utilisée. La maquette ne présente pas de problèmes en elle-même. Mais au bout d’un certain temps, mon cerveau a complètement perdu le sens de la loupe.

« C’est bizarre », me suis-je dit. « Je n’ai jamais utilisé de loupe de ma vie pour chercher quelque chose. Une loupe, ça permets de voir des détails. C’est l’icône idéale pour un bouton de zoom. Mais pas pour une recherche. C’est quand même bizarre d’utiliser exactement le même symbole, la même icône, la même métaphore, pour deux fonctions totalement différentes. »

Totalement écervelé, je suis allé bêtement poser la question sur StackExchange, en cherchant à retrouver l’origine de l’utilisation d’une icône de loupe comme symbole de recherche. Il se trouve que ça tient principalement à deux clichés.

Le détective cherche des indices avec sa loupe. Le scientifique cherche des détails microscopiques avec sa loupe. Et c’est tout. C’est une sacrément bonne métaphore quand vous n’avez jamais fait ça de votre vie, mais que c’est pourtant bien ancré dans votre inconscient via des lectures, films et séries de votre jeunesse.

D’après les réponses sur StackExchange, un des premiers logiciels à utiliser la loupe comme icône de recherche fut le système d’exploitation NeXT (la boîte lancée par Steve Jobs après son éviction d’Apple), à la fin des années 80.

L’icône fut ensuite reprise dans des produits plus grands publics, comme le Newton d’Apple , les premiers Palm Pilot, puis démocratisée dans Windows 95. Alternativement, la recherche était de temps en temps représentée par des jumelles (comme dans Word), une lampe torche (comme dans Netscape), ou illustrée par un chien (comme dans Windows XP, ou chez Lycos).

Mon cerveau est désormais rassasié, et je peux continuer à travailler tranquillement.

J’ai le sentiment qu’il existe chez certains webdesigners la conviction d’être des artistes, et que les designs de sites web se doivent d’être des chefs d’oeuvres représentatifs de leur art. C’est complètement faux.

Le webdesign n’est pas un art.

Et c’est même tout sauf ça. En mars dernier, Christopher Butler expliquait ça très bien dans son article « Your ego is a bad designer » :

La différence fondamentale entre le design et l’art réside dans ceux pour qui chacun est au service. L’art est au service de l’artiste; c’est un véhicule d’expression de soi. A partir de là, il est au service des autres simplement en existant, en donnant de l’inspiration, en montrant ce qui est possible. Le design, à l’opposé, ne devrait jamais servir le graphiste en premier. Le graphiste rend toujours un service à quelqu’un d’autre. Le design est au service du client, et le processus de servir le client sert au graphiste. Contrairement à l’art, le design n’est pas un véhicule d’expression de soi. (Les designers peuvent s’exprimer à travers leur travail; le bon design n’en a pas besoin.) En d’autres mots, le design ce n’est pas totalement à propos de vous.

Vous pouvez détester autant que voulez les peintures de Picasso, les films de Tarantino ou la musique de Sufjan Stevens, ça n’enlève rien au fait que ce sont des artistes. Leurs oeuvres sont imprégnées de leur personnalité. Vous aimez ou vous n’aimez pas. Vous comprenez ou vous ne comprenez pas. Ça marche bien commercialement ou ça ne marche pas. Peu importe.

Par contre, si vos internautes ne comprennent pas comment fonctionne votre site, s’impatientent devant un formulaire super long à charger parce que vous avez cru bon d’utiliser des listes déroulantes personnalisées, ou bloquent devant des ombres physiquement improbables, ils sont tout à fait en droit de vous haïr personnellement.

Il y a déjà presque 5 ans, Jeffrey Zeldman (le papa de « A List Apart » et des livres « A Book Apart ») expliquait comment « Comprendre le webdesign » :

Le webdesign ce n’est pas le design de livres, ce n’est pas le design de poster, ce n’est pas l’illustration, et les plus grands accomplissements de ces disciplines ne sont pas le but recherché par le webdesign. Bien que certains sites web peuvent être des moyens pour diffuser des jeux et des vidéos, et bien que ces moyens de diffusions peuvent être agréables à regarder, de tels sites sont des exemples du design de jeux et du storytelling vidéo, pas du webdesign. Alors qu’est-ce que le webdesign ?

Le webdesign est la création d’environnements numériques qui facilitent et encouragent l’activité humaine; qui reflètent ou s’adaptent à des voix et des contenus individuels; et changent gracieusement au cours du temps tout en maintenant leur identité.

Répétez ça, en mettant l’accent :

Le webdesign est la création d’environnements numériques qui facilitent et encouragent l’activité humaine; qui reflètent ou s’adaptent à des voix et des contenus individuels; et changent gracieusement au cours du temps tout en maintenant leur identité. 

En juin dernier, l’excellent Benoït Meunier détaillait sur son blog le travail d’un (web) designer :

Votre travail n’est pas toujours aussi cool et amusant que vous pouvez le croire. Il est très souvent clérical. C’est aussi un travail scientifique de recherche, d’analyse. Vous êtes aussi un psychologue qui cherche l’écoute et non le prochain pitch. Vous connaissez aussi tous les recoins du projet par coeur. Vous en connaissez aussi les implications fiscales et l’évolution d’affaires ne vous est pas étrangère.

Votre travail demande aussi de regarder les statistiques, d’évaluer le comportement, de synthétiser des montagnes de données pour permettre une meilleure décision et par la suite, proposer d’enlever un lien, de modifier un titre, de faire des tests sur le meilleur adverbe d’un appel à l’action.

Votre travail c’est aussi ça.

Vous n’êtes pas Don Draper. Vous devez travailler fort, sur quelques pixels parfois pas très sexy mais cruciaux à une bonne expérience.

Vous êtes payé pour cela. Faites-le bien.

J’ai le sentiment qu’en France, la vue du webdesign comme un art est particulièrement accentuée  à cause du titre de « Directeur artistique ». Dans certaines agences web, vous pourrez rencontrer toute une bande de directeur et directrice artistique. Certains sont effectivement des directeurs artistiques, et suivent et dirigent des shoots photos, des conceptions vidéos, etc… Mais certains sont en réalité des webdesigners. Cette simple mention sémantique joue dans l’inconscient des clients et des webdesigners eux-mêmes que le webdesign a un rôle artistique.

Si vous êtes dans ce cas-là, arrêtez de vous appelez directeur artistique. Vous êtes peut être un designer d’Interface Utilisateur, ou alors un Architecte de l’Information. Mais sur le web, vous n’êtes pas un directeur artistique.

Le webdesign n’est pas un art.

De temps en temps, je reçois une maquette avec un formulaire à intégrer qui contient quelque chose comme ça :

Ceci est une liste déroulante personnalisée. C’est vachement pratique pour repérer les webdesigners débutants, les graphistes print qui font du web, ou encore les webdesigners qui pensent que le design est la finalité d’une page web (indice : ce n’est pas le cas).

Si vous êtes intégrateur, vous savez déjà que vous allez devoir faire quelque chose de très sale pour arriver à ce résultat graphique. Les contrôles de formulaires sont par défauts très limités à modifier en CSS. Ceci est dû au fait que ce sont en fait des éléments remplacés par le navigateur par des contrôles propres au système d’exploitation. L’avantage, c’est que le formulaire pourra s’adapter au fonctionnement du système d’exploitation. Par exemple sur iOS, vous aurez droit à la roue du juste prix. L’inconvénient, c’est que vous êtes assez limité au niveau de la présentation.

CSS3 apporte quelques solutions (notamment avec la propriété appearance), mais on est loin d’une solution universelle. La moins pire des solutions à l’heure actuelle consiste à utiliser du JavaScript pour remplacer les contrôles de formulaire par de faux contrôles. La bibliothèque Uniform (en jQuery) fait ça plutôt bien.

Mais ça implique d’énormes compromis. Il y a quelques semaines, Aviv Ben-Yosef rappelait sur son blog pourquoi il faut éviter les faux contrôles de formulaires en HTML.

Voici une liste des pour et contre de l’utilisation de tels contrôles graphiques.

Pour : 

• C’est joli.

Contre :

• Ça alourdit le temps de téléchargement de la page, et donc aussi le nombre de requêtes.
• Ça ralentit le chargement de la page côté client. Vous devrez attendre que tous vos scripts soient chargés avant de pouvoir utiliser votre formulaire.
• Ça diminue l’ergonomie de votre site. Les contrôles de formulaires système ont l’avantage d’être familiers pour les internautes. Même si vous avez fait une charte de liste déroulante super jolie et ergonomique, ça demandera du temps de compréhension supplémentaire à vos visiteurs.
• Ça réduit l’interopérabilité de votre site. Oui, ça fonctionne bien sur les machines à l’heure à laquelle vous avez développé votre site. Mais rien ne vous garantit que ça ne fonctionnera encore sur les machines de demain.
• Ça détruit l’accessibilité de votre page. Les faux contrôles générés en HTML deviennent totalement inutilisables.
• Ça a un impact sur le temps d’intégration, et donc le coût de votre projet.

Par pitié, n’imposez pas ça à vos visiteurs.