HTeuMeuLeu
Opera présente Coast, un navigateur sur iPad (et donc restreint à l’UIWebView et au moteur WebKit d’Apple). L’interface est bien polie avec de jolies animations un peu partout. J’ai fait une vidéo de quelques minutes du navigateur. J’adore l’utilisation d’une couleur propre au site détectée automatiquement avec la favicon au milieu pendant le chargement.
Sur le blog de l’agence Sud Africaine Flow Interactive :
Nous voyons souvent des équipes marketing demander des tas d’information pendant une inscription. « Comment avez-vous entendu parler de nous ? » « Quel est votre titre ? » (J’ai vu une liste de titre qui incluait non seulement monsieur, madame et mademoiselle mais aussi son altesse royale et amiral. Je ne plaisante pas.)
J’apprécie que les gens du marketing veulent savoir ces choses pour les aider à faire leur travail. Mais ajouter ces champs vous coûtera des utilisateurs. Voici donc un guide pratique pour décider de quels champs vous devez vous séparer…
Brad Frost, sur son blog :
Nous avons l’air de trous du cul.
La prochaine fois que vous vous trouvez intentionnellement en train de priver quelqu’un d’une expérience — pour acquérir une connaissance, compléter une tâche, pour faire quelque chose en ligne qui pourrait rendre leur vie ne serait-ce qu’un tout petit peu meilleure — imaginez vous debout devant cette personne dans la vraie vie, la regardant droit dans les yeux, puis fermement et sans le moindre doute, luire dire « Va te faire foutre. ».
Au cours de ces derniers mois, j’ai pris conscience d’un changement important en intégration : tout va très vite maintenant. Très, très vite. C’est quelque chose que je vois au jour le jour en faisant de la veille. Il ne se passe plus une semaine sans que je ne découvre une nouvelle propriété CSS fraîchement sortie des spécifications du W3C (bonjour :nth-match(), merci Kaelig) ou un nouvel outil pour concevoir du web (hello Sketch Mirror). Mais c’est surtout quelque chose qui a désormais un impact direct sur un projet web.
Prenons un petit projet web qui dure environ trois mois, entre la signature du projet et sa mise en ligne. (C’est optimiste, mais réaliste si votre client sait ce qu’il veut). En trois mois, vous aurez deux ou trois nouvelles versions de Firefox et Chrome. Ça signifie qu’entre le moment où vous commencez à concevoir votre projet, puis l’intégrez, puis le mettez en ligne, vous aurez deux à trois versions de navigateur de différence. Mais deux ou trois versions, ce n’est peut-être pas encore suffisant pour avoir des fonctionnalités radicalement différentes et impactantes.
Alors prenons un plus gros projet, qui durera environ un an. (Ce n’est probablement pas une bonne idée de démarrer un projet web en sachant d’emblée qu’il va durer aussi longtemps, mais ça peut aussi arriver par accident, par erreur d’estimation.) En un an, vous aurez environ huit nouvelles versions de Firefox et Chrome, une nouvelle version d’Internet Explorer et de Safari, une mise à jour majeure d’iOS, d’Android, de Windows, et d’OS X. C’est comme un paysage technologique totalement différent, apparu en un an. Ça ne signifie pas nécessairement une adoption aussi rapide auprès des utilisateurs.
Mais ça signifie que si vous faites un projet web prévu pour durer, vous avez grandement intérêt à vous projeter sur les futures versions de navigateur et d’en profiter pleinement. Je n’ai plus aucun scrupule à utiliser des animations ou des transitions CSS, du box-sizing ou des box-shadow, tant que ça respecte une dégradation gracieuse.
Ce week-end, j’ai regardé un chouette documentaire sur Arte intitulé « Mission Curiosity, le grand défi sur Mars« . J’ai particulièrement bien aimé ce passage où les ingénieurs de la NASA testent le parachute qui servira à ralentir la chute de Curiosity sur Mars.
Il ne doit pas y avoir beaucoup de métiers où des mecs se réjouissent autant d’avoir détruit un parachute qui vaut surement plusieurs dizaines de milliers de dollars.
Mais ça m’a forcément rappelé mon métier d’intégrateur. Cette frustration de ne pas réussir à reproduire un bug qu’on m’a envoyé. « Chez moi ça marche, alors essaye de vider ton cache, remettre le zoom par défaut du navigateur, désactiver tous les plugins, redémarrer, ou je sais pas, moi, formate Windows… « . Ça sonne souvent comme une excuse de développeur pour ne pas s’embêter à creuser le problème, mais je vous assure que c’est compliqué.
Si coder c’est 90% de débuggage et 10% d’écriture de bugs, alors tester c’est 10% du temps passé à s’assurer que ça marche dans les bons cas, et les 90% restants à essayer de faire planter son code coûte que coûte.
Il y a quelques mois, Brent Simmons écrivait un superbe article rendant hommage à son testeur préféré :
Durant ma récente conférence à AltWWDC, on m’a demandé ce qui faisait une bonne personne en Assurance Qualité. Je crois que j’ai répondu « l’acharnement ». Ce qui dans mon propre lexique est une éloge.
Voici le truc concernant Nick : il est convaincu qu’il y a un autre bug. Et il va continuer à chercher jusqu’à ce qu’il le trouve. Et, une fois qu’il l’aura trouvé, il sera convaincu qu’il y a un autre bug.
Il utilise plusieurs doigts (j’aime imaginer qu’il a une main coupée qu’il garde au chaud juste pour ça) et il passe un appel et remarque le moindre pixel décalé. Puis il écrit de bons rapports de bugs avec les étapes pour le reproduire, souvent des captures d’écran, et parfois même avec une vidéo.
Voilà ce qui fait une bonne personne en Assurance Qualité. Les meilleurs sont de macabres personnages qui se réjouissent de torturer des développeurs, mais qui sont aussitôt pardonnés par la concision et la précision de leurs rapports de bugs.
Il y a dix jours, je suis tombé via Twitter sur la carte des navigateurs Internet sur le site de L’Express. Ça m’a paru étrange, car les statistiques présentées ne ressemblent pas du tout à ce que j’avais en tête pour ces derniers mois. L’Express attribue la carte au site BoredPanda, qui lui-même attribue la carte à un utilisateur de DeviantArt, qui lui-même attribue la carte aux données de StatCounter, datées de 2012.
Les statistiques des navigateurs sont en général à prendre avec de très grosses pincettes, en particulier lorsqu’elles viennent de StatCounter. Néanmoins, elles permettent quand même d’entrevoir certaines tendances mondiales sur le marché des navigateurs. L’année dernière, StatCounter avait publié une vidéo présentant l’évolution du marché des navigateurs par pays de 2008 à 2012. J’adore ce genre de visualisation. En regardant de plus près l’évolution des statistiques par pays depuis la publication de cette vidéo, je me suis rendu compte d’un changement assez impressionnant qui s’est produit au cours de l’année passée. J’ai donc pris des captures d’écran des cartes de StatCounter des soixante derniers mois, et voici le résultat.
En cinq ans, on est passé d’une planète toute bleue (sous Internet Explorer) à une planète toute verte (sous Chrome). Ça fait déjà un moment que StatCounter annonce que Chrome est le navigateur le plus utilisé au monde (déjà en 2011, puis à nouveau en 2012). Les données globales de NetMarketShare sont loin de corroborer cette information. Pourtant, j’ai de mon côté bien constaté une prise de première position flagrante par Chrome ces derniers mois sur des sites de clients.
Plus je fais mon bonhomme de chemin en tant qu’intégrateur, et plus je me rends compte qu’une différence majeure entre un intégrateur débutant et un intégrateur avec un peu plus de bouteille réside dans la confiance accordée à du code externe. Là où un intégrateur débutant va concevoir un site comme un assemblage de plugins et de bouts de codes trouvés sur le net, un intégrateur expérimenté s’en méfiera comme de la peste, à la limite du syndrome NIH. Plus j’avance et plus je me rends compte que la plupart du temps, il n’y a pas besoin de plugin pour faire quelque chose. Au contraire.
Récemment un collègue est tombé sur une page d’un site client qui déclenchait une action au bout d’une seconde. Il est resté bloqué deux secondes en lisant le code car le code JavaScript utilisait une fonction doTimeout, et pas la fonction native en JavaScript setTimeout. Il s’avère que doTimeout est un plugin jQuery dont la baseline est « Comme setTimeout, mais en mieux« . Et par mieux, ça veut surtout dire que ça fait exactement la même chose que la fonction setTimeout, mais avec une syntaxe proche de jQuery, avec la possibilité de chaîner les fonctions. C’est bien, mais dans 99% des cas ce n’est pas utile, et ça ne l’était certainement pas dans ce cas précis. Et pourtant ça a été appelé sur cette page, avec le Ko et la requête HTTP supplémentaire que ça impose. Ce n’est pas beaucoup 1 Ko. Mais 1 Ko pour écrire en jQuery ce qui aurait pu s’écrire en une ligne de JavaScript, c’est beaucoup.
Ça m’a rappelé mes premières années, quand on parlait de DHTML, de Scriptaculous, de Prototype, mais pas encore de Mootools ou jQuery. J’avais fini l’intégration d’un site. Le chef de projet commence à recetter, et tout de suite m’interpelle.
Le chef de projet : Les sous-menus ne fonctionnent pas.
Moi : Euh… Quels sous-menu ?
Je n’étais pas au courant qu’il devait y avoir des sous-menus. Ça n’avait été spécifié nulle part. Et apparemment, ce n’était pas utile parce que le directeur technique avait dit qu’il y en avait des tout fait très bien. Me voilà donc en urgence en train d’essayer d’installer un sous-menu, avec des compétences en JavaScript alors proches du néant. Je galère, je tâtonne, et puis je finis par avoir quelque chose de fonctionnel. Mais ça n’avait rien de qualitatif (dans la mesure où l’on peut quantifier la qualité d’une intégration). Et surtout j’avais l’impression de n’avoir rien appris. Oui, je savais désormais mettre en place un menu avec cette bibliothèque JavaScript en particulier. Mais ça ne m’aidait pas plus à comprendre le fonctionnement de base de JavaScript et du parcours du DOM.
Un an plus tard, après avoir fait quelques pas supplémentaires en JavaScript, je devais à nouveau intégrer un menu supplémentaire. Et cette fois-ci, j’ai décidé de me lancer, avec mon code HTML et Mootools. Et là j’ai réalisé à quel point la mise en place d’un tel menu était ridiculement facile (en particulier avec un framework de parcours de DOM qui évite du code un peu verbeux). En quelques lignes, j’avais reproduit le fonctionnement que j’avais eu du mal à obtenir un an plus tôt. Et c’était un sentiment enivrant de liberté, un peu comme faire du vélo pour la première fois sans roulettes. Et aussi l’impression d’avoir perdu un temps à courir après le bon plugin ou la bonne bibliothèque qui fait exactement ce qu’on recherche, alors que le faire de zéro demandait autant voire moins de temps pour un enrichissement personnel bien plus grand.
Loin de moi l’idée de vouloir bannir strictement tout code tiers, il est important de réaliser que les problèmes résolus par des plugins n’ont souvent pas grand chose à voir avec les problèmes que vous essayez de résoudre.
Parmi les détails qui font ou défont l’expérience utilisateur d’un site web, je suis convaincu que le chargement d’une page joue un rôle très important. Bien sûr, il faut que votre site se charge rapidement. Mais même en se chargeant rapidement, certains détails peuvent trahir le manque d’attention porté à l’intégration d’un site.
Voici un exemple sur lequel je suis tombé ce week-end. Il s’agit d’un simple article sur Fast Company. Voici une vidéo du chargement sur mon iPad mini.
Avec un poids total de près de 2 Mo et plus de 150 requêtes, cette page n’est clairement pas un modèle d’optimisation. Un test sur WebPageTest confirme qu’il y a du travail. Mais au delà d’une recherche de performance pure et dure, voici ce qui m’intéresse côté expérience utilisateur.
C’est plutôt atroce, non ? Et encore, c’est pourtant un large progrès comparé à six mois plus tôt. Quand j’ai écrit « Ta page charge. Ce n’est pas sale.« , le site masquait totalement l’affichage de la page pendant son chargement. Cet exemple semble peut-être exagéré, mais je pense qu’il assez emblématique de ce que l’on rencontre de plus en plus.
Voici quelques observations pour améliorer l’expérience du chargement de son site :
La semaine dernière, Raphaël Goetter implorait sur son blog la mort d’IE8 :
Nous sommes en juillet 2013 et Internet Explorer 11 va sortir dans quelques jours, plein de promesses.
En attendant, son arrière-grand-père IE8 continue à être très prisé dans certains milieux (et je ne parle même pas de IE6 !).
Juste pour vous faire baver un peu, voici une petite liste non exhaustive des fonctionnalités (propriétés, valeurs et fonctions) CSS3 que l’on pourra employer à tour de bras dès que IE8 ne figurera plus dans nos cahiers des charges.
Je suis tout à fait d’accord dans l’idée de voir décéder IE8. Par contre, de mon point de vue, je ne souhaite pas nécessairement voir IE8 mourir pour pouvoir utiliser de nouvelles propriétés. Avec un principe de dégradation gracieuse, on peut déjà utiliser depuis un bon moment en production des media queries, box-shadow, transforms, border-radius, opacity, et j’en passe.
J’aime bien la philosophie de Kévin Rocher sur le support des anciennes versions d’IE (lue sur le blog de son stagiaire) : « fuck ie6, ie7 vaguement navigable, ie8 navigable. ie9 propre. » À moins de ne chercher à faire du pixel perfect, IE8 n’est plus vraiment un problème.
Pour moi, la disparition d’IE8 serait une bonne chose car IE8 est le dernier survivant d’une espèce de navigateurs en voie de disparition : les navigateurs liés au système rarement mis à jour et avec une adoption très très lente. D’un côté, il y a les navigateurs non liés au système, comme Chrome et Firefox, qui eux seront mis à jour toutes les six semaines. Et de l’autre côté, il y a les navigateurs liés au système comme Internet Explorer et Safari, mais qui dans le premier cas a droit à des mises à jour automatique, et dans le second profite de l’adoption très rapide des dernières versions de l’OS.
Si on reprend les chiffres douteux de StatCounter, ça signifie qu’aujourd’hui, 80% des navigateurs utilisés en France ont moins d’un an. Ça a de quoi donner foi au futur du web et du métier d’intégrateur.
Le mois dernier j’ai eu la chance de séjourner à New York City. Au hasard de mes trajets en métro, je suis resté bloqué sur cette publicité :
Vous devez serrer dans vos bras et embrasser vos enfants.
Les mots ne suffisent pas.
Ça m’a semblé bizarre. Je n’ai pas d’enfants, mais cela m’a semblé être une évidence, un comportement des plus basiques à adopter. Bien sûr que vous devez faire des câlins et embrasser vos enfants. Il se trouve que cette publicité fait partie d’une campagne de 2008, « 10 façons d’être un super papa« , incitant d’autres comportements « basiques », comme écouter son enfant, manger ensemble, passer du temps ensemble… Cependant, je conçois que la vie de parent ne doit pas être toujours facile, et que ces rappels peuvent être utiles.
En parlant de rappel utile, je suis retombé ce week-end sur cet excellent article de Dustin Curtis sur les crash aériens, « Pilotez l’avion« . Il revient notamment sur les explications du crash du vol Air France 447 en plein océan atlantique en 2009 :
Peu après que le problème initial de capteur de vitesse ait été résolu par les systèmes anti-gel inclus dans l’avion, l’AF447 était un avion parfaitement opérationnel. Chaque instrument fonctionnait parfaitement. Il volait à une altitude sans danger. Si les pilotes avaient appuyé sur quelques boutons pour ré-activer le pilote automatique, tout le monde à bord aurait survécu. Mais ils ne l’ont pas fait. L’un des co-pilotes a fait une seule erreur absurde, pendant quatre minutes et vingt-trois secondes, qui a fait chuter l’avion.
Ce genre de défaillance humaine est plutôt courante; ce genre d’en apparence stupides décisions impossibles sont faites tout le temps dans des situations catastrophiques. J’ai déjà vu la panique s’installer quand les serveurs d’une startup sont tombés, par exemple, amenant les ingénieurs à passer à côté de choses simples dans leur confusion. J’ai déjà senti cette force écrasante quand j’ai fait de grosses erreurs.
À chaque fois que je lis ou vis l’une de ces situations, je me souviens d’une histoire que j’ai lue dans The Checklist Manifesto sur les listes de vérification en cas de panne moteur sur un avion Cessna à un seul moteur. La liste comporte six étapes cruciales, comme par exemple s’assurer que les vannes de carburant sont ouvertes et que la pompe du réservoir de secours est activée. Mais la première est fascinante. C’est simplement pilotez l’avion. Dans la confusion causée par la perte d’un moteur, les pilotent paniquent souvent et oublient les choses les plus évidentes qu’ils devraient faire. Ça semble totalement inutile, mais cette étape assure la meilleure chance de survivre.
Je suis parfois surpris de certains commentaires sur des articles rappelant des bases, évoquant parfois la tristesse d’avoir à rappeler ces bases, parfois une pointe de condescendance, mais parfois tournant limite au lynchage public.
Plus je travaille en tant qu’intégrateur ou plus généralement en temps que concepteur web, et plus je réalise à quel point il est indispensable de rappeler les bases, que ce soit avec des clients néophytes ou des collègues avertis, et que ce soit dans des moments calmes en pré-conception ou dans des moments d’urgence une fois un site en production.
Ce midi je suis tombé sur cette infographie dans l’édition du jour du 20 minutes :
Je suis bien resté cinq minutes à chercher le sens et l’intérêt de cette infographie, et surtout quelle information j’étais censé en retirer. Et je n’ai pas trouvé de réponse. Sébastien Desbenoit appelle ça une VIDANJ : « Visualisation de Données Accompagnant un Néant Journalistique. » J’aime bien cet acronyme.
Mais surtout j’adore cette infographie. Mais pas dans le bon sens du terme. Voici quelques points que j’ai relevé :
Tout ça m’a fait repensé à une conférence que j’avais adoré, d’Irene Ros à la Take Off Conference à Lille en janvier dernier : Responsible use of data visualization. Et en particulier cet exemple (à 18 min) :
Un autre exemple rigolo, c’est de mal représenter des données. Tout le monde aime les infographies. Mais ici c’est un peu une véritable boucherie d’infographie.
Ils comparent le chiffre d’affaire annuel et les dépenses publicitaires entre Coca-Cola et Pepsi Cola. Et ils utilisent des camemberts pour ça. Il n’y a aucune raison à ça. Ça veut dire quoi 35,2 milliards de dollars… d’une capsule ? Et il n’y a aucune relation entre la taille des deux données comparées. Remarquez comme les 1,1 milliards de dollars sont plus gros que les 35,2 milliards de dollars. Et je ne suis pas sûr s’il faut que je regarde l’espace vide ou alors l’espace plein.
Ce qu’ils auraient dû faire, c’est plutôt ça.
Non seulement maintenant vous pouvez vraiment comparer visuellement les deux sociétés. Mais vous pouvez aussi comparer les deux catégories. C’est probablement plus important que de voir une capsule en 3D.
Hier, j’ai vu chez Badsender cet exemple édifiant de newsletter :
Chaque jour, l’objet de la newsletter envoyée par Libération est invariablement le même : « Le point de l’actualité du + DATE + au matin ».
Pourquoi ce qui est impensable avec la version papier du quotidien devient possible avec l’email ? Pourtant, la newsletter de Libération génère probablement un traffic considérable sur son site internet. Un traffic indispensable à la monétisation digitale du quotidien. Alors pourquoi ne pas optimiser ? Pourquoi cette paresse ?
C’est complètement fou. Le premier contact que n’importe quel abonné aura avec cette newsletter, la première information qui sera lue, chaque matin, sera totalement dénuée d’intérêt. (C’est aussi utile qu’un fichier appelé « style.css« .) Jamais un grand quotidien national n’irait occuper la plus grande partie de sa une avec la date du jour dans « la vraie vie ».
C’est le genre de pratique qui me rend fou, un peu comme les popups bloquantes à l’arrivée sur un site vous demandant vos coordonnées, un like ou un ticket restaurant, à votre bon coeur. Jamais un commerçant dans « la vraie vie » n’irait vous demander vos coordonnées dès votre entrée dans sa boutique. Il y a un temps pour tout.
Cela me rappelle certains exemples donnés par Charles de UXUI dans son article sur 24 jours de web, « Les concepteurs de sites internet ne sont pas (tous) des utilisateurs comme les autres » :
Une bannière publicitaire pour la gendarmerie sur le site de La Redoute ? Le concepteur salue un placement ambitieux, l’utilisateur se demande s’il existe un rapport entre le manteau qu’il venait chercher et ce gendarme qui lui sourit (et qui ne porte même pas de manteau.)
Vous imaginez rentrer dans une boutique de prêt à porter dans « la vraie vie » et être accueilli par une escouade de gendarmerie, présente pour recruter ? Ce serait fou.
Et je ne parle même pas des sites qui bloquent activement leurs utilisateurs sur des critères purement physiques, brillamment recensés sur WTF Mobile Web :
Feeling emasculated.
Come back when you have a bigger screen.
Vous imaginez rentrer quelque part dans « la vraie vie » et vous faire gentiment éjecter parce que vous êtes trop petit, trop grand, pas « bien comme il faut » ? Non merci.
Google avait magnifiquement illustré tout ça dans cette vidéo il y a deux ans :
En plus de respecter la loi des titres de Betteridge, « Le feriez-vous dans la vraie vie ? » est une bonne question à se poser lors de la conception d’un site web. Parce qu’au cas où il serait nécessaire de le rappeler : le web, c’est aussi « la vraie vie ».
Hier, Mozilla a annoncé la sortie officielle de Firefox OS ainsi que les premiers smartphones officiels à destination du grand public. Le ZTE Open est disponible dès aujourd’hui en Espagne chez Telefónica pour 69€. Le Alcatel One Touch Fire sera dévoilé plus en détail le 11 juillet en Pologne chez Deutsche Telecom.
C’est un grand événement pour Mozilla, et peut-être pour l’avenir du web tout entier. Et pourtant, j’ai toujours du mal à croire en Firefox OS. Il y a à mon avis deux façons de voir Firefox OS.
Il y a quelques mois, je parlais de Firefox OS autour de la citation « Vous pouvez mourir en héros ou vivre suffisamment longtemps pour vous voir devenir le méchant ». Les choses ne se sont pas améliorées depuis, et Firefox OS ressemble de plus en plus aux méchants Apple et Google que certains membres de Mozilla se délectent de critiquer. Pour lancer Firefox OS, Mozilla s’est associé à Foxconn, cette usine « d’animaux » et d’enfants, comme Apple et Google. Sur le marketplace de Firefox OS, les applications web sont soumises à validation, comme sur l’App Store ou Google Play. Et puisqu’il est basé entièrement sur des applications web tournant sur le moteur de rendu Gecko de Mozilla, Firefox OS interdit de facto à tout autre fabricant de navigateur de s’installer sur son système. De la part de Mozilla qui a lutté des années contre le monopole de Microsoft, ça fait tâche.
J’entends aussi souvent répété l’argument de l’ouverture de Firefox OS qui suffirait à assurer le succès du système, comme ça a été le cas pour Firefox. Selon moi, si Firefox a été un succès, c’est parce que c’était un bon produit. De ce que j’ai pu voir jusqu’à présent de Firefox OS, ou essayer via le simulateur ou le Geeksphone Peak acheté au boulot, Firefox OS n’est pas (encore) un bon produit. Le fait que l’application Mail n’arrive pas (encore) à afficher correctement un mail HTML n’y est peut-être pas pour rien. (Pour un OS dont le point fort est censé être son moteur de rendu web, ça fait un peu tâche quand même.)
Mais ce n’est surement pas la bonne façon de voir Firefox OS. Comme le rappelait hier Christian Heilmann (développeur évangéliste chez Mozilla), l’objectif de Mozilla est aussi de proposer un accès au web à des marchés émergents. Et c’est là où je commence à reprendre foi en Firefox OS. Il y a aujourd’hui 2,5 milliards de personnes ayant accès à Internet. Ça signifie qu’il y a encore 4,5 milliards de personnes à inviter à nous rejoindre. En octobre dernier, la CNN titrait « L’Afrique n’est pas juste un continent mobile-first, c’est mobile-only » :
Il y a plus de gens en Afrique qui ont un téléphone mobile que de gens ayant accès à l’électricité.
La perspective que Mozilla arrive à s’imposer dans ces pays, offrant un accès au web à encore plus de monde me semble bien plus excitante que toute autre paluchage devant des spécifications techniques ou des technologies web en cours de standardisation. Et c’est pour ça que même si j’ai du mal à croire en Firefox OS, j’espère de tout coeur que Mozilla réussira sa mission.
Alors bienvenue au monde et bonne chance, Firefox OS.
La semaine dernière, j’ai lu l’avis de Nicolas Hoffmann sur le livre Projet Responsive Web Design sorti récemment chez Eyrolles. J’ai beaucoup aimé :
Ce livre confirme une fois de plus ce que je constate (et je ne suis pas le seul) depuis plusieurs années : l’intégrateur (ou le développeur front-end) devient une pièce majeure de l’équipe Web. J’avais déjà écrit « de l’intégrateur au développeur front-end… » sur OpenWeb, ce livre appuie et explique très bien cet état de fait, à travers le Responsive Web Design donc.
Pas plus tard que ce matin, je travaillais à l’intégration sur un projet en Responsive Web Design, et je peux vous assurer que la personne vers qui tous les acteurs se tournent durant ces projets, c’est l’intégrateur et pas un autre. Le rôle est vraiment central.
Aujourd’hui, sur le blog de DarkLg, Pourquoi un (bon) intégrateur est indispensable à tout projet web :
Voici quelques raisons pour lesquelles je pense qu’un bon intégrateur est indispensable à tout projet web :
- Il est souvent le premier technicien sur le site, et est donc le premier à constater des erreurs de conception, ou des éléments qui ne pourront pas être administrables.
- Il fera la différence entre une erreur de DA et une subtilité à mettre en place.
- Il saura optimiser les performances Front-End de vos sites.
…
J’aime beaucoup ces deux articles. Alors oui, les intégrateurs parlent aux intégrateurs, et nos avis sont forcément un peu biaisés. Mais ces discours sur l’importance et l’indispensabilité de l’intégrateur (et intégratrice) me parlent beaucoup.
Ces derniers mois, j’ai travaillé sur la refonte de l’espace client d’une marque. J’ai travaillé principalement avec les développeurs, les directeurs et chefs de projet techniques, mais aussi de manière plus ou moins directement avec les responsables marketing et communication. C’est une « petite » équipe d’une vingtaine de personnes, qui travaille sur des projets web depuis des années. Et pourtant, avant ce projet, ils n’avaient jamais travaillé avec des intégrateurs. Jamais jamais. Auparavant, les développeurs s’occupaient tant bien que mal de bidouiller du HTML et du CSS pour arriver à quelque chose d’à peu près ressemblant aux maquettes. Ça peut paraître totalement fou quand on travaille en agence, où le métier d’ intégrateur est plutôt bien rentré dans les mœurs. Mais ce n’est pourtant pas la première fois ces dernières années que j’ai eu l’occasion d’évangéliser le rôle de l’intégrateur auprès de grandes marques, aux processus très lourds et bien rodés. Et à chaque fois, ça a été la même réaction : une bouffée d’air frais. Finis les aller-retours incessants avec les équipes créa pour changer un s sur une maquette. Finies les journées entières perdues par les développeurs à essayer de comprendre les méandres d’Internet Explorer.
Mais cela semble évident. Un bon intégrateur fera du bon boulot en intégration, tout comme un bon référenceur fera du bon boulot en référencement, ou un bon webdesigner fera du bon boulot en coloriage.
Mais ce qui est important, et qui me semble encore assez nouveau dans les mentalités, c’est qu’un bon intégrateur joue un rôle crucial dans la qualité globale d’un projet web, en pouvant apporter des conseils avisés sur toutes les facettes d’un projet, dès sa conception.
L’intégration, ce n’est pas l’exécution du webdesign. Et si vous vous trouvez dans une salle de réunion pour un projet web sans aucun intégrateur, vous êtes sur la mauvaise voie.
Hier matin, j’ai eu la surprise en arrivant au boulot de suivre un véhicule roulant à contre-sens. Ce n’est pas la première fois que ça m’arrive à cet endroit précis. Je me suis même déjà retrouvé nez à nez devant un véhicule roulant à contre-sens (je l’ai joué à la dégonfle au volant de ma Twingo, le conducteur en face a tout de suite vu à qui il avait affaire). Voici la rue en question, suite à des récents travaux.
Il s’agit à la base d’une route à quatre voies, dont deux réservées aux bus. Puis il y a un passage piéton et une intersection avec des pavés. Puis la route est réduite à trois voies, avec plus qu’une seule voie de bus. Puis la route est à nouveau réduite à deux voies. Voici un plan reconstitué par mes soins.
A chaque fois, le problème s’est passé au passage de l’intersection, du point A au point B sur mon illustration. Plutôt que de continuer tout droit, le véhicule au point A se décale d’une voie pour se retrouver alors au point B, à contre-sens. Le marquage au sol est pourtant assez clair
J’ai moi-même eu un moment d’hésitation la première fois que j’ai emprunté cette nouvelle route. Et je pense que ces erreurs sont facilitées par trois indices visuels :
Pour éviter ça, je pense qu’un simple panneau indiquant le nombre et le sens des voies suffirait (même si du coup ça fait un peu porte de Norman et que ça ne résout pas vraiment le problème de base de cette route).
Cette petite tranche de vie m’a rappelé un article vu le mois dernier sur Twitter, « Opodo : le bouton qui fâche« , rapportant un test utilisateur :
Lors de ce test nous avons demandé aux participants de réserver le voyage de leur choix. Vous allez voir dans la vidéo ci-dessous une utilisatrice qui filtre les résultats en utilisant certains critères (destination, durée, budget…) mais une action inattendue se produit :
Après avoir cliqué sur le bouton « Supprimer tous les critères » (00:35) l’utilisatrice ne comprend pas pourquoi ses choix se sont effacés. Le libellé du bouton est pourtant clair, alors pourquoi cette erreur ?
Dans cet exemple, comme dans mon exemple de contre-sens, il s’agit d’une erreur particulièrement grossière. Et pourtant, si elle se produit, ce n’est pas parce que les gens sont particulièrement idiots, mais bien parce qu’il y a un problème de design.
Le langage HTML.
L’optimisation pour le SEO.
Le protocole HTTP.
Une feuille de styles CSS.
Le format PDF.
Le format GIF.
Le format TIFF.
Le référentiel RGAA.
Je n’aime pas beaucoup me répéter. Alors à chaque fois que j’emploie une des expressions ci-dessus, je grince un peu des dents. (Et c’est pire en anglais.)
Il y a eu un sacré paquet d’articles sur l’utilisation de Photoshop pour le web ces derniers mois. À l’heure où l’on est supposé épouser une diversité incroyable d’appareils, je suis convaincu que le design sous Photoshop n’a plus vraiment sa place.
Je crois que les discussions ont commencé suite à cet excellent article de Brad Frost en janvier dernier sur « L’ère post-PSD » :
Tout au long de ma carrière, j’ai vu des graphistes immensément talentueux perdre une montagne de temps à créer des maquettes complètes de ce à quoi un site web pouvait ressembler. On pousse des pixels, on sue sur des détails, les pages sont imprimées, accrochées sur des murs, et présentées à des clients. Les clients braillent leurs retours, les graphistes exécutent. Ils répètent cette danse jusqu’à ce que tout le monde soit content (ou jusqu’à ce que personne n’en ait plus rien à faire, ce qui arrive plus souvent que vous ne le croiriez). Et seulement à ce moment ces sacro-saintes maquettes sont transmises (ou plutôt balancées) aux développeurs pour les construire.
C’est un processus de plus en plus pathétique qui a de moins en moins de sens dans ce monde et cette époque multi-appareils. Je ne plaide pas pour abandonner complètement Photoshop et faire du design uniquement dans le navigateur (ils sont où déjà les modes de fusion dans les outils de développement de Chrome ?) mais plutôt pour une meilleure compréhension de comment utiliser Photoshop pour du web design moderne.
Je pense que « pathétique » est le bon mot. On vient de passer les vingt dernières années à tenter de faire du print sur le web. Il est temps que ça change.
Afin de palier aux faiblesses techniques de Photoshop, certains prêchent l’utilisation d’autres logiciels, comme Sketch par exemple. C’est déjà un bon premier pas pour s’éloigner du Bitmap de Photoshop vers du vectoriel, plus proche de la nature du web. Mais à chaque fois, la réaction d’une partie de la petite communauté de Directeurs Artistiques sur Twitter est la même : « Comment osez-vous nous imposer un logiciel pour faire du design ? Nous on ne vient pas vous dire dans quel logiciel travailler. » C’est touchant, mais c’est pourtant exactement ce qui se passe.
En travaillant sous Photoshop, vous imposez à toute votre chaîne de production d’en faire autant. Parce que le format PSD est une véritable abomination, Adobe s’assure à chaque mise à jour qu’il reste inutilisable de manière fiable sous tout autre logiciel (coucou les dossiers de calques qui sautent dans Pixelmator ou Gimp). Photoshop est aussi un outil particulièrement atroce à utiliser pour de l’intégration. Certains plugins comme CSS Hat ou Slicy (anciennement Layer Cake) tentent de rendre la tâche moins pénible, on est encore loin d’un véritable outil pensé pour de l’intégration. Et même si des logiciels comme Sketch améliorent cette situation, je ne suis pas sûr que remplacer Photoshop par un autre logiciel propriétaire ne soit la solution.
J’aime bien la vision de Ryan Singer abordée lors d’une séance Play by Play sur le prototypage d’interface : « Photoshop est juste un outil — de la même manière qu’un croquis — pour retirer le doute sur une idée. »
Que ce soit pour de l’intégration ou du design, j’utilise Photoshop ou Pixelmator comme si j’étais dans une épreuve de Fort Boyard : une fois rentré, mon but est d’en sortir le plus rapidement possible avec la réponse à ce que je suis venu chercher.
Il y a quelques années on faisait des sites complets en Flash. Aujourd’hui on maquette encore des sites complets sous Photoshop. Il est temps que ça change. Comme dans le cas des pré-processeurs, je pense que le problème n’est pas l’outil qu’on utilise, mais ce qu’on en fait. L’après Photoshop n’arrivera qu’une fois qu’on se sera débarrassé de cette vision print du web.
Je regarde beaucoup de conférences, et il y a des tas de gens que j’admire vraiment. Et puis il y a Bret Victor. Comme le disait Irene Ros à TakeOffConf à Lille en janvier dernier, « aucune conférence ne devrait se passer sans citer Bret Victor ». J’avais été bluffé par sa conférence « Inventing on principle » l’année dernière. Cette semaine, une nouvelle vidéo d’une de ses conférences au SIGGRAPH de San Francisco en mai 2012 a été mise en ligne : « Arrêtez de dessiner des poissons morts ».
Ceci est ce que Magritte appelle « la trahison des images ». Ceci n’est pas un poisson. C’est une image d’un poisson. C’est une représentation visuelle d’un poisson. Si j’avais dessiné ça sur papier, ce serait une plutôt bonne représentation d’un poisson. Si vous ouvriez un livre que vous tombiez sur ce dessin, vous vous diriez « oui, il y a une image d’un poisson dans mon livre ». Ça capture toute la « poissonitude » que l’on peut capturer à travers un media papier. Mais ceci n’est pas du papier, c’est un nouveau média. Et dans ce média, c’est une très mauvaise représentation d’un poisson. Ça ne ressemble pas du tout à un poisson.
Les poissons sont tout le temps en train de bouger. Si vous regardez un poisson, il fera surement des aller-retour, il bougera son corps d’avant en arrière, remuant sa queue. Les poissons sont tout le temps en mouvement. Dans un média où nous nous attendons à voir du mouvement là où il y a du mouvement, ceci ne ressemble pas du tout à un poisson vivant. C’est une bonne image pour un poisson mort. Et si vous voulez dessiner un poisson mort, Photoshop est un super outil. Tout ce que vous allez dessiner dans Photoshop sera complètement mort, totalement statique, pas du tout en mouvement.
Mais je ne veux pas dessiner un poisson mort, je veux dessiner un poisson vivant.
Le parallèle avec le web n’est pas trop difficile à faire. Et c’est ainsi qu’il commence à animer son poisson sur son interface faite-maison avec deux iPad reliés en Bluetooth. Les différents concepts d’interface qu’il présente font vraiment toujours autant envie. Surtout, il argumente avec précision pourquoi, d’après lui, taper du code n’est pas adapté pour faire de l’animation.
La deuxième raison pour laquelle je pense que coder est inapproprié pour créer des arts graphiques vient de la relation entre un langage et la compréhension visuelle. Du code, c’est du langage. Nous codons dans des langages de programmation. Nous pensons de manière linguistique lorsque nous codons.
Dans une large mesure, la seule raison pour laquelle des artistes créent des arts graphiques est pour exprimer quelque chose qu’ils ne peuvent pas exprimer avec un langage. Les artistes dessinent parce qu’ils veulent transmettre quelque chose qu’ils ne peuvent pas décrire. Les mots « nuit étoilée » ne décrivent pas « La nuit étoilée« .
Si je suis un fervent défenseur de la conception web la plus proche possible d’un navigateur, je suis tout à fait d’accord que du code n’est pas le bon outil pour de la création graphique. Nous sommes dans un état d’esprit différent lorsque nous codons et lorsque nous sommes devant une toile vide sous Photoshop.
Sa conclusion est précise et ambitieuse :
La principale chose que je veux que vous retiriez de cette conférence, c’est de l’insatisfaction.
Je veux que vous rentriez chez vous, que vous ouvriez Photoshop et que vous ressentiez que vous dessinez des poissons morts. Je veux que vous ressentiez à quel point tout ce que vous dessinez est plat, statique et sans vie. Quand vous créez des animations, je veux que vous ressentiez à quel point c’est froid et mort, comment vous ne pouvez pas jouer avec. Je veux que vous ressentiez tout ce qui nous manque, en utilisant ce média pour simuler d’autres médias. En définitive, je veux que vous ayez des standards plus élevés pour ce média.
Il y a un an et demi, j’ai acheté ma première voiture. Je n’avais jamais eu besoin d’un véhicule auparavant. J’habitais sur Lille et les transports en commun me permettaient de me rendre à mon travail et d’être indépendant 95 % du temps. Et puis j’ai déménagé à 50 Km de mon lieu de travail. À moi les joies du TER, de ses retards quotidiens, de ses grèves trimestrielles et de l’angoisse constante d’arriver en retard le matin et de ne pas pouvoir rentrer chez moi le soir. Alors j’ai décidé d’acheter une voiture.
Le problème, c’est que j’y connais rien en automobile. J’écoutais attentivement les conseils de mon entourage, mais chacun y allait de sa propre expérience se contre-disant les unes des autres. « Avec les kilomètres que tu vas faire, il te faut un diesel ! » « Prends plutôt une essence, c’est moins cher et de toute façon le carburant est quasiment au même prix. » « Achète français, ça coûte moins cher à l’entretien. » « Achète japonais, ils font les meilleurs moteurs et ça demande moins d’entretien. »
Je n’avais pas la moindre idée de ce qui pouvait être important d’avoir dans une voiture, mais j’avais quelques contraintes. Je souhaitais un véhicule pour une utilisation occasionnelle, environ une fois par semaine. Je n’avais pas de budget précis en tête, mais je souhaitais pouvoir payer cash, sans faire de prêt. J’en avais aussi besoin assez rapidement, mais je n’avais pas beaucoup de temps à y consacrer. Et surtout, je devais pouvoir me rendre facilement seul chez le concessionnaire de la voiture de mes rêves. C’est bête, mais quand on n’a pas de voiture, c’est tout de suite très compliqué de se rendre chez des concessionnaires placés à l’extérieur des agglomérations.
Alors j’ai acheté ce petit bolide.
Oui, une Twingo. Je peux désormais me vanter d’avoir une voiture de ministre.
Au début, tout allait bien. Ma Twingo et moi vivions un amour fou. Elle me convenait très bien pour une utilisation hebdomadaire. Et puis petit à petit, j’ai commencé à l’utiliser un peu plus, et à prendre le train moins souvent. Et puis la SNCF a enchaîné les retards, grèves et autres perturbations, et j’en ai eu marre. Et j’ai fini par prendre la route tous les jours, et ne plus jamais prendre le train.
Et là, forcément, la Twingo n’est pas forcément la voiture idéale pour avaler 100 Km d’autoroute par jour. Alors je recherche actuellement une nouvelle voiture. Une voiture plus confortable, dans laquelle je serais prêt à passer deux heures par jour. Et puis bien équipée, où je pourrais facilement relier mon téléphone pour y écouter ma musique, des podcasts, etc. Si j’ai toujours des tas de questions qui me trottent à l’esprit, l’expérience de mon premier achat me permet d’aborder ce deuxième achat beaucoup plus sereinement.
Si je vous parle de tout ça, c’est parce que cette expérience de premier achat a fait écho à celle que peuvent avoir des clients en recherche d’un tout premier site web. Si j’essaie de guider mes prospects en leur expliquant les avantages et inconvénients de telle ou telle solution, j’ai forcément un point de vue biaisé sur la question. Alors si vous êtes entrepreneur, que vous avez besoin d’un site pour votre société, que vous n’y connaissez rien au web, quels seront vos critères d’achat ? Le prix ? Le ressenti des premiers rendez-vous ? La taille de l’agence web ? Le langage serveur ou le CMS utilisé ? Comment faire le tri entre les conseils de vos amis et ceux des différentes agences que vous avez pu rencontrer ?
Je n’ai pas de réponse universelle, mais en me basant sur ma propre expérience d’achat d’un premier véhicule, je conseille aujourd’hui souvent de ne pas dépenser tout son budget. Si vous n’y connaissez rien au web, il y a de fortes chances pour que les besoins que vous imaginez aujourd’hui soient très différents des besoins que vous aurez dans un an, après avoir eu déjà un peu d’expérience dans la mise à jour de votre site.
Je viens de le poster sur Twitter, mais je le reposte ici parce que j’aime vraiment beaucoup cette Théorie du McDonald’s de Jon Bell.
J’utilise un truc avec mes collègues quand on essaye de décider où manger le midi et quand personne n’a d’idée. Je suggère d’aller au McDonald’s.
Quelque chose d’intéressant se produit alors. Tout le monde tombe d’accord sur le fait qu’on ne peut pas aller au McDonald’s, et de meilleures suggestions de déjeuners émergent. Magie !
C’est comme si nous avions brisé la glace avec la pire idée possible, et maintenant que la discussion a commencé, les gens deviennent soudainement créatifs. J’appelle ça la théorie du McDonald’s : les gens sont inspirés à trouver de bonnes idées pour écarter les mauvaises.
C’est une technique que j’utilise beaucoup au travail. Les projets démarrent de différentes façons. Parfois on vous donne un brief formel. Parfois vous entendez une rumeur de quelque chose qui pourrait arriver et vous commencez à y réfléchir à l’avance. D’autres fois vous avez muri une idée pendant des mois ou des années avant de la partager avec votre équipe. Il n’y a aucun processus défini pour du travail créatif, mais j’en viens à croire que tous les comportements créatifs partagent une chose : le deuxième pas est plus facile que le premier. Toujours.
C’est tout ce que j’aime.
