HTeuMeuLeu

Comparaison du temps passé par un intégrateur débutant et un intégrateur confirmé à faire du découpage dans Photoshop, coder en HTML, coder en CSS, faire du débuggage entre navigateurs.  

Je ne m’étais jamais vraiment posé la question, mais cet article de Scott Hanselman m’a fait réaliser pourquoi on appelle un bouton radio « un bouton radio »  (avec la confirmation de Wikipédia).

Les boutons radio sont appelés ainsi car ils rappellent les boutons que l’on peut trouver sur les anciennes radios qui permettent de choisir d’écouter une station parmi les différentes fréquences préalablement enregistrées. Comme il n’est possible d’écouter qu’une seule station à la fois, lorsque l’on appuie sur un des boutons, si un autre est déjà enfoncé, alors il se relève.

J’ai honte de ne pas avoir su ça plus tôt.

Il y a quelques années, j’étais tombé sur un article chez 37signals qui m’avait marqué :

Il y a quelques années, j’ai lu un livre sur les pédales d’effets pour guitares. Quelque chose que l’auteur avait écrit en introduction m’avait marqué : « Le ton est dans vos doigts. »

Il poursuivait son explication : vous pouvez acheter la même guitare, les mêmes pédales d’effets, et le même ampli qu’Eddie Van Halen utilise. Mais quand vous jouez avec ce matériel, ça va toujours sonner comme vous.

A l’inverse, Eddie pourrait se brancher sur une installation merdique de Strat/Pignose dans une boutique d’occasions et vous pourriez quand même reconnaître que c’est Eddie Van Halen qui joue.

Bien sûr, du matériel de luxe peut aider. Mais la vérité est que le ton vient de vous.

Je pense souvent à cette histoire quand les gens font une fixation sur le matériel plutôt que le contenu. Vous voyez le genre : des apprentis designers qui veulent une avalanche de polices fantaisistes et de filtres Photoshop mais qui n’ont rien à dire. Des photographes amateurs qui veulent débattre du film contre le numérique au lieu de ce qui fait en réalité une bonne photo. Des entrepreneurs qui se préoccupent plus de logiciels et de problèmes de mises à l’échelle plutôt que d’avoir en fait des clients et faire de l’argent. Ils passent tous à côté du but.

C’est particulièrement vrai pour l’intégration. L’intégration, c’est personnel. Vous avez beau avoir un super IDE, une charte d’intégration, une bonne connaissance des standards, votre code restera votre code. Le choix des balises, du type d’indentation, du nommage de vos classes et identifiants, restent intrinsèquement liés à vos propres préférences, et à votre propre style. J’ai par exemple tendance à être assez minimaliste dans mon HTML, mais un peu plus verbeux dans mes CSS.

S’il est assez naturel de voir la personnalité d’un graphiste transparaître à travers ses créations, il en va de même pour un intégrateur. Mais contrairement à un graphiste, le travail de l’intégrateur est souvent invisible, et beaucoup plus difficile à juger. Comme je l’expliquais le mois dernier :

Si vous voulez vraiment savoir ce que vaut un intégrateur, ne regardez pas ses pages intégrées. Regardez son code.

Je suis tombé sur cette liste de conseils pour les concepteurs de jeux rédigée en 2004 par Jordan Mechner, le créateur de Prince of Persia. Après avoir parlé de Portal 2 et de Mega Man, je suis toujours aussi fasciné par les leçons à apprendre du monde du jeu vidéo pour le monde du web.

1. Prototypez et testez les éléments clés du jeu le plus tôt possible.
2. Construisez le jeu par étapes incrémentales. Ne faites pas de gros documents de conception.
3. En avançant, continuer à renforcer ce qui est fort, et à vous séparer de ce qui est faible.
4. Soyez ouverts à l’inattendu – tirez le maximum des propriétés émergentes.
5. Soyez prêts à vendre votre projet à chaque étape en cours de route.
6. C’est plus difficile de vendre une idée originale qu’une suite.
7. De plus gros budgets et équipes signifient de plus grandes pressions pour rester dans les temps.
8. N’investissez pas dans des outils de développement démesurément grandioses.
9. Assurez-vous que le joueur ait toujours un but (et connaissez le).
10. Donnez au joueur un retour clair et constant s’il s’approche de son but ou s’il s’en éloigne.
11. L’histoire doit aider le gameplay, pas le submerger.
12. Le moment où le jeu devient jouable pour la première fois est le moment de vérité. Ne soyez pas surpris si ce n’est pas aussi amusant que vous l’espériez.
13. Parfois un tour bon marché est mieux qu’un plus cher.
14. Écoutez la voix de la critique – elle a toujours raison (vous devez juste trouver de quelle manière).
15. Votre vision initiale n’est pas sacrée. C’est juste un brouillon.
16. N’ayez pas peur d’envisager de GROS changements.
17. Quand vous découvrez ce qu’est le coeur du jeu, protégez le jusqu’à la mort.
18. Peu importe tout ce que vous jetez, ce ne sera jamais assez.
19. Mettez votre ego de côté.
20. Personne ne sait ce qui va marcher.

Kevinjohn Gallagher a écrit un chouette article détaillant le débat autour des préfixes -webkit- (rappel) et d’Opera, intitulé « Est-ce que la grosse dame chante pour les préfixes navigateurs ?« . Il a de bonnes propositions pour améliorer la situation :

La première action à prendre est de mettre la pression sur Apple/Google/WebKit pour implémenter les bons standards des propriétés en retirant le support de « -webkit- » lorsque la version non-préfixée est standardisée, et ne pas contourner le processus convenu. Ne vous trompez pas, en favorisant l’utilisation continue de « -webkit- » en dépis de la version non préfixée comme décris dans les spécifications CSS2.1 et CSS3, ce sont ces organisations qui ont donné aux développeurs la permission de ne pas écrire leur code d’une manière standard.

Deuxièmement, nous devons créer un endroit centralisé avec les bonnes informations, avec le bon niveau de détails. Vous et moi savons ce que nous faisons, mais franchement Internet est inondé de désinformation et de personnes contournant les standards dès que ça corresponds à un truc « cool ». Bruce Lawson me rappelait l’existence des Web Standards Curriculum qu’Opera ont ouverts et soumis au W3C; mais ce n’est pas écrit pour un développeur d’aujourd’hui, c’est écrit pour des gens qui sont déjà bien avertis.

Troisièmement, nous avons besoin que les services de validation HTML/CSS marquent le manque de standards comme des erreurs. Si vous avez un préfixe -webkit- et pas la version non préfixée, c’est une erreur. Si vous avez un préfixe -webkit- mais pas la version -moz-, c’est un avertissement (idéallement une erreur). Au fond nous voulons faire du web un meilleur endroit, et ça n’arrivera que si on éduque.

Quatrièmement, arrêtons avec la minification des CSS. Je sais que ça va causer une controverse, mais on ne gagne que quelques Ko et on rends le débuggage de notre code plus difficile pour les gens. Et avant que quelqu’un ne me sorte « l’excuse des données sur mobile », je vous en réfère aux images dans le responsive design, et le fait que des sites mis en avant par des magazines importants atteignent maintenant 5 Mo à télécharger sur un mobile ! Le web a grandit basé sur la capacité des gens à inspecter du code, lire, apprendre et reproduire; revenons en aux bases.

Cinquièmement, nous avons besoin que le CSS Working Group avance plus vite. Foutrement plus vite ! Une partie des cartes de Apple/Google consiste à dire que le CSSWG (et tous les autres groupes de travail impliqués dans CSS et HTML5) sont tellement horriblement lents à standardiser quoi que ce soit que les gens n’ont pas d’orientation claire et unifiée. Cette excuse foireuse ne marchait pas pour Microsoft à l’époque, et elle ne marche pas non plus maintenant; mais ça ne veut pas dire qu’ils ont tort, mais indique juste le niveau de négligence dont ils veulent se décharger.

Enfin, nous devons pointer du doigt et balancer des noms. Aucun d’entre nous n’aiment cette idée, mais il le faut, désolé. C’est la seule façon pour que les gens fassent attention. Prenez le top 10 000 d’Alexa. Prenez le top 500 FTSE. Prendez le top 100 des agences numériques et parcourez les sites qu’elles ont réalisé. Croyez moi, il ne faudra que quelques messages du genre « Les sites réalisés par R/GA ne fonctionnent pas sur 250 millions d’appareils mobiles » et les choses changeront.

Je suis assez d’accord avec l’ensemble de ces points, en particulier le deuxième invitant à éduquer les développeurs web, comme je l’évoquais ici. Le 4ème point me semble assez futile. Et même si le dernier point et l’idée d’une chasse au sorcière (comme l’avais suggéré Daniel Glazman) me dérange profondément, je crains qu’il ne faille en arriver là pour que les choses changent.