HTeuMeuLeu

La semaine dernière, Jeff Atwood (fondateur de Stack Overflow) a initié un débat sur son blog avec un article intitulé « Par pitié, n’apprenez pas à coder » :

La tendance à dire que « tout le monde devrait apprendre à programmer » est tellement hors de contrôle que le maire de New York City a réellement juré d’apprendre à coder en 2012.

C’est un noble geste pour recueillir les votes de la communauté high-tech de NYC, mais si le maire de New York City a vraiment besoin de taper du code JavaScript pour faire son boulot, c’est qu’il y a quelque chose de profondément, horriblement, terriblement de travers avec les politiques dans l’état de New York. Même si M. Bloomberg « apprenait à coder », avec mes excuses à Adam Vandenberg, je suppose que ça donnerait quelque chose comme ça :
10 PRINT "I AM MAYOR"
20 GOTO 10Heureusement, les chances pour pour que cette fantaisie technologique arrive, même pour plaisanter, sont nulles, et pour de bonnes raisons : le maire de New York City va on l’espère passer son temps à faire le travail que des employés contribuables le payent pour faire à la place. D’après le site du bureau du maire, ça signifie travailler sur les programmes contre l’abstention à l’école, les améliorations des transports publics, le budget de la ville pour 2013, et… il faut vraiment que je continue ?

Pour ceux qui soutiennent que programmer est une compétence essentielle que nous devrions enseigner à nos enfants, au même titre que la lecture, l’écriture, ou l’arithmétique : pouvez-vous m’expliquer en quoi Michael Bloomberg serait meilleur à son travail quotidien de gestion de la plus grosse ville des USA s’il se réveillait un matin en étant un as du développement Java ? Il me semble évident qu’une lecture expérimentée, une écriture expérimentée, et au moins un niveau lycéen en mathématiques sont fondamentaux pour réaliser le travail d’un politique. Ou n’importe quel travail, pour ce que ça vaut. Mais comprendre des variables et des fonctions, des pointeurs et la récursivité ? Je ne vois pas.

Forcément, les réponses ont été vives et nombreuses. J’ai retenu notamment celle de Sacha Greif, webdesign Freelance : « Par pitié, apprenez à coder« .

« Apprendre à coder » ne veut pas forcément dire devenir le prochain Linus Torvalds, tout comme « apprendre à cuisiner » ne veut pas dire ouvrir un restaurant 3 étoiles.

Ça veut simplement dire avoir une compréhension basique du fonctionnement des ordinateurs plutôt que suivre aveuglément ce que vous dit un trombone qui parle (et peut être finalement être capable de programmer vos propres trombones qui parlent).

Si le premier article est particulièrement tranché, je reste persuadé que l’apprentissage de la programmation devrait être aujourd’hui obligatoire à l’école. Pas au même titre que la lecture, l’écriture ou les mathématiques. Mais au même titre que l’histoire, la géographie, la physique, la chimie, l’économie, ou la philosophie. Vous ne deviendrez pas un grand historien, chimiste ou philosophe en vous contentant des cours donnés au collège et au lycée. Mais aussi barbants que certains de ces cours ont pu vous paraître à l’époque, ils ont contribué à votre culture générale, et à la façon dont vous appréhendez et comprenez le monde qui vous entoure.

S’il me paraît important pour un quidam d’avoir des notions basiques en programmation, cela me semble carrément indispensable pour quelqu’un qui travaille dans le web. Mais c’est souvent loin d’être le cas chez les chefs de projet et les graphistes.

Chez Pixar, tous les employés sont invités à apprendre à dessiner :

Grâce à l’Université Pixar, les employés apprennent à voir le travail de la société (et de leurs collègues) sous un nouvel angle. « Les compétences qu’on développe sont des compétences dont nous avons besoin partout dans l’organisation. Pourquoi enseigner le dessin à des comptables ? Parce que des cours de dessin n’apprennent pas seulement aux gens à dessiner. Ça leur apprends à être plus observateurs. Il n’y a aucune société sur Terre qui ne bénéficierait pas d’avoir des employés plus observateurs. »

En apprenant à coder, vous n’apprenez pas seulement à coder (même si c’est plutôt cool). Vous apprenez à résoudre des problèmes. Je ne pense pas qu’il y ait une société sur Terre qui ne bénéficierait pas d’avoir des employés plus doués pour résoudre des problèmes. Ça vaut donc également pour le maire de New York.

Mais trop souvent, j’ai le sentiment que l’ignorance de la programmation parmi les chefs de projet web ou les graphistes est due à un total mépris du métier. « Je suis directrice artistique, je ne me vois absolument pas me lancer dans du développement JavaScript » (entendu à Paris Web, à 38min).

Quelque soit votre métier, vous devez être curieux, et ne jamais rechigner à apprendre quelque chose de nouveau. Récemment lues sur Reddit, je cautionne particulièrement ces paroles de Neil deGrasse Tyson :

Je suis poussé par deux philosophies principales. En savoir plus aujourd’hui sur le monde que j’en savais hier. Et en chemin, diminuer la souffrance des autres. Vous seriez surpris jusqu’où cela peut vous mener.

Ce serait hautain et condescendant de ne pas vouloir apprendre à cuisiner ou de ne pas vouloir apprendre une nouvelle langue.

Je pense que c’est hautain et condescendant de ne pas vouloir apprendre à coder. C’est décrédibilisant pour vous en tant que professionnel du web. C’est décrédibilisant pour vous en tant qu’être humain.

Hier, Andrew Ray a lancé un appel aux webdesigners auquel je ne peux qu’approuver : « Arrêtez d’utiliser des ombres portées courbées« .

Le phénomène des ombres portées courbées est une mode de design dégoûtante qui doit cesser. Maintenant. Peut être que vous trouvez ça joli. Vous avez tort.

Elles me donnent envie de vomir en créant une surface impossible.

L’intention est de rendre les coins de l’image incurvés. C’est horriblement raté. Pour que l’effet marche, les coins devraient être visuellement déformés. Ils ne le sont pas. Ils sont parfaitement en angle à 90 degrés. Ça donne l’impression que l’image est placée sur une surface incurvée.

Si vous avez la moindre aptitude de repère dans l’espace, l’image ci-dessus doit vous rendre nauséeux. Le texte est placé sur une surface incurvée mais n’est pourtant pas déformé. C’est une structure impossible. C’est comme lire du texte sur un fond à motifs. Ça détériore inconsciemment la compréhension de la lecture, ça cause des indigestions, et ça dégrade votre crédibilité en tant que designer.

Ce n’est pas la première fois que je vois une mode aussi dégoûtante se répandre dans le webdesign. La dernière fois, c’était la mode d’ajouter des reflets sous tout et n’importe quoi.

Devinez quoi, monsieur-le-graphiste-apprenti-sorcier-apprenti-physicien. Même dans les théories les plus folles de la physique quantique et des multiples univers parallèles, jamais l’écran de cet ordinateur ne se reflétera ainsi sur la surface sur laquelle il est posé. Jamais. Ça ne veut pas dire que vous ne devez jamais faire de reflets. Mais clairement pas comme ça.

Parce que le problème, quand je rencontre une erreur comme celle-ci sur une page web, c’est que mon cerveau passe immédiatement en mode « Oh oh, il y a quelque chose qui cloche ». Je vais essayer de passer à côté, de lire le contenu de la page. Mais mon cerveau va revenir à la charge : « Non mais t’as vu ce reflet ? Tu crois que ce serait possible en vrai ? ». J’essaierais quand même de poursuivre ma lecture. Mais ça me trottera toujours en tête.

En y réfléchissant, ça m’a rappelé l’effet de la vallée dérangeante (ou « Uncanny Valley » en anglais) :

L’effet de la vallée dérangeante est une réaction psychologique devant certains robots humanoïdes. Il décrit le fait que plus un robot humanoïde est similaire à un être humain, plus ses imperfections nous paraissent monstrueuses. Ainsi, certains observateurs seront plus à l’aise en face d’un robot clairement artificiel que devant un robot doté d’une peau, de vêtements et d’un visage pouvant passer pour humain. La théorie prévoit cependant qu’au delà d’un certain niveau de perfection dans l’imitation, les robots humanoïdes sont beaucoup mieux acceptés. C’est pour cela qu’est utilisé le terme de vallée : il s’agit d’une zone à franchir dans laquelle chaque progrès fait vers l’imitation humaine amènera plus de rejet avant de finalement amener une acceptation plus grande.

Le problème des ombres portées courbées ou des reflets sous un produit, ce ne sont pas les effets en eux-mêmes. Mais c’est le fait que mal réalisés, ils ne sont plus crédibles et deviennent totalement repoussants. On atteint alors la vallée dérangeante du webdesign.

Je rencontre souvent chez mes confrères développeurs une manie que j’ai pris l’habitude d’appeler le syndrome du développeur. Cette manie consiste à restituer des données telles qu’elles sont à la source. J’appelle ça le syndrome du développeur, mais je pourrais appeler ça le syndrome du technicien, car ce n’est clairement pas limité à cette catégorie professionnelle, et encore moins à l’informatique. Laissez-moi vous donner des exemples.

Dans les toilettes de mon boulot, les robinets du lavabo sont arrangés comme ci-dessus (cette photo a été prise par Kev Adams, ce qui me rends un peu triste et honteux d’être tombé dessus et de m’en servir comme exemple). Cette disposition n’est évidemment pas du tout pratique à utiliser. Mais il n’est pas difficile d’imaginer pourquoi ça a été installé ainsi : un tuyau d’eau chaude et un tuyau d’eau froide en entrée, un robinet pour l’eau chaude et un robinet pour l’eau froide en sortie.

Pour améliorer ça, il semble donc évident de devoir se séparer d’un robinet, pour n’avoir qu’une seule sortie d’eau. Mais là encore, les différentes installations qu’on croise dans notre quotidien sont loin d’être parfaites.

Une première solution consiste à conserver deux robinets mais une seule sortie d’eau (ci-dessous à gauche). Mais là encore, il s’avère difficile de jauger et d’ajuster la température. La meilleure solution est d’utiliser un robinet ajustable, permettant de contrôler très facilement le débit et la température de l’eau (ci-dessous à droite).

Si je vous parle de robinetterie, ce n’est pas à cause d’une soudaine passion naissante pour la plomberie. Mais c’est parce que je rencontre exactement le même genre de problèmes partout sur le web. A chaque fois, une donnée enregistrée est restituée telle quelle ou presque, sans chercher à savoir si elle est pertinente pour l’internaute.

Un exemple courant concerne l’affichage de dates. La solution la plus facile et la plus courante pour un développeur, c’est d’afficher une date au format « JJ/MM/AAAA HH:MM ». Cette solution semble naturelle, mais s’avère dans bien des cas complexe à comprendre pour l’internaute. Par exemple, en me connectant à mon compte Last.fm, je découvre les morceaux que j’ai récemment écoutés et qui ont été ajoutés à ma bibliothèque.

C’est bien, mais ça ne m’avance pas à grand chose. « C’est qui ces groupes ? Quand est-ce que j’ai écouté ça ? Le 9 mai, c’était quand ça ? Et est-ce que la chanson de Gary Wright parle du logiciel d’Adobe ? »

En allant dans ma bibliothèque, je découvre une présentation différente des dates, beaucoup plus pratique.

« Ah, c’était mercredi après-midi. Donc c’est surement ma copine qui a allumé mon ordi et qui a lancé des playlists. » Oh, et la chanson Dream Weaver, c’est dans la B.O. de Wayne’s World.

Un autre exemple que je croise souvent sur le web, ce sont les lignes panier des sites e-commerce. Le but d’une page panier, c’est de présenter les informations importantes de tous les produits, et de permettre certaines actions (suppression, modification de coloris/taille/quantité). Voici un magnifique exemple chez La Redoute.

Essayez de distinguer facilement les 3 maillots de bain que vous venez d’ajouter à votre panier. Le visuel n’est pas assez grand pour distinguer quoi que ce soit. Et les libellés des produits ont tous été tronqués et sont quasiment identiques. Admirez également au passage la très utile colonne « Offre spéciale ».

Vous pouvez très bien mettre en ligne un site tout à fait correct rempli des symptômes du syndrome du développeur, tout comme il est courant de rencontrer des robinets comme dans mon premier exemple. Mais si vous réfléchissez à ce qui est mieux pour l’utilisateur, vous apporterez une meilleure expérience utilisateur. Et ce travail, ce n’est pas qu’au développeur ou à l’intégrateur de s’en préoccuper, mais aussi et surtout au chef de projet et au graphiste.

Cette semaine, Microsoft a laissé entendre qu’ils n’autoriseraient aucun autre navigateur qu’Internet Explorer sur la version ARM (pour tablettes) de Windows 8. Microsoft se rapproche ainsi du contrôle imposé par Apple sur iOS. Mozilla est aussitôt monté au créneau, suivi par Google, pour dénoncer cette pratique.

Si je désapprouve fortement la politique de Microsoft et d’Apple, la réaction de Mozilla me semble particulièrement hypocrite, comme le souligne Preston Gralla chez ComputerWorld.

Quand on insiste pour qu’il explique l’apparente contradiction dans l’attitude de Mozilla envers Apple et Microsoft, Harvey Anderson (avocat chez Mozilla) déclare :

« La différence ici est que Microsoft utilise le pouvoir de son monopole de Windows sur le marché des OS pour exclure la compétition sur le marché des navigateurs. »

Il y a tellement de choses fausses dans cette phrase, que c’est difficile de savoir par où commencer. Alors commençons par les bases : sur le marché des tablettes, s’il y a un pouvoir de monopole, il est dans les mains d’Apple, pas de Microsoft. Les derniers rapports IDC indiquent qu’Apple domine le marché des tablettes avec 68% de parts de marché. Les tablettes Windows se vendent à peine. Alors de quel pouvoir de monopole Anderson parle-t-il ?

Mozilla ? Hypocrites ? Noooon, jamais !

Ahem. Ahem. Ahem.

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.

Ces dernières semaines ont été particulièrement chargées en révélations dans le monde d’Android. La fin du premier trimestre 2012 a également été l’occasion pour de nombreuses sociétés d’annoncer leurs résultats. Mais surtout, le procès actuellement en cours aux États-Unis opposant Google à Oracle sur l’utilisation de technologies propres à Java. Si vous voulez en savoir plus, CNET a un résumé assez complet.

Voici une sélection personnelle de différents faits et chiffres apparus ces dernières semaines :

• Larry Page a dit : « Je crois qu’Android était important pour Google. Je ne dirais pas que c’était crucial. » (source)
• On a vu a quoi ressemblait le premier prototype de Google Phone en 2006, deux ans avant l’arrivée de l’iPhone.
• Google espérait vendre 10 millions de tablettes et atteindre 33% de parts de marché en 2011 (source)
• La Kindle Fire d’Amazon, une tablette Android dépourvue de tous les services de Google, est la plus populaire des tablettes Android avec plus de 54% de parts de marché (source)
• Six mois après sa sortie, la dernière version d’Android ne représente que 4,9% de tous les téléphones Android. (source)
• C’est la plus lente adoption d’Android, toutes versions confondues. (source)
• L’opérateur Verizon a vendu au cours du premier trimestre 2012 plus d’iPhones que tous les modèles de téléphones Android confondus (source)
• « Apple a capturé 73% des bénéfices de l’industrie téléphonique et Samsung a capturé 26%. HTC a pris 1%. Tous les autres ont perdu de l’argent. » (source)
• En 2010, Google gagnait 2,5x plus d’argent avec iOS qu’avec Android. (source)

« Android vaincra ».

Mais pas cette année. Cette année, c’est Apple.

Ce week-end, j’ai regardé une vidéo de Sequeletis (vue via Twitter) expliquant comment le jeu Mega Man éduque le joueur à travers son design et la conception de ses niveaux, et non par de vulgaires tutoriels. La vidéo dure 20 minutes, mais tout s’enchaîne très vite c’est très rigolo (j’ai ris tout haut à 1min44).

Si ce concept est important dans le jeu vidéo, c’est à mon avis tout aussi valable pour le web. Il y a deux mois je partageais avec vous l’exemple des portes de Norman, en résumant ma pensée :

Si vous devez expliquer à l’internaute comment se servir de votre page, même avec une simple phrase, vous avez raté votre travail.

C’est malheureusement une pratique très courante sur le web, où on va forcer l’internaute à lire une notice. Même un simple « cliquez ici » est une notice. Pourtant, des petits détails parfois anodins peuvent faire la différence.

Par exemple chez Archiduchesse, quand vous ajoutez un produit à votre panier à partir d’une page liste, une petite étoile en pixel art va partir du produit pour de diriger vers le récapitulatif du panier en haut à droite du site.

S’il est assez courant de retrouver un récapitulatif panier sur un site e-commerce à cet endroit, et s’il est déjà ici assez bien mis en avant graphiquement, cette animation fait clairement le lien entre l’action tout juste réalisée et la suite, c’est à dire le passage d’une commande.

Sur la plupart des sites e-commerce, bien qu’ayant des mises en page relativement similaires, l’ajout au panier se suit en général d’une popup indiquant à l’internaute qu’il peut « poursuivre son shopping » ou « finaliser sa commande ».  Si on reprends l’exemple de la vidéo de Mega Man du début, ce genre de popup est complètement l’équivalent des bulles d’aide dans les jeux vidéo vous bloquant dans votre lancée pour vous expliquer des concepts basiques.

Le skeuomorphisme est le principe d’imiter dans un objet un détail de conception qui n’est plus nécessaire, mais qui était indispensable autrefois. On trouve de nombreux exemples dans la vraie vie, comme l’imitation de rainures de bois sur des meubles en plastique, ou l’imitation du son de fermeture de l’obturateur sur un appareil photo numérique compact ou bridge. En informatique, on rencontre chaque jour pleins d’exemples. Le plus classique est l’utilisation d’une disquette comme icône de sauvegarde de documents.

Cet article de aKa chez FramaBlog nous rappelle également de manière amusante pourquoi les touches de nos claviers sont disposées ainsi :

Un beau matin de 1868, alors que les États-Unis résonnent encore des canons de la guerre de sécession, un bricoleur du Wisconsin du nom de Sholes invente la première machine à écrire. Sans se poser trop de question, il place logiquement les touches par ordre alphabétique.

Chaque touche appuyant sur une barre métallique horizontale qui ne peut pas frotter contre ses voisines, Sholes se voit dans l’obligation de décaler les rangées de touches, décalage qui est encore présent, sans aucune raison autre qu’historique, sur votre clavier, voire même sur les claviers virtuels des tablettes et des écrans tactiles !

Les champions du skeuomorphisme ces dernières années, ce sont Apple, qui usent et abusent d’effets skeuomorphiques dans leurs logiciels.

L’année dernière, James Higgs exprimait son mépris pour cette nouvelle tendance :

Il va sans dire que ma préférence va pour le design sans décoration, certainement sans un soupçon de sentimentalisme, et que je déteste ces nouvelles applications. Pourquoi ?

Pour faire simple : parce que ce sont des mensonges. Elles tentent de nous réconforter en essayant de nous montrer comment elles sont liées aux objets physiques du monde réel alors qu’il n’y en a pas besoin. En quoi sommes nous aidés à comprendre ce que fait l’application Localiser mes amis en y ajoutant des décorations en cuir ? Et à quel point ça peut être difficile pour quelqu’un, même un nouveau venu dans le numérique, de comprendre une liste de livres ? Est-ce que c’est si difficile, que la seule façon de le faire comprendre est de les présenter sous forme d’une bibliothèque en bois ?

Sur Snow Leopard, Photo Booth ressemblait à ça :

Puis est arrivé Lion, et son mode plein écran. Et voici venir le train du skeumorphisme :

Boom ! Des rideaux. Des panneaux en bois. Des boutons en métal. Vraiment, Apple ?

Encore une fois, regardons l’utilité de Photo Booth : prendre des photos, enregistrer des vidéos, et leur appliquer des filtres. La première version de Photo Booth rendait tout cela très facile et accessible. Par contre, elle ne communiquait pas le but de Photo Booth : faire l’idiot et s’amuser. Laissez-moi vous présenter un exemple :

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

Photo Booth est un jouet numérique. La première version de Photo Booth, bien que très propre et fonctionnelle, ne ressemblait pas à un jouet. Ce n’était pas amusant, et ça ne vous encourageait pas à jouer avec. Avec le nouveau mode plein écran, Apple utilise le skeuomorphisme pour inviter ses utilisateurs à s’amuser.

Le skeuomorphisme sert à communiquer et à renforcer des sentiments, à aider une application à devenir une expérience mémorable, et pas juste un outil. Ça aide à communiquer sur le but d’une Interface Utilisateur, et pas seulement sur les fonctionnalités qu’elle propose.

En février dernier, les différents fabricants de navigateurs (Mozilla, Opera et Microsoft) ont exprimé leur souhait d’interpréter certaines propriétés CSS3 avec le préfixe -webkit-. Le lendemain, Daniel Glazman (co-président du groupe de travail CSS du W3C) lançait un appel à tous les développeurs web pour éviter que cette situation ne se produise. Le message a été plutôt bien relayé par la communauté du développement web et du design web. Malheureusement hier, le magazine .NET rapportait qu’Opera s’apprêtait de manière imminente à implémenter et interpréter certaines propriétés avec le préfixe -webkit- :

Opera, aux côtés de Microsoft et Mozilla, ont annoncé lors d’une réunion du CSS Working Group qu’ils supporteraient certaines propriétés avec le préfixe WebKit. C’est parce que trop d’auteurs de sites mobile utilisent uniquement les propriétés avec un préfixe -webkit-, et même pas la version standard, sans préfixe, lorsqu’elle est disponible. Cela mène à une expérience utilisateur réduite sur Opera, Firefox Mobile et IE Mobile, qui n’affichent pas les mêmes effets à la mode, comme des transitions, des dégradés, même s’ils supportent ces effets.

Il y a trois mois, je résumais le ridicule de la situation, auquel j’ajoute aujourd’hui cette représentation Tarantino-esque de l’état du web.

Les acteurs du web ont fait quelque chose de stupide en utilisant uniquement des préfixes -webkit-. Les fabricants de navigateurs vont faire quelque chose de stupide en implémentant les propriétés avec le préfixe -webkit-. Le W3C propose une réponse stupide visant à pénaliser les auteurs du web ignorants ou peu consciencieux.

Je l’ai dit hier et je le redis aujourd’hui : c’est une honte. En choisissant d’interpréter les propriétés avec le préfixe -webkit-, les navigateurs favorisent leurs propres intérêts personnels au détriment du Web Ouvert. C’est particulièrement honteux de la part d’Opera et surtout Mozilla qui se vantent sans cesse de défendre le Web Ouvert.

Qu’on soit bien clair : l’origine de tout ce débat, l’origine du problème, ce n’est pas le W3C, ce ne sont pas les navigateurs. Ce sont nous, petits intégrateurs, qui sommes la cause de ce problème. Ou plutôt, les intégrateurs peu consciencieux ou peu avertis, qui utilisent uniquement des préfixes -webkit- sans se préoccuper des autres navigateurs.

Je me considère comme un intégrateur un minimum averti. Je travaille en agence depuis 6 ans, et je fait de la veille que je partage quotidiennement sur Twitter ou sur ce blog. J’estime être relativement au courant des nouveautés du web et en particulier en intégration. Au fil des années, de ma part mon travail et également via Twitter, j’ai rencontré et discuté avec des dizaines voire une centaine d’intégrateurs. Des intégrateurs freelance, des intégrateurs en agence, des intégrateurs chez l’annonceur pour de plus ou moins grands comptes. En dehors de la sphère Twitter et de la petite famille francophone de développeurs web, j’ai très souvent constaté qu’une bonne partie d’intégrateurs sont souvent mal renseignés sur leur métier. Dans certains cas, c’est parce qu’ils considèrent l’intégration comme un simple métier, et qu’ils n’éprouvent pas l’intérêt de faire une veille quotidienne. Dans d’autres cas, c’est par manque de temps et par épuisement. Par exemple, j’ai rencontré un jour une intégratrice qui travaillait dans une agence où elle devait intégrer chaque jour un site complet (de 10 à 20 pages). Difficile de trouver le temps de faire de la veille dans de telles agences.

L’origine du problème, c’est donc le manque de formation et de connaissances détaillées dans le web pour une grosse partie des intégrateurs, développeurs web ou webdesigners. En choisissant d’interpréter les propriétés avec le préfixe -webkit-, les navigateurs ne vont pas résoudre l’origine du problème. Ils vont l’aggraver. Ces intégrateurs vont continuer à utiliser des propriétés avec le préfixe -webkit- uniquement, en se satisfaisant que ça fonctionne désormais partout. Mais ils ne se remettront pas en question, et ils n’aideront pas à rendre le web meilleur.

Alors quelle est la solution ?

Beaucoup d’intégrateurs souhaiteraient tout simplement l’abandon des préfixes navigateurs. Mais ces préfixes sont utiles et nécessaires. Ils permettent aux navigateurs d’implémenter des fonctionnalités en cours de définition par le W3C, et aux développeurs de les tester. Mais à tout moment, ces propriétés sont susceptibles de changer, pour être améliorées voire supprimer. C’est ce qui est arrivé avec les définitions des dégradés en background. La première syntaxe proposée par le W3C a été revue et adoptée par les autres navigateurs suite à la proposition d’une meilleure syntaxe par Mozilla.

Alors quelle est la solution ?

Je n’ai pas la prétention d’avoir une solution miracle. Mais par expérience, je sais une chose : si à un moment donné, un navigateur affiche un message alarmant à l’internaute sur un site donné, alors toute la hiérarchie d’une boîte va se réveiller pour que ce soit corrigé au plus vite. J’ai souvent rencontré le cas sur IE6. Sur IE6, quand vous êtes sur une page en HTTPS et que vous appelez une ressource en HTTP, le navigateur affichera une alerte à l’internaute lui demandant s’il souhaite afficher ou pas les contenus non sécurisés. A chaque fois que j’ai aidé des clients à résoudre ce problème sur leurs sites, croyez moi, toute la hiérarchie était sur le coup : des remontées du service téléphonique client au département marketing jusqu’à la direction générale. L’origine du problème vient également d’une mauvaise pratique de la part du développeur web, qui n’a pas pris le soin d’appeler des contenus sécurisés partout. Mais en corrigeant ce problème, le développeur web apprends quelque chose. Et s’il tient à sa survie, il y a de grandes chances qu’il retienne la leçon.

On pourrait alors imaginer un message d’alerte similaire, laissant entendre que le site a été mal conçu, et lui proposant d’améliorer le rendu du site. Si l’internaute accepte, le navigateur pourra interpréter les préfixes -webkit-. Sinon, la page s’affichera normalement.

Avec une telle solution, tout le monde est gagnant. L’internaute peut afficher une version optimale du site. Le navigateur peut démontrer ses capacités. Et le développeur web et les concepteurs du sites seront invités à revoir leurs pratiques.

J’espère vraiment que la décision d’Opera et de Mozilla n’est pas figée, et qu’ils essaieront de travailler avec des développeurs web pour trouver la meilleure solution, plutôt que d’imposer au monde entier leurs mauvaises décisions.

Après un premier trimestre 2012 exceptionnel, Apple a annoncé hier ses résultats du deuxième trimestre 2012. Encore une fois, et comme le résume MG Siegler, les chiffres sont exceptionnels :

• 39,2 milliards de dollars de chiffre d’affaires
• 11,6 milliards de dollars de bénéfices
• 47,4% de marge brute
• 35,1 millions d’iPhones vendus
• 11,8 millions d’iPad vendus
• 4 millions de Mac vendus
• 7,7 millions d’iPod vendus

Mais ce qui me marque le plus, c’est qu’Apple fait désormais sa deuxième entrée dans le Top 20 des entreprises ayant réalisé le plus de chiffre d’affaires en un trimestre. Apple occupe désormais la 4ème et la 6ème place de ce classement grâce aux deux derniers trimestres. Les 18 autres places sont occupées par des compagnies pétrolières, dont la plus récente date du 3ème trimestre 2011 à la 18ème place pour ExxonMobil.

Quand j’y réfléchis, je suis époustouflé.

Je suis né et j’ai grandi dans un monde où les rois du pétrole étaient les rois du monde. Nos moyens de locomotions, nos modes de vie, nos Guerres, ont directement été influencées par la possession et le contrôle du pétrole.

Depuis 6 mois, ce n’est plus le cas. Depuis 6 mois, c’est une société informatique qui a pris ce rôle. Depuis 6 mois, c’est Apple qui domine le monde.

Des étudiants de l’Université de Stanford (en Californie) ont présenté la semaine dernière à Lyon les résultats de leur recherche intitulée « Qui a tué ma batterie : analyser la consommation d’énergie des navigateurs mobiles« . Le rapport de l’étude de 10 pages est particulièrement complet et détaillé, et sa lecture s’avère très intéressante. C’est à ma connaissance un des premières lectures du genre aussi complète sur ce sujet. Si la lecture en anglais vous effraie, voici un petit résumé et une traduction des points les plus importants.

Les mesures ont été effectuées sur un téléphone Android ADP2 avec une connexion 3G. Un multimètre relié à la batterie enregistrait les mesures matérielles. Une version modifiée du navigateur par défaut d’Android a été utilisée pour mesurer précisément l’impact énergétique de chaque fichier chargé, et permettre d’automatiser la mesure de consommation pour des pages avec et sans cache.

Les tests ont été effectués sur 25 sites connus représentatifs du paysage du web. Les premiers résultats des mesures sont assez marquants. S’il faut compter au minimum une dizaine de joules pour établir une connexion 3G, la différence de consommation d’un site à l’autre peut aller de quelques joules à plus de 40.

Voici quelques exemples et quelques points qui m’ont particulièrement marqué dans cette étude.

• Certains sites comme Youtube passent près d’un quart de leur énergie de rendu sur des images.
• Le code JavaScript de Yahoo est inclus dans les pages HTML. La quantité de code JavaScript est très petite mais le code est exécuté à chaque chargement de la page. Ainsi l’exécution JavaScript prends seulement 6,79% du total de l’énergie utilisée pour le rendu.
• AOL et Picasa contiennent tous les deux de grandes images, but la consommation d’énergie des CSS d’AOL est beaucoup plus faible que celle de Picasa. La raison est qu’AOL utilise des tableaux HTML pour positionner ses images alors que Picasa utilise CSS pour positionner ses images. Ceci illustre parfaitement comment le positionnement en CSS est moins efficace en énergie que le positionnement utilisant des balises HTML.
•  Réduire JavaScript sur une page web mobile aux seules fonctions utilisées sur une page réduit grandement la consommation d’énergie. Utiliser des librairies JavaScript génériques (comme jQuery) simplifie le développement, mais augmente la consommation d’énergie des pages résultantes.
• Comme JavaScript, un fichier CSS doit être spécifique à la page et contenir seulement les règles requises par les éléments présents.
• JPEG est le format le plus efficace en énergie sur les téléphones Android, quelque soit la taille des images. Pour démontrer ce point, nous avons utilisé Mogrify pour convertir toutes les images des pages d’Amazon et de Facebook en JPEG avec une compression à 92% de qualité. Les deux sites ont alors constaté un gain de consommation d’énergie, à hauteur de 20% pour Amazon et 30% pour Facebook. La raison de ce gain est que le format JPEG compresse mieux les images et est plus rapide à décompresser que du PNG ou du GIF.

Et voici la traduction de leur conclusion apportant des conseils pour concevoir des sites efficaces en énergie.

• Nos expériences démontrent que le format JPG est le meilleur format pour le navigateur d’Android, et ce pour toutes les tailles d’images.
• Gmail, le plus « vert » des sites mobiles que nous ayons trouvé, utilise des liens HTML pour ouvrir les messages sur lesquels l’utilisateur clique. La version bureau de Gmail utilise JavaScript à la place. Nos expériences suggèrent qu’utiliser des liens plutôt que JavaScript réduit grandement la consommation d’énergie pour le rendu d’une page. Ainsi, en concevant la version mobile du site différemment de la version bureau, Gmail a été capable de sauver de l’énergie sur le téléphone.
• Nous avons trouvé un certain nombre de pages qui auraient pu être mises en cache localement et affichées sans aucun accès réseau. Malheureusement, ces sites utilisent Google Analytics, un outil qui aide le suivi de l’utilisation du site. Le JavaScript utilisé par Google Analytics force une requête réseau dynamique qui ne peut pas être mise en cache. Ainsi, bien que le site aurait pu être affiché à partir du cache, le téléphone doit payer le coût important de démarrer une session 3G. Nous espérons que ce document aidera les sites web à comprendre le coût de l’utilisation de ces outils tiers. Alternativement, si les navigateurs exposaient le statut de leur connexion à JavaScript, Google Analytics pourrait choisir de ne pas reporter d’informations si la connexion 3G est faible.
• AOL est capable de gagner de l’énergie lors de son rendu en utilisant de simples tableaux HTML pour positionner des éléments sur la page. D’autres sites qui positionnent des éléments en CSS demandent beaucoup plus d’énergies pour le rendu.
• Sur tous les sites mobiles que nous avons testé, les publicités étaient de petits fichiers JPEG et avaient peu d’impact sur la consommation totale d’énergie.
• Des sites comme apple.com sont particulièrement énergivores. Nous espérons que ce document démontre l’importance de construire un site mobile optimisé pour les appareils mobiles. Les sites qui ne le sont pas finissent par vider la batterie des téléphones des visiteurs. Ceci peut potentiellement réduire le traffic du site.

Il est difficile de mesurer la qualité d’une intégration. Certains outils comme le validateur W3C ou des validateurs WCAG permettent de se faire une petite idée, mais ne sont en rien représentatifs de tous les critères concernés par l’intégration d’une page web (graphisme, référencement, développement, etc…).

En y réfléchissant, je pense que la qualité d’une intégration peut se mesurer sur 3 niveaux avec les questions suivantes :

1. Est-ce que c’est bien pour l’internaute ? 
2. Est-ce que c’est bien pour le projet ?
3. Est-ce que c’est bien pour moi ?

La première question, « Est-ce que c’est bien pour l’internaute ?« , fait directement écho à mon mantra. En se préoccupant d’abord de l’internaute, on va faire attention aux problématiques qui vont directement le toucher :

• La performance : la vitesse de chargement d’une page web est un des critères les plus importants vis-a-vis de l’internaute. Est-ce que mon code est bien optimisé ? Est-ce que mes images sont bien découpées et bien compressées ? Est-ce que le nombre de requêtes HTTP est bien optimisé ?
• La compatibilité : vu la multitude d’appareils, de navigateurs et de logiciels permettant d’accéder au contenu de votre site, il est indispensable de codez pour les autres. Est-ce que la propriété X fonctionne sur le navigateur Y ? Est-ce que ma page s’affichera bien sur de nouveaux appareils avec des résolutions d’écran 2 fois supérieures ?
• L’accessibilité : toute aussi importante, et pourtant souvent sous-évaluée. Est-ce que le code un peu filou que je suis en train d’écrire sera bien interprété par un navigateur vocal ?

La deuxième question, « Est-ce que c’est bien pour le projet ?« , s’attache aux particularités de votre projet.

• Le type de projet : on n’évalue pas la qualité d’une intégration d’un e-mail, d’une application Facebook et d’un site e-commerce de la même manière. Les bonnes pratiques de l’intégration d’e-mails sont à l’opposé des bonnes pratiques d’un site e-commerce. Différentes problématiques demandent donc différents regards d’évaluation.
• Le graphisme : trop souvent vu comme la finalité d’une page web, il n’en reste pas moins un critère important. Est-ce que votre intégration ressemble bien à la maquette ? Est-ce que vous avez du prendre certaines libertés ? (et si oui, est-ce vraiment parce que c’est mieux pour le projet ?)
• Le référencement : selon le type de projet, il est possible que vous ayez des impératifs forts en référencement. Certaines préconisations vous demanderont peut être d’aller à l’encontre de vos bonnes pratiques habituelles.
• La technologie utilisée : même en livrant une intégration HTML statique, vous n’obtiendrez jamais le même résultat selon le langage (PHP, .NET, Ruby, …) ou le CMS (WordPress, Magento, …) utilisés par votre projet.

La dernière question, « Est-ce que c’est bien pour moi ?« , est le moment de penser à vous, cher intégrateur, mais aussi à vos collègues intégrateurs. C’est le moment de vous posez des questions sur vos pratiques personnelles.

• La compréhension de votre code : est-ce que vous arriverez à comprendre ce que vous venez d’intégrer dans 1 an ? est-ce que vos collègues vont comprendre ce que vous venez de faire ?
• La pertinence de vos choix d’intégration : j’ai intégré toute ma page en « position:absolute ».  Est-ce que c’était vraiment la meilleure solution ? Et si jamais on doit changer ça dans 3 mois ?
• Les bonnes pratiques habituelles : si vous travaillez en agence, il est important de respecter les normes d’écriture et les bonnes pratiques habituelles. Si votre agence utilise toujours jQuery, est-ce bien raisonnable d’utiliser Mootools parce que « vous aviez envie d’essayer » ?

Ce ne sont ici que quelques exemples, et les tenants et aboutissants de l’évaluation de la qualité d’une intégration sont évidemment bien plus nombreux. Mais ces quelques critères permettent déjà de prendre un certain recul sur son propre travail, et surtout de relativiser sur son jugement du travail des autres.

Le week-end dernier j’ai regardé cette conférence Post Mortem des scénaristes de Portal 2 (Chet Faliszek et Erik Wolpaw) datant de mars dernier à la GDC. Si vous avez aimé Portal 2, c’est vraiment une chouette conférence à voir (attention par contre, c’est plein de spoilers). Ce qui m’a particulièrement plu, c’est qu’ils ne parlent pas vraiment de leurs secrets de fabrication et de comment ils ont imaginé telle ou telle partie du jeu. Mais plutôt, ils parlent de toutes les idées qu’ils ont eu, qu’ils ont développé et qu’ils ont fini par abandonner. J’ai particulièrement aimé ces exemples de fausses fins (à 35 minutes dans la vidéo) :

A un moment, tôt dans la production, nous avions eu l’idée de disperser à travers le jeu des fausses fins. Ça nous est venu en regardant les sessions de tests de Portal 1. Il y a un moment aux environs des 2/3 du jeu où vous avancez sur une plate-forme qui se dirige vers un incendie. Vous êtes supposé vous en échapper et c’est là que vous rentrez en coulisse. Mais pour un petit pourcentage de testeurs, ça leur convenait parfaitement de rester sur la plate-forme et finir dans les flammes. C’était une bonne fin pour eux. C’était triste, mais ils aimaient ça. Ça finissait juste avec eux qui mourraient.

Alors on s’est dit qu’on pourrait faire plaisir à ces gens, et on avait disséminé à travers le jeu des endroits où Chell mourrait, ce serait la fin et on jouerait une chanson. Et si vous vouliez, vous pouviez vous arrêter là.

On en avait une au bout de quelque chose comme 2 minutes de jeu. Si vous mourriez là, il y avait une chanson (que Jay et moi chantions) qui passait en revue ces 2 premières minutes, et ce qu’il venait de se passer.

Puis plus tard dans le jeu, il y avait un passage où il y avait une fissure au plafond où vous pouviez voir la Lune. Vous pouviez placer un portail sur la Lune, et si vous en placiez un sur le mur, ça vous aspirait directement sur la Lune et vous vous asphyxieriez tout en écoutant une chanson triste sur la Lune. Et celle-ci marchait plutôt bien. Pour les gens qui la trouvaient, ce qui n’était qu’un petit pourcentage de nos testeurs, ils l’aimaient vraiment beaucoup.

Mais finalement on a laissé tomber ces fins alternatives. En partie parce que ça représentait beaucoup de travail pour peu de résultats. Mais aussi en partie parce qu’en dehors de ces deux fins, on avait un peu surestimé combien de fausses fins vraiment bonnes on pourrait arriver à imaginer.

Lors de la conception d’un projet, tout le monde va avoir des petites idées. C’est important de pouvoir expérimenter et tester ces idées et ces nouveaux concepts. Mais s’ils ne fonctionnent pas vraiment, ou pas aussi bien qu’on l’avait imaginé, c’est important de savoir abandonner ses idées. C’est difficile à faire, que ce soit parce que c’était une idée qui nous tenait personnellement à coeur, ou parce qu’on a passé beaucoup de temps à l’implémenter pour la tester. Mais il est toujours préférable d’avoir un produit avec une seule grande direction, plutôt que pleins de bonnes petites idées dispersées.

J’ai l’impression qu’il existe un sentiment assez étrange parmi certains développeurs qui ont passé les 10 dernières années à travailler sous Flash. Pour eux, HTML5 fait pâle figure comparé à tout ce qu’offre Flash. Pour eux, HTML5 est une véritable régression.

Je pense que HTML5 n’a pas besoin d’être meilleur que Flash sur tous les points pour le remplacer.

C’est assez courant dans le milieu high-tech. Une technologie supplante une autre, sans pour autant être meilleure sur tous les points. Pensez par exemple à la qualité audio médiocre d’un MP3 par rapport à celle d’un CD audio. Ça m’a particulièrement marqué il y a quelques années quand j’ai écouté en voiture l’album Illinoise de Sufjan Stevens, que je connaissais par coeur pour l’avoir écouté des centaines de fois sur mon ordinateur ou mon iPod. J’avais l’impression de redécouvrir l’album, et d’entendre clairement des instruments que je n’avais jamais entendu auparavant. Pourtant, à choisir, je préfère largement la flexibilité d’un fichier numérique à un CD audio.

Ce qui compte ce n’est pas forcément la technologie pour la technologie, mais la réponse qu’elle apporte aux besoins des vrais gens. Quand on s’en tient à certains points, HTML5 n’arrive pas à la cheville de Flash. Flash dispose de solides frameworks et environnements de travail (FlashDevelop, Adobe Flash IDE, Flex). Les dernières versions de Flash utilisent ActionScript 3, un langage puissant et orienté objet. Flash permets de faire des démos impressionnantes en 3D. Et jusqu’à il n’y a pas si longtemps, Adobe s’assurait de la gestion de la compatibilité entre appareils et navigateurs via son plugin Flash Player.

Mais ces points sont surtout importants pour les développeurs. Mais Monsieur Tout le monde, lui, s’en fiche pas mal de tout ça, de la même manière qu’il s’en fiche de la qualité absolue de la musique qu’il écoute. Sur Internet, je pense que l’accessibilité d’un site, la compatibilité entre appareils et navigateurs, la visibilité par des moteurs de recherche et la vitesse de chargement sont plus importants pour un utilisateur que des effets technologiques en-veux-tu en-voilà. S’il faut que ça passe par des publicités ou des démos interactives moins tape à l’oeil en HTML5 plutôt qu’en Flash, je pense que l’utilisateur final sera gagnant.

Nous sommes dans une période transitoire où les mêmes développeurs, les mêmes créatifs, les mêmes agences essaient de reproduire en HTML5 ce qu’ils avaient l’habitude de faire en Flash. C’est évidemment une erreur. Mais si ces agences essaient de comprendre ce qu’est le web, ce qu’est HTML5, ils arriveront à faire des sites meilleurs.

Vu via Hacker News sur le site du CERN : « La proposition de Tim Berner’s Lee« .

En Mars 1989, Tim Berners-Lee a soumis une proposition pour un système de gestion de l’information à son chef, Mike Sendall. « Vague, mais excitant » étaient les mots que Sendall a écrit sur la proposition, permettant à Berners-Lee de continuer.

Au fait, saviez-vous que bien qu’élaboré au sein des laboratoires Suisse du CERN, techniquement, le web a été inventé en France ?

Basé sur cette B.D. de Cyanide & Happiness et inspiré par ses parodies.