Toutes les news, intégration XHTML/CSS, HTML5, développement web, Terragen 2…

News au format RSS
Suivez-moi sur Twitter (Nico3333fr)

Paris Web 2016, retour du spectateur (le 06/10/2016)

J’ai eu le plaisir de participer à la onzième édition de Paris Web. Je ne résiste pas à l’envie de partager plusieurs retours, ce premier billet sera celui du simple spectateur.

L’édition de tous les dangers ?

Une fois n’est pas coutume, j’étais quelque peu inquiet avant cette édition. Un staff en plein renouvellement, une sur-multiplication des événements web, une édition 2015 qui avait fait très fort, je ne cache pas que j’étais inquiet.

Autant le dire de suite, je n’ai pas été déçu, et même bien au contraire.

De très bonnes surprises en conférence

Que ce soit les sujets qui tirent sur la société (Anatomie d’une désintoxication au Web sous surveillance, Organisez des cryptoparties !), sur le développement personnel (Libérée, délivrée… du syndrome de l’imposteur), sur la sécurité (Web security by design), de la technique pure (HTML5.1 + web platform APIs, Progressive Web Apps : le futur du web arrive) ou des sujets un peu surprise comme L’audio n’a pas dit son dernier mot ou La blockchain, quand l’individu sert au collectif… malgré lui, j’ai été servi.

D’autres sujets restent des valeurs sûres, comme sur l’internationalisation des sites, Vers l’infini et au delà des référentiels, etc.

Je note (enfin !) le retour en force de l’éco-conception via Éco-conception : mon site web au régime avec Frédéric Bordage, que je fus ravi de rencontrer enfin, même si ce fut fugace.

Après, il y a des sujets auxquels je n’ai pu assister, soit par impossibilité de dédoublement de ma personne, soit pour d’autres raisons. Mais je compte bien me rattraper avec les vidéos, car il y avait pléthore de sujets intéressants. Le moins qu’on puisse dire, c’est que ça a envoyé du lourd à tous les étages.

J’ai l’impression que cette année nous a mis un beau miroir en indiquant notre responsabilité au niveau même de la conception dans notre travail.

Quelques grosses claques dans la gueule

D’habitude, j’en prends plein la tronche aux conférences, et les ateliers sont la journée bonus où je suis les sujets de manière plus cool…

Pas cette année. J’en ai pris plein la tête aussi aux ateliers. Des promesses en JavaScript (qui m’ont en plus fait découvrir un paquet d’autres trucs), de Jérémie Patonnier qui me fait un mini-cours particulier très dense qui va servir mes plugins accessibles, en passant par un bon gros sujet sur Git qui m’a permis de décrotter beaucoup de choses biens obscures pour moi (merci Guillaume et Tûtie… heu Agnès !).

Le dernier atelier fut une source d’inspiration grâce à Emmanuelle et aux participants, un des plus beaux moments de diversité qu’il m’ait été donné de vivre. Observer Jean-Philippe communiquer, apprendre avec Emmanuelle/Sylvie, échanger tous ensemble… un bien beau moment.

Bref, j’avais déjà l’habitude avec Christophe Porteneuve et ses conférences sur ES2015, mais là, tous, vous m’avez donné au moins un an de trucs à apprendre et à digérer, bande de grands malades. En une journée, l’investissement est plutôt rentable. :)

Seule frustration : beaucoup, mais alors beaucoup de sujets intéressants en même temps. Au bas mot une dizaine m’intéressaient sur trois possibles. Appel du pied : écrivez des articles sur vos ateliers ou connexes à vos conférences, ça serait cool.

Bienveillance

Certaines éditions sont plus rigolotes, d’autres sont plus folles… cette année, j’ai eu l’impression de voir une forme de transmission, et ce même dans certains sujets comme D’imposteur à mentor ? et d’autres.

Autant sur certains sujets, j’ai été dans le rôle du vieux sage, autant sur de nombreux autres, j’ai été le débutant.

Ce qui me fait dire qu’on est tous le débutant d’un autre sur un sujet donné, et probablement le mentor d’un autre sur un autre sujet. Comme disait ce bon Einstein, tout est relatif. Pour ma part, j’ai été la cible d’énormément de bienveillance : « n’hésite pas à demander », « recontacte-moi si tu as besoin ». C’est bon de se sentir pas seul dans un monde de plus en plus individuel.

Les rencontres

Ne faites pas comme moi, ne soyez pas timide. Allez voir les gens, même s’ils semblent être des monuments pour vous. Perso, j’ai à peine osé glisser un mot à Léonie Watson (grande figure de l’accessibilité), tellement j’étais impressionné par son charisme. Soyez plus dégourdi que moi, vraiment.

Cet événement ne serait rien sans les gens qui y sont. J’ai juste un gros regret, ce fut bien trop court. J’ai eu l’impression que ces 3 jours ont duré à peine la moitié. Je n’ai pas pu discuter comme je l’aurai voulu avec la moitié des gens.

Quand je suis parti, j’en avais comme on dit vulgairement « gros sur la patate ». Quoi qu’il en soit, j’ai été ravi de partager ces moments très sympas.

Un événement à part

J’ai pu voir, comme le dit assez justement Christophe Andrieu dans un billet de retour sur cette édition, « le débat fait encore rage sur Twitter et par billets Medium rageurs interposés ». Qu’il fasse rage ailleurs, ce n’est pas l’image de Paris Web que je veux garder ici.

Cette édition a été à mes yeux une des plus inclusives, et j’ai ouï dire que le staff souhaitait encore faire mieux. Donc encourageons-le avec bienveillance. J’ai vu par exemple de nombreux orateurs/oratrices faire un transcript de leurs conférences, on va faire simple : je ne connais aucun événement où une telle émulation sur l’inclusivité se met en route. Ce n’est pas parfait, ce n’est pas toujours facile, on est parfois maladroit, c’est du boulot… mais ce n’est pas grave. Continuons. Le passé m’intéresse moins que l’avenir, et encore moins que les trolls.

Comme disait Jean-Philippe, je préfère sacrifier le buffet et manger un petit jambon-beurre plutôt que de sacrifier cet esprit.

Et enfin, ceux qui enterrent les conférences généralistes comme Paris Web ont été un peu vite en besogne. Une locomotive comme cet événement est forcément mis en difficulté, mais cette année, je lui trouve un aspect rutilant. Quoi qu’il en soit, ces fossoyeurs en seront pour leurs frais : je crois au contraire qu’on n’a jamais eu autant besoin de sortir le nez de nos spécialités et d’aller voir ce qui se raconte ailleurs. Nous en sortirons plus ouverts, plus inclusifs, plus empathiques et tout simplement… meilleurs.

Merci le staff

Maintenant, on va parler de ceux dont on ne parle pas assez : le staff. Je vais essayer de vous rappeler quand même l’essentiel, car on l’oublie un peu trop souvent. Ces bénévoles se donnent sans compter pendant une année et turbinent comme des malades. En plus, c’est presque une forme de masochisme, car ces personnes ne voient parfois pas le quart des conférences de l’événement pour lequel ils se donnent comme des tarés. C’est quand même hallucinant un tel niveau d’abnégation !

À la fin de la conférence, le staff s’incline devant nous pour nous remercier de notre présence, mais je crois qu’on fait faux-bond.

C’est à nous de nous incliner et de vous dire merci pour tout ce que vous faites. Je n’ai pas de mot assez fort pour vous dire à quel point cet événement a changé ma vie professionnelle depuis 6 ans et par ricochet ma vie personnelle. Alors, j’essaierai de le condenser en un simple « Merci ». Du fond du cœur.

Obtenir une bonne note sur Mozilla Observatory : HTTPS/CSP/SRI/CORS/HSTS/HPKP/etc. (le 08/09/2016)

Un projet très intéressant est sorti il y a peu nommé Mozilla Observatory. Cet outil permet de tester divers points concernant la sécurité des sites Web.

En grand joueur, je me suis amusé à essayer d’obtenir la meilleure note possible, qui selon le barème est de 135/100. Je suis arrivé à 130/100 sur le site de Röcssti, ce qui n’est déjà pas si mal.

Mise à jour du 27 Octobre 2016 : Röcssti étant désormais sur HSTS preload list, ce n’est plus 120/100 mais 125/100 au score.

Mise à jour du 22 Novembre 2016 : Röcssti envoyant un en-tête Referrer-Policy, ce n’est plus 125/100 mais 130/100 au score.

Résultats de Mozilla Observatory pour Röcssti

Comme cela a l’air d’intéresser pas mal de monde sur Twitter, je vais essayer d’expliquer au mieux ce qu’il faut faire pour faire péter le A+, et essayer de vulgariser tous ces noms barbares. :)

Autant le dire de suite : certains points peuvent être difficiles à obtenir selon vos conditions. Je ne suis pas non plus un expert sur chacun des points, vous m’excuserez d’avance le langage de béotien. Si un expert ou une experte en sécurité veut bien vulgariser ceux que je ne maitrise pas, il ou elle est le ou la bienvenu(e) !

Attention, bon nombre des choses que je présente ici vous font entrer dans le merveilleux monde du HTTPS, mais il sera très difficile voir quasi-impossible d’en sortir si vous déployez tout cela. Réfléchissez bien avant de déployer toute cette armada, car certains points ne s’annuleront vraiment pas facilement.

HTTPS/TLS

Le premier point sans lequel vous n’irez pas très loin est HTTPS. Curieusement, on croit que la sécurité vient du type de certificat (cela joue), mais en fait c’est aussi et surtout la configuration serveur qui va vous octroyer une bonne ou mauvaise note. Si le serveur est configuré pour utiliser des protocoles dépassés (et donc vulnérables), vos notes risquent de vite baisser. Par contre, si votre serveur ne supporte que les protocoles les plus récents, de vieux navigateurs pourront être exclus : si un agent utilisateur n’arrive pas à se mettre d’accord sur un protocole avec le serveur, fin de la discussion. C’est très bien expliqué dans « Le réveil de la crypto forte ». C’est un équilibre à trouver.

Si vous avez la maitrise de votre serveur, vous pouvez vous lancer à étudier cela. Personnellement, j’admets bien volontiers que la config serveur n’est pas mon fort. La documentation donnée par Mozilla est intéressante : Recommended Configurations for TLS. Je reconnais que ce point est délicat si on n’a pas de connaissances sur le sujet.

Si vous n’avez pas la main sur votre serveur, c’est là que votre hébergeur doit prendre le relai… et une initiative est tombée à point nommé : Let’s Encrypt. Cela vous évite déjà le fait de payer pour votre certificat, et l’outil est réputé plutôt simple. De ce côté-là, Röcssti étant hébergé chez Infomaniak (partenaire de Let’s Encrypt depuis un certain temps), cela a été très facile à gérer. Un simple clic dans l’admin permet d’installer un certificat, et ce dernier se renouvelle automatiquement.

Ajoutons à cela qu’en début d’année, je leur ai gentiment demandé d’améliorer leurs configurations… et ils l’ont fait !

Bref, n’hésitez pas à challenger vos hébergeurs, et à les féliciter quand ils jouent le jeu. Et n’oubliez pas que ce qui est fait pour vous bénéficie à tout le monde.

Pour tester votre configuration :

HTTP Strict Transport Security (HSTS) et redirections

Maintenant que votre site peut être servi en HTTPS, il va falloir… ne plus rien utiliser d’autre. Pour cela, vous pouvez commencer par mettre en place des redirections (via htaccess ou en-tête PHP). La logique de Mozilla Observatory est la suivante : le nom de domaine doit d’abord être redirigé vers le même en HTTPS (ce qui permettra d’utiliser HSTS correctement), et quoi qu’il arrive la destination finale doit être en HTTPS.

Là, rien de bien particulier. Cela peut se faire via htaccess par exemple :

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

La redirection renvoie vers la version sécurisée avec le rewrite flag permanent redirect, toutefois, cela est insuffisant. C’est là qu’entre en scène HTTP Strict Transport Security (HSTS). Selon Wikipédia, « HSTS est un mécanisme de politique de sécurité proposé pour HTTP », qui intime à l’agent utilisateur de remplacer automatiquement tous les liens non sécurisés par des liens sécurisés (on n’attend même plus la redirection côté serveur pour aller directement vers la version sécurisée). Voici l’en-tête en question chez moi :

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Grosso modo, dès que l’agent utilisateur reçoit cet en-tête : il ne va plus utiliser autre chose qu’HTTPS durant 1 an (31536000s = 1 an dans mon cas) et ce même si on utilise une URL non sécurisée (elle sera automatiquement « upgradée » vers HTTPS), les sous-domaines auront également le même traitement.

C’est pour cela que par exemple vous aurez l’impression chez Infomaniak que dès que vous utilisez une URL en HTTPS, HTTPS sera activé automatiquement pour tout le domaine. C’est le cas sur votre machine (qui a reçu l’en-tête HSTS), mais pas nécessairement partout si vous n’avez pas activé les redirections. Par contre, n’importe qui qui reçoit cet en-tête de votre site sera systématiquement renvoyé vers HTTPS.

La seule limite de cet en-tête surpuissant est la première connexion : tant qu’on ne l’a pas reçu, on n’est pas protégé. C’est là qu’un autre mécanisme entre en jeu pour compléter cela : on peut inscrire son nom de domaine sur une liste de pré-chargement HSTS preload list pour demander son inclusion dans cette liste. Cette liste est utilisée par les navigateurs modernes. En clair, si votre site est dans cette liste, les navigateurs utiliseront HTTPS de suite et quoi qu’il arrive.

Le preload dans l’en-tête au-dessus indique qu’on donne le consentement pour y être inclus. Pour Röcssti, j’ai déjà fait la demande, mais c’est toujours en attente, et d’après ce que j’ai lu, c’est plutôt long pour y être ajouté, et aussi long pour en être retiré. Un point de détail, ne mettez pas de point-virgule après preload, sinon HSTS preload list vous gueulera dessus. J’ai eu le problème avec l’en-tête mis par défaut chez Infomaniak, vous pouvez le surcharger en attendant que cela soit fixé (le bug a été remonté et a été fixé).

Mise à jour du 27 Octobre 2016 : Röcssti est désormais sur HSTS preload list, hop, 5 points de plus !

Je le redis, attention, bon nombre des choses énoncées ici vous font entrer dans le merveilleux monde du HTTPS, mais il sera très difficile voir quasi-impossible d’en sortir. Si vous avez le moindre doute qu’un jour vous deviez revenir à du HTTPS sans le « S », réfléchissez bien.

HTTP Public Key Pinning (HPKP)

Là on touche du doigt un point délicat à gérer si vous n’avez pas la main mise sur votre serveur et/ou si vous n’avez de bonnes compétences en la matière.

Grosso modo, l’idée de l’en-tête HPKP est de faire présenter une liste à la première connexion réussie (sur le principe joliment nommé TOFU, tout comme HSTS) représentant les clés de confiance par le serveur (via un hashage cryptographique, un SHA-256). Le navigateur mémorise cette liste. Aux prochaines connexions, les navigateurs ayant gardé en mémoire la liste des clés de confiance vont re-vérifier les clés publiques, et, si le certificat a été compromis, le navigateur refusera la connexion.

Voici des ressources sur le sujet :

Je le redis (et les ressources ci-dessus aussi) : faites vraiment gaffe avant de vous lancer là-dedans, procédez doucement en mode Public-Key-Pins-Report-Only, car il est très facile de se blackbouler soi-même si on ne fait pas attention. N’utilisez pas bêtement l’outil ci-dessus, ne foncez pas tête baissée, il est vraiment facile de se planter si on ne lit pas la documentation (j’insiste, mais vous ne pourrez pas dire que vous n’avez pas été prévenus).

Pour ma part, je n’ai pas encore tous les tenants et les aboutissants de cette techno sur mon hébergement, donc je préfère attendre et apprendre avant de m’y frotter. Peut-être la solution viendra de l’hébergeur directement, cela sera à voir.

Referrer-Policy

Comme son nom l’indique, Referrer-Policy indique votre politique en matière de Referrer. Essayons d’expliquer cela simplement.

Typiquement, si vous chargez une image http://www.foo.com/image.jpg sur un site depuis http://www.monsite.com/plop.htm, votre navigateur va envoyer une requête en indiquant dans les en-têtes que l’origine de la requête est Referer: http://www.monsite.com/plop.htm. C’est ce que vous voyez dans certains outils de logs qui vous disent par exemple que votre fichier a été affiché depuis « telle adresse ». Le principe est équivalent pour des liens, ce qui vous permet de savoir que « telle adresse » a un lien vers une page du vôtre (par exemple sous Google Analytics).

Le seul souci de cette valeur, c’est qu’elle peut transmettre à votre insu des informations sensibles. C’est là que cet en-tête entre en jeu, il permet de définir explicitement votre politique à ce propos. Voici les valeurs recommandées par Mozilla Observatory :

  • no-referrer : on n’envoie jamais l’en-tête
  • same-origin : on n’envoie l’en-tête que sur les requêtes ayant la même origine
  • strict-origin : on envoie l’en-tête à toutes les origines, mais seulement l’URL sans le chemin (on sait que cela vient de « tel site » mais sans en savoir plus)
  • strict-origin-when-cross-origin : on envoie l’en-tête complète sur la même origine, et seulement l’URL sans le chemin sur les autres origines

Pour ma part, j’ai utilisé la dernière valeur.

SubResource Integrity (SRI)

Là je vais être fainéant, je viens d’écrire un billet sur le sujet : À propos de SubResource integrity (SRI) et de traduire en français Subresource Integrity sur le MDN.

Grosso modo, le cas classique d’utilisation est la vérification de l’intégrité d’un fichier qu’on télécharge par exemple depuis un CDN. Dans mon cas, ce n’était pas obligatoire, néanmoins je me suis amusé à l’ajouter pour mon fichier JavaScript.

<script src="./layout/js/jquery-mini_1460217696.js"
async="async"
integrity="sha384-pQLaaAifGwNK5mu6Y9T+zVs8G05K8aE3JBHEIzwnzhmJ5QR1mNwR8/QtV4lRkrm2"></script>

Si le hash ne correspond plus (autrement dit si le fichier a été compromis), patatrac, le navigateur n’exécutera plus ce fichier JavaScript.

Cross-origin Resource Sharing (CORS)

CORS est un en-tête HTTP (encore un !) indiquant votre politique concernant les sites souhaitant accéder à vos ressources depuis un autre nom de domaine, via des méthodes comme XMLHttpRequest.

Pour vous donner un exemple, supposons que je mette en place un CDN proposant les versions minifiées de Röcssti. Il faudra que sur ce CDN, je spécifie qui a le droit d’accéder à ces fichiers. Supposons que j’autorise tout le monde, cela donnerait dans un htaccess :

Header set Access-Control-Allow-Origin "*"

Dans le billet précédent sur SubResource Integrity, j’ai fait mention de CORS pour utiliser l’outil SRI Hash Generator.

Bref, c’est bien de savoir que cela existe, mais CORS me semble un peu moins important que les autres points. Typiquement le genre de trucs que l’on peut ignorer jusqu’au jour où on s’y retrouve confronté (« mais pourquoi on n’arrive pas à accéder à mon API depuis tel autre site en AJAX ? »).

X-Content-Type-Options, X-Frame-Options, X-XSS-Protection

Ce sont d’autres en-têtes de sécurité, voici le détail pour chacun.

X-Content-Type-Options: nosniff doit être activé sur tous vos fichiers. Cela peut se faire via un htaccess :

<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>

Cela évite aux navigateurs de jouer aux devinettes avec les types MIME de vos fichiers, et donc de risquer des failles XSS avec des fichiers malicieux. Si les types MIME ne sont pas bons, les navigateurs ne les exécuteront pas, point barre.

Header set X-Frame-Options "DENY" indique que vous interdisez que votre site soit embarqué dans des frame et autres iframe. Cela évite les attaques de type clickjacking, grosso modo qu’on embarque votre site dans un jeu de frames pour berner un utilisateur peu attentif. Si vous voulez gagner quelques points, il faut également doubler cette disposition en utilisant la directive frame-ancestors 'none'; dans vos directives CSP (voir plus bas).

X-XSS-Protection: 1; mode=block indique aux navigateurs disposant de certains filtres de protection pour certaines attaques XSS de – s’ils détectent ces attaques – bloquer la totalité du contenu. Toujours bon à activer.

Ces trois en-têtes sont assez simples à mettre en place, c’est pour cela que j’avais beaucoup poussé pour qu’ils soient tous pris comme des bonnes pratiques Opquast dans la version 3 du référentiel. Ils y sont, les voici :

Les cookies

Pensez à spécifier le paramètre secure et si le cookie n’a pas besoin d’être accédé par JavaScript, mettez le flag HttpOnly à true. Bien entendu, si vous pouvez vous passer des cookies, ou limiter leur champ d’action et leur durée de vie autant que possible, c’est préférable.

Content Security Policy (CSP)

Ah, Content Security Policy, c’est une de mes possibilités préférées depuis 2 ans. Un article de ma part devrait arriver d’ici quelque temps, donc je ne vais pas tout détailler.

Ajout du 13 Septembre : l’article vient de sortir sur Smashing Magazine, faites donc un tour sur Content Security Policy, Your Future Best Friend.

Revenons au principe : vous envoyez un en-tête CSP avec les directives que vous souhaitez voir exécutées.

Grosso modo, vous dites ce que vous allez autoriser sur votre front. Voici des ressources sur le sujet :

Pour avoir un bon score sur Mozilla Observatory :

  • Interdisez-vous les scripts 'unsafe-inline' (ce qui me semble être le minimum)
  • Mieux, n’autorisez pas les styles ou les scripts en ligne et pas de fonction eval (pas de 'unsafe-inline' ou 'unsafe-eval')
  • Plus restrictif, interdisez-vous default-src: 'self' et utilisez default-src: 'none', ce qui va vous forcer à définir chaque directive à la main.

Pour obtenir cela, tout dépend d’où vous partez. Si vous avez déjà implémenté des directives CSP sans 'unsafe-inline' ou 'unsafe-eval' pour les styles/scripts, vous avez fait le plus dur ! Passer à default-src: 'none' ne sera pas trop difficile, je l’ai fait en 15 minutes sur Röcssti. Par contre, si vous n’avez pas encore éliminé les styles en ligne et les scripts en ligne, le travail risque d’être plus long.

Pour vous donner un ordre d’idée, sur ce site dont le code est plutôt correct (mais ancien), j’ai eu un peu de travail pour éliminer quelques vieux cancrelats. Pas plus tard qu’hier, j’ai reçu environ 2 à 300 notifications d’erreurs CSP sur mon site (qui n’est pas monstrueusement fréquenté). Quelques mises à jour massives entre hier et aujourd’hui ont bien calmé le jeu, même si ce n’est pas totalement fini.

Par contre, sur une refonte, c’est en théorie beaucoup plus facile, vous pouvez même vous mettre de suite des garde-fous. Typiquement, c’est un long travail de propreté et d’orthogonalité dans votre code. Pour ma part, les plugins accessibles en sont une des parties les plus visibles. Sur des sites avec un existant plus compliqué, cela peut prendre plus de temps, dans ce cas, il vaudra mieux utiliser l’en-tête Content-Security-Policy-Report-Only avec un report-uri.

Détail, pensez bien à ajouter frame-ancestors 'none'; comme indiqué plus haut. CSP est également évoqué via une bonne pratique Opquast : le site propose un mécanisme de sécurité permettant de restreindre l’origine des contenus.

Conclusion

Ouf, si vous êtes arrivé au bout de ce billet fleuve, et moi aussi par la même occasion.

Quoi qu’il en soit, cet outil Mozilla Observatory arrive à point nommé, il met en exergue certains efforts à fournir pour proposer des sites toujours plus sûrs, et s’inscrit parfaitement dans une démarche de qualité et d’amélioration continue. Bien entendu, la sécurité de vos sites ne s’arrêtera pas là.

De mon expérience, je dois reconnaître que sans mon hébergeur actuel qui est sérieux et Let’s Encrypt, je n’aurais pas été capable d’obtenir ce A+ pour le site de Röcssti. Il y a un moment, il faut savoir reconnaître ses limites et déléguer, gérer des serveurs, c’est un métier, et je ne suis pas admin serveur non plus ! :)

Cela pose définitivement la question du sérieux des partenaires de vos sites. Mon ancien hébergeur dont j’étais plutôt content il y a quelques années – je viens de déménager ce site il y a quelques jours après des années chez eux – n’a pas voulu installer Let’s Encrypt (entre autres nombreuses conneries). La sanction est arrivée petit à petit : d’abord le site de Röcssti qui lui est passé sous le nez, ensuite celui de « Est-ce qu’on met en prod », après deux autres sites où j’avais besoin d’HTTPS, et enfin mon site personnel. Et ce n’est pas dit que je ne fasse pas déménager d’autres sites. Certes, ce sont quelques poissons noyés dans un océan, mais si tout le monde s’y met…

Ajoutons à cela qu’en tant que personnes averties, nous avons un devoir minimum d’encourager les services qui essaient de sortir du lot et qui nous écoutent. Ils ne sont malheureusement pas la majorité, parfois obtenir un simple en-tête X-Content-Type-Options: nosniff sur certains CDN est un chemin de croix… c’est tout le sens du billet que j’ai publié chez Openweb : « chers services tiers, et si vous vous associez à nous ? ».

Le second plus gros effort à fournir est pour CSP, hormis HPKP, le reste peut s’obtenir si vous êtes capable de paramétrer quelques en-têtes.

N’hésitez pas à partager vos découvertes ou vos connaissances/infos sur ces sujets, on apprendra tous et toutes les uns des autres !

À propos de SubResource integrity (SRI) (le 22/08/2016)

Au hasard de mes pérégrinations webesques du week-end, je suis tombé sur un utilitaire assez sympathique : SRI Hash Generator.

SRI Hash Generator

Subresource integrity, késaco ?

Cet utilitaire permet d’utiliser simplement SRI, qui est une spécification du W3C. Grosso modo, l’idée de SRI est simple : vérifier l’intégrité d’un fichier (CSS ou JavaScript par exemple) qu’on télécharge par exemple depuis un CDN. L’intégrité est faite à l’aide d’un hash (une fonction de hachage cryptographique en bon français), exemple :

<link rel="stylesheet" href="https://rocssti.net/downloads/rocssti-fr.css" integrity="sha384-7e5gIv4ZjCNGuNodi1FRsA2KxKWIp+ambTxw9xGhjpkTIJGneKrLp7j8jHBIYNtD" crossorigin="anonymous" />

Le navigateur qui lit ce genre d’appel va recalculer l’intégrité, et, si les valeurs coïncident, va exécuter le script ou la CSS. Si les valeurs ne coïncident pas, le navigateur refusera d’exécuter le script et/ou d’appliquer la CSS.

L’idée à la base de SRI est – si un CDN est compromis – d’empêcher que le vilain code malicieux qui a été inséré dans la bibliothèque que vous utilisez ne vienne se propager sur vos sites.

Exemples

Je me suis amusé à faire deux exemples simples avec Röcssti : chacun appelle Röcssti avec un hash différent (un bon et un bidonné) et essaie d’utiliser une classe de ce dernier.

Comme vous pouvez le voir dans le second cas, c’est radical si votre navigateur supporte SRI, même une pauvre classe n’est pas appliquée.

Peut-être l’aviez-vous vu par exemple sur le CDN de jQuery ?

<script src="https://code.jquery.com/jquery-3.1.0.min.js"
integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
crossorigin="anonymous"></script>

Bon à savoir

Si vous vouliez tester l’outil, pensez à autoriser CORS pour le fichier en question. Cela peut se faire via un .htaccess avec :

Header set Access-Control-Allow-Origin "*"

Côté support, c’est ok pour Firefox et Chrome, espérons que cela arrive vite pour les autres.

Pour en savoir plus sur SRI :

Ajout : piqué au vif de ne pas proposer le moindre lien francophone sur ce sujet, j’ai traduit la page sur le MDN en français : SRI, en français !

Ajout : Finalement, j’ai écrit un article sur le sujet sur OpenWeb : SubResource Integrity.

« De dieu, mon bon BDD » (le 15/06/2016)

Je me faisais la remarque récemment que, globalement, les réseaux sociaux et autres moteurs de recherches en savent de plus en plus sur nous et notre travail.

Il suffit de se faire « Googler » pour que sortent les infos d’où l’on travaille (via Microsoft LinkedIn © et apparentés), pour que l’on puisse connaitre une partie de notre réseau proche de collaborateurs, il suffit de tomber sur nos portfolios et autres sites personnels – même si le mien n’est pas très à jour, doux euphémisme – pour voir nos réalisations, etc.

Par contre, il y a un truc que je trouve dommage, en bon humaniste comique de service, très peu de choses filtrent sur l’ambiance qui règne au boulot. Il y a bien des recommandations très formelles où en général on loue les qualités professionnelles de la personne. Mais on ne sait rien de l’essentiel. Au mieux, quelques photos de croissants.

Vous savez, ces petites choses qui font tout le sel des relations entre collègues. Maintenant, vous saurez :

  • pourquoi le Jeudi, je commande les burgers en me faisant passer pour un certain Oscar : c’est un gag récurrent avec un ancien collègue (salut Oscar) ;
  • pourquoi toujours le Jeudi, je prends en photo un burger quand je ne suis pas au travail, et on se fait signe ainsi ;
  • pourquoi j’imitais – mal – E.T : parfait pour faire claquer de rire une ancienne collègue (salut Elsa) ;
  • qu’on pratique l’analyse politique de Rocco : Rocco commente une actualité façon service après-vente des émissions (Yo Fabien) ;
  • qu’on me surnommait « mon bon BDD » lors de mon ancien travail (hein mon bon Gérard, qui a relevé que je disais souvent l’expression « Brut De Décoffrage ») ;
  • qu’on s’appelait tous Jean-<mettez ici le prénom>, ce qui provoquait l’incompréhension des non-initiés ;
  • que je disais sans arrêt « Ach, leu gro mossieur t’abord » (12 travaux d’Astérix) en décrochant au téléphone quand c’était mon collègue ;
  • pourquoi on adorait lire les petites annonces du coeur du journal : un lisait, l’autre commentait (yo Dadou) ;
  • que quand mon collègue me disait « mais qu’il est con ce BDD », je lui répliquais au choix, soit la vanne de Coluche « et on se rend pas compte à quel point », soit la réplique de Léonard est un génie « Pas de flatteries, j’ai horreur de ça » ;
  • Etc.

Entres autres gags récurrents impossibles à retranscrire ici. Dommage que ces petits plaisirs ne ressortent que trop rarement.

Si vous êtes inspiré, racontez ça en commentaire ou sur votre site, ça vaut la peine d’être partagé, on est quand même des humains avant tout.

Retour sur Sud Web 2016 à Bordeaux (le 06/06/2016)

J’avais découvert Sud Web en 2012 – souvenez-vous, la fin du monde – et je n’avais malheureusement pas pu y retourner depuis, même si l’envie était toujours là. L’édition 2012 m’avait beaucoup plu et garde une place à part dans mes souvenirs, pour tout un tas de raisons qu’il serait trop long d’énumérer ici.

Alors quid de cette édition 2016 ?

Autant ne pas tourner autour du pot, ces moments font du bien.

Ils nous invitent à lever la tête de nos guidons à 104 touches et d’emmener nos réflexions un peu en dehors du temps. On se fait plaisir à découvrir de nouvelles choses, et surtout à constater que bien souvent, les mêmes problématiques que celles que nous rencontrons reviennent dans des domaines à priori éloignés des nôtres.

Et de remarquer que de la contrainte nait la créativité !

Côté conférences

Que ce soit les sujets longs ou les interventions plus courtes, toute la journée fut intéressante, autant dans la découverte de l’audio API que dans l’émotion à la lecture de « J’ai dix ans », autant dans « Mon pire client à 5 ans » qui a fait sourire le parent que dans le « Zero Waste Fashion » qui tape sur ma fibre recyclable, même si je ne connais rien à la couture. Mention spéciale au Bus Factor, qui m’a rappelé pourquoi j’ai décidé d’arrêter de sauver le monde depuis quelques années.

Les conférences donnaient l’impression de nous faire voyager à travers divers âges, et cette sensation était parfaitement accompagnée par Pauline Calmé entre les interventions. D’où une certaine prise de perspective, fort salutaire.

Côté élaboratoires

J’avais adoré le concept en 2012, et je crois que je l’aime toujours autant, sinon plus. Fonctionner à la bonne énergie des participants, c’est une énergie durable et propre, j’avais l’impression d’être dans un camp de vacances de gens passionnés.

En bon atteint du syndrome de l’anti-imposteur (merci Raphaël, je peux enfin mettre un mot sur ce qu’il m’arrive), je n’ai pas pu m’empêcher de proposer un petit atelier sur la survie en internationalisation des sites, complètement improvisé et bien sympathique, j’espère que les participants ont apprécié ce moment autant que moi. Encore une fois, le mot important était d’aller voir ailleurs pour voir les différences de culture, pour en apprécier toutes les saveurs, et se remettre en cause. C’est pour cela que je ne mens pas quand je dis que j’adore intégrer un site en Arabe ou en Japonais, même si ce n’est pas toujours facile… c’est enrichissant.

La seule frustration finale des élaboratoires est… que j’aurais bien rempilé pour une journée.

Côté gens

Bien entendu, ce genre d’événement n’est rien sans les gens qui le font, que ce soit le staff ou les participants.

De ce côté-là, j’ai autant été content de retrouver des visages bien connus que d’en rencontrer pleins de nouveaux. Les discussions en off étaient bien sympathiques, je me suis même surpris à ne participer à aucun élaboratoire durant un créneau de l’après-midi… juste pour le plaisir de discuter.

Des réflexions qui « m’interrogationnent »

Un très gros retard sur mon avion du retour me libèrera du temps pour achever la version 3 de Röcssti, et me forcera à être créatif, vu le côté limité de la connexion à l’aéroport. Si en une grosse journée, j’arrive à propulser ainsi un projet perso, peut-être me faudrait-il plus de temps libre au travail ? Cela m’interpelle.

La question de la transmission de la connaissance et de l’expérience reste importante, sinon nous sommes condamnés à revivre les mêmes problèmes, régulièrement. Pour cela, des idées intéressantes sont sorties, à voir jusqu’où elles iront.

Un point qui me fait très plaisir, les discussions de visu nous ont éloigné des postures qu’on affiche parfois bien malgré nous sur les réseaux sociaux, lesdites postures qui me fatiguent de plus en plus. La conscience des problèmes des silos (comme Medium) est très forte et est revenue plusieurs fois lors de discussions, j’avoue avoir apprécié l’idée du fanzinat des gens du web.

Je vois de plus en plus de gens qui veulent se lancer, essayer des conférences, des billets, etc., je leur dis un très clair : allez-y, proposez ! Intervenir en conférence n’a en fait rien à voir avec la façon dont le monde vous voit, même si cela peut effectiver changer, mais surtout va changer la façon… dont vous vous voyez vous-même.

Bref, j’aime bien ces valeurs et ces questions. Peut-être qu’à l’instar de Montaigne, je préfère des têtes bien faites que des têtes bien pleines ? Là, en matière de têtes bien faites, j’ai été servi, c’est le moins que je puisse dire.

En conclusion

Le maitre mot que je retiens de cette édition est la congruence (être en accord entre ses actions, ses sentiments, son être, etc.). Ce n’est pas toujours facile, mais c’est la seule voie pour durer.

Même si j’adore la thématique des super-héros, je crois que la thématique de cette année était le temps. Nos espaces-temps sont tous différents, et pourtant cela fonctionne quand on choisit de prendre le temps. J’apprécie de passer en moins d’une heure de vieux briscard du web à jeune débutant impétueux.

En tout cas, Sud Web a trouvé sa singularité, et cette parenthèse bordelaise fut fort appréciée et salvatrice. Bravo le staff, vous avez assuré en tous points, je vous remercie pour ces moments.

Les media-queries et les préférences utilisateurs (le 15/05/2016)

Maintenant que les avantages indéniables des unités relatives pour la taille de fonte ont été posés du point de vue du respect des paramètres utilisateur, voyons leurs effets sur les media-queries.

Vous avez peut-être déjà pu voir certains effets sur les pens précédents.

Rappelons un fait : les media-queries sont un système pour adapter les contenus d’un site selon les caractéristiques du visiteur (largeur d’écran, etc.). En général, l’idée est de les adapter au mieux en fonction du design et du contexte de l’utilisateur. Ce « truisme » (je rêvais de placer ce mot depuis longtemps) tombe sous le sens, mais vous allez voir qu’il prend une certaine dimension dans notre sujet.

Au fait, les media-queries se basent sur quoi ?

Cela va peut-être vous surprendre, mais les media-queries se basent sur les préférences utilisateur ! Si vous n’en êtes pas convaincu, je vous prie de faire cette expérience sur cet exemple : une taille de fonte en unité relative (em). Vous noterez que j’ai défini un breakpoint à 50em (qui va faire apparaitre un texte).

Voila l’expérience en question :

  • Mettez-vous en conditions « standard », soit avec une taille de fonte de 16px.
  • 50 fois 16 = 800 pixels. Redimensionnez votre fenêtre, vous verrez apparaitre le texte en-dessous de 800px.
  • Maintenant, augmentez votre taille de fonte par défaut à 32px.
  • 50 fois 32 = 1600 pixels. Redimensionnez votre fenêtre (si elle fait plus de 1600px de large), vous verrez apparaitre le texte en-dessous de 1600px.
  • Si comme moi, votre écran fait moins de 1600px de large, le texte sera déjà visible, et il va falloir agrandir votre fenêtre pour le faire disparaître.

Surprenant n’est-ce pas ?

Une erreur assez commune est de croire que les media-queries sont basées sur l’élément html. Ce n’est pas le cas, c’est bien basé uniquement sur les préférences utilisateur. Si vous doutez que l’élément html n’influe en rien, vous pouvez tester sur le pen suivant : une taille de fonte en em sans « reset ». Comme vous pourrez le voir, qu’il y ait un « reset » ou pas n’y change strictement rien, le comportement est le même.

Les paramètres utilisateurs, seulement la taille de fonte par défaut ?

C’est principalement la taille de fonte par défaut, mais… pas uniquement. L’utilisateur a deux autres possibilités : le zoom global et le zoom texte.

Le zoom global, comme son nom l’indique, effectue un zoom sur tous les éléments, vulgairement : tout le site grandit proportionnellement.

Le zoom texte, comme son nom l’indique aussi, n’effectue un zoom que sur le texte.

Il y a quelques subtilités en pratique entre ces deux zooms, nous allons voir lesquelles dans de futurs exemples. Si vous souhaitez tester sans tout faire à la main, je vous conseille d’utiliser une extension comme NoSquint, qui permet de tester directement avec l’un ou l’autre.

Alors, quid des media-queries en pixels ?

Comme dans le billet précédent, les pixels sont indépendants des préférences utilisateur. Ce qui suit va encore vous le prouver.

Si vous mettez en place une media-query en pixels, avec une taille de fonte par défaut à 16 ou 32px, elle ne s’appliquera que quand la fenêtre fera 800px. En quelque sorte, c’est l’écrasage « presque » ultime des préférences utilisateur.

Pour les zooms, c’est quelque peu différent. Comme le zoom global grossit tout (les préférences utilisateur comprises), la media-query s’appliquera quand le zoom sera à 200% (cela peut sembler assez intuitif). D’où le « presque » entre guillemets dans la phrase précédente.

Par contre, le zoom texte n’impactera pas le déclenchement de la média-query. Encore une fois, comme les pixels sont indépendants des préférences utilisateurs, cela semble plutôt logique.

Voir l’exemple sur Codepen : une taille de fonte en em avec une media-query en pixels.

Si vous regardez le pen tout en em, que ce soit en zoom texte ou en zoom global, la media-query s’appliquera à 200%.

Qu’en déduire pour nos sites ?

Une citation résume bien ce phénomène :

Designing for the Web is like visualizing a tesseract. We build experiences by manipulating their shadows. — Tim Brown

Traduction expresse : concevoir pour le Web est comme visualiser un tesseract (un cube à 4 dimensions), on construit une expérience en manipulant ses ombres (nous ne pouvons voir que 3 dimensions).

Vous pouvez tester sur le site de Röcssti. Le conteneur principal a été défini en em et les tailles de fonte ainsi que les media-queries ont été définies également en em.

En fait, travailler en em permet, sans le savoir, de travailler au mieux sur toutes les dimensions utilisateur (zoom, préférences de typo, zoom texte, etc.), sans même en avoir forcément conscience.

Si vous voyez la bibliothèque dans le film Interstellar, c’est exactement le même principe.

InterStellar

Vous avez le cas « standard » avec ses déclinaisons responsive. Imaginez-vous 3 ou 4 images sur une droite.

Maintenant, imaginons une troisième dimension, où l’on augmente la taille de fonte standard. On rajoute le zoom global ? Une dimension de plus.

Zoomez fortement sur le desktop ? Vous aurez l’adaptation mobile du cas « standard », sur un grand écran. Ayez une taille de fonte de base légèrement diminuée et un zoom texte léger ? Vous aurez peut-être le rendu tablette ou équivalent.

Et même parfois, vous aurez une singularité dans tout cela. Lisez Double breakpoint bug de Thomas Tzilliox, le cas où ces dimensions laissent un espace vide, en quelque sorte. :)

La (sur)vie avec les em

Le guide de survie avec les em du billet précédent n’était pas complet.

Après, je crée le site dans les conditions « standards », et ô miracle, changer la taille de fonte par défaut ne cassera rien.

C’est même le contraire, je ne casse rien mais je construis en même temps dans d’autres dimensions : les breakpoints que je définis pour le mobile dans le cas standard vont resservir pour toutes les variétés de réglages selon les périphériques ou les utilisateurs.

C’est quand même extraordinaire quand on y pense, car le fait d’adapter au mieux les contenus pour le cas « standard » (en gros, en connaissant sa division par 16), vous fait travailler en même temps pour de forts zooms sur desktop.

Pour de bon que si vous aviez le doute de travailler le responsive uniquement d’après les contenus plutôt que de viser des résolutions fixes, cela va achever d’enterrer ce doute.

En tout cas, j’espère que vous voyez mieux le sens de « lâcher prise sans perdre le contrôle » : vous n’avez pas prise sur les media-queries, vu qu’elles sont basées sur les préférences utilisateurs… sur lesquelles vous n’avez pas de prise. Et pourtant, vous pouvez faire au mieux, même pour un cas que vous n’imaginez pas.

Media-queries en rem

Ajout du 1 Mars 2018 : tous les tests précédents sont valables sur des media-queries en em. Les media-queries en rem créent une curiosité. Voyez le test une taille de fonte en rem avec « reset » sur une media-query en rem.

Firefox et Safari desktop vont déclencher le breakpoint à 500px (10 * 50rem = 500px) avec une taille de fonte par défaut à 16px et à 1000px avec une taille de fonte par défaut à 32px !

Chrome et Edge vont le déclencher à 800px et 1600px respectivement (ils se basent sur la préférence utilisateur, comme pour les media-queries en em).

En clair, évitez les media-queries en rem, le support en est inconsistant. Et honnêtement, je ne sais pas dans ce cas qui a raison côté navigateur.

Ajout : Chrome et Edge ont raison, Firefox a corrigé ce bug (le patch sera publié sur Firefox 59 à priori). Le bug est remonté chez Webkit pour Safari.

Les em/rem avec les préférences utilisateurs (le 14/05/2016)

Je suis surpris de voir que les unités relatives ne font pas encore consensus dans la communauté Web, notamment sur la typographie. Nicolas Hoizey avait fait une chouette conférence sur le sujet, que je vous invite à aller voir ou revoir : Un petit pas pour l’em, un grand pas pour le Web.

Dans sa grande mansuétude, il tue également un vieux troll qui dit que la taille de fonte par défaut est toujours de 16px : People don’t change the default 16px font size in their browser. Je résume : c’est souvent le cas, mais pas toujours.

Un autre point quand vous hésitez à choisir une unité, la question à vous poser est : de quoi dépend réellement la valeur que je veux mettre, de quel contexte ? (gardez toujours cela à l’esprit)

Maintenant que c’est posé, avançons ! Suite à un échange sur Twitter hier après-midi, les notions de respect des préférences utilisateurs ne semblent toujours pas claires, tout comme le comportement des media-queries. Alors décortiquons le tout avec des exemples très simples.

Notes : si vous souhaitez tester les exemples que je vais donner, sous Firefox, il faut aller dans Options, Contenus, et là vous pourrez changer votre taille de fonte par défaut. Afin de simplifier les exemples, je les ferai avec une taille de fonte par défaut de 16px et 32px, j’ai choisi le double juste pour des raisons de simplicité d’explication. Je ne redonnerai pas tout le code à chaque fois, il y aura des pens pour cela.

Taille de fonte sur Firefox

Une taille de fonte par défaut en pixels

html { font-size: 10px; }

Pourquoi dit-on que c’est mal ? Voici la raison : que ma taille de texte par défaut soit de 16px, 32px ou n’importe quoi, l’utilisation des pixels fera que le site imposera ses valeurs au visiteur. Le texte que j’ai paramétré sera affiché en 16px dans tous les cas.

C’est quand même gênant si j’ai paramétré mon navigateur pour qu’il affiche le texte plus grand ou plus petit par défaut. Ne le faites pas pour la typo, à aucun endroit. Vraiment pas.

Voir l’exemple sur Codepen : une taille de fonte par défaut en pixels.

Une taille de fonte par défaut en unités relatives

Pour cet exemple, je n’ai pas utilisé de pixels, mais des unités relatives. Rappelons que les em sont fonction de la taille de fonte de leur parent, et les rem (root-em) sont fonction de la taille de fonte de l’élément racine, soit html.

Avec une taille de fonte par défaut à 16px, pas de souci, le texte est bien affiché en 16px et le titre h1 en 32px.

Si je mets ma taille de fonte par défaut à 32px dans mon navigateur, le texte sera donc bien affiché en 32px et le titre h1 en 64px. Là, les valeurs utilisées respectent les préférences de l’utilisateur.

Voir l’exemple sur Codepen : une taille de fonte en unité relative (em).

Avec l’unité rem, le résultat est exactement le même, les préférences utilisateur sont respectées. Voir une taille de fonte en unité relative (rem).

Ok, en relatif, mais avec ou sans « reset » ?

Une pratique assez courante est d’utiliser ce genre de propriété sur l’élément html :

html { font-size: 62.5%; }

À quoi cela sert ? C’est une simple astuce pour se simplifier le calcul (que moi-même j’utilise dans Röcssti). En partant de l’idée que la taille « standard » est de 16px, 62,5% de ces 16px donneront 10px à l’affichage.

Mais alors, on ne respecte plus les préférences utilisateur ???

Bien sûr que si, on les respecte. C’est pour cela que je mets « reset » entre guillemets. Comme c’est un chiffre rond, cela simplifie juste les calculs, surtout pour l’unité rem. Avec ce « reset », 10px équivalent en permanence à 1rem. 1.4rem donne… un affichage de 14px, et ce où que l’on soit dans le document (sur le body ou ailleurs).

Si vous n’êtes pas convaincu, testez une taille de fonte en em sans « reset » ou une taille de fonte en rem sans « reset ». Les préférences utilisateur sont respectées et le résultat est le même.

Bref, avec ou sans « reset » et en em ou en rem, le résultat est le même, seules quelques valeurs changent. C’est juste un peu de gymnastique intellectuelle, à votre convenance ! Si vous préférez que 1rem soit équivalent à 10px pour vos calculs ou qu’il soit égal à « une fois la taille de fonte par défaut », c’est à votre convenance, je ne suis pas sectaire.

Le seul souci de ce « reset » est sous Internet Explorer (du 9 au 11). Une bête erreur d’arrondi peut fausser les valeurs affichées des fontes, cela se fixe ainsi :

html { 
font-size: 62.5%;
font-size: calc(1em * 0.625); /* fix */
}

Bref, pas dramatique.

Pourquoi les gens n’aiment pas le « reset » ?

En fait, c’est souvent à cause d’un oubli : le « reset » est appliqué sur html mais il n’y a pas de taille par défaut sur le body. Du coup, le moindre oubli fait qu’on se retrouve avec une taille de fonte affichée à 10px, ce qui est rikiki et souvent très disgracieux au milieu d’un beau site.

Des em ou des rem ?

Cela dépend de votre contexte. Même si je suis un très gros utilisateur des em, je les utilise surtout parce que mon contexte s’y prête bien. Ajoutons à cela que les em fonctionnent partout, même sur les vieux Internet Explorer !

Les em nécessitent :

  • soit un minimum de conventions posées,
  • soit une certaine vision d’ensemble.

Et ce afin de pouvoir gérer l’héritage de la taille de fonte du parent.

Si vous avez une équipe éclatée sans aucune vision d’ensemble sur la CSS, avec des modules développés de manière complètement autarcique, les rem seront sûrement plus faciles à gérer, vous n’aurez pas de souci d’héritage. Les rem ont cependant une petite faiblesse, ils ne sont pas du tout supportés sur Internet Explorer 8 et inférieurs.

Sur des projets plus simples à cadrer ou avec des guidelines bien posées, les em se gèrent sans trop de souci.

Après, on voit souvent cette notion d’héritage dans les em comme quelque chose de compliqué, mais cela peut aussi être une force. Un module défini en em, si l’on doit le réutiliser dans une zone différente où la taille de fonte sera plus grande, évoluera tout naturellement avec son contexte. Par exemple, un helper genre margin-top: 1em s’adaptera où qu’il soit.

Croyez-moi sur parole, dans certains cas comme pour l’obtention et la conservation d’un rythme vertical, c’est très utile. Et dites vous que vos espacements s’adapteront en fonction des préférences utilisateur.

Mon guide de survie avec les em

Quand je commence une intégration, la première question que je pose est la taille du texte courant. Car quasiment tout va dépendre de cela.

Une fois que je la connais, j’applique cette valeur sur le body (avec ou sans « reset » sur html).

Ensuite, je calcule les tailles pour les Hx et autres classes comme .big, etc. (automatisé par un pré-processeur ou via le Röcssti-Builder).

Après, je crée le site dans les conditions « standards », et ô miracle, changer la taille de fonte par défaut ne cassera rien.

Contrairement à ce que beaucoup de gens croient, appliquer une classe qui modifie la taille à un élément dont la taille est également directement modifiée en em ne pose pas de souci. Par exemple, un h1 class="h2" sera bien à la taille de la classe .h2 (vu que c’est le parent qui sert de référence). Les soucis ne sont pas là !

Par contre, les em sont compliqués quand on commence à imbriquer les classes modifiant les tailles, genre un span class="big" dans un h2.

En pratique, j’évite les imbrications hasardeuses, pas ou peu de souci d’héritage et tout se passe comme un charme.

Même mes collègues qui étaient – doux euphémisme – très réfractaires aux em s’y sont plutôt bien habitués, donc c’est bien preuve que c’est possible. :)

Alors on doit jeter les pixels aux oubliettes ?

Du calme ! Et je n’ai pas dit ça ! :)

Oui, jetez-les pour la typo. Utilisez les em, et si c’est compliqué, foncez sur les rem. Mais quoi qu’on en dise, les pixels sont bien pratiques pour discuter avec un graphiste ou un client (qui n’a aucune notion des unités relatives). C’est une unité plutôt intuitive – quoique cela se discute dès qu’on commence à discuter écran à haute densité de pixels – et que tout le monde comprend. En gros, parler en pixels est une simplicité pour l’esprit.

L’autre cas problématique est lié aux arrondis, notamment sous Chrome/Webkit. Si vous avez un sprite avec diverses images et que vous dimensionnez en em l’élément dans lequel l’image va s’afficher, des fois les arrondis sont foireux et même si la valeur est bien censée donner 15px, il peut y avoir des dépassements, catastrophique si les images dans le sprite sont serrées. Bref, dans ce cas, autant utiliser les pixels.

Idem pour les images. Ceci dit, si l’on garde la question du début « de quoi dépend réellement la valeur que je veux mettre, de quel contexte », pour une image, la réponse est tout simplement : d’elle-même. À méditer.

Et pour les media-queries ?

Je m’aperçois que ce billet est déjà bien long, je vous propose d’y revenir dans un prochain billet. N’hésitez pas à tester et à réagir.

Ajout : suite de ce billet dans Les media-queries et les préférences utilisateurs.

Grogne sur l’accessibilité (le 29/04/2016)

Un monstre coup de grogne d’un développeur concernant l’accessibilité a fait un bruit certain, la newsletter Opquast en a parlé et je vais rebondir dessus.

Remettons-tous dans l’ordre. Un article explique certains problèmes des design patterns sur des utilisateurs clavier. Voici l’article en question : Danger! ARIA tabs.

Je passe sur le côté maladroit de certaines formulations et volontairement trollesque de cet article. Je passe aussi sur le code donné en exemple, qui me semble insuffisant (comme indiqué dans ce commentaire).

Il y a par contre un problème réel (entre autres) qui mérite d’en parler (que je n’avais pas compris au début) : l’utilisateur clavier n’est pas habitué à ce qu’on lui propose ces design patterns, et souvent il est perdu (par exemple, il ne sait pas qu’il peut utiliser les flèches gauche et droite pour afficher les onglets). Ça c’est un souci réel.

Et en guise de propos, le classique « ça dépend ». Sauf que le coup de grogne mentionné plus haut est monté, et je ne suis pas loin de donner bien raison à ce développeur. Étant moi-même impliqué à développer des plugins accessibles que je déploie massivement (à peu près tous les sites que je fais les utilisent), je ne peux clairement pas entendre un « ah bin, ça dépend, et il va falloir jeter ce que vous avez fait ». Même pas en rêve.

Là je serais du genre à répondre : « sérieux les gamins, vous êtes gentils, mais je respecte vos standards, j’y contribue, j’ai des dizaines et des dizaines de sites en prod, j’ai pas le temps ni même la possibilité de faire dans le détail, bordel ! » (et encore, je suis resté poli). Pire, ce genre de naufrage peut ruiner une chiée d’efforts et de motivation. La cause de l’accessibilité n’a me semble-t-il pas besoin de ça.

Par contre, ce que je peux entendre et je regrette de ne pas l’avoir lu, c’est « continuons avec ces standards, mais améliorons-les en pratique, soyons constructifs », ce qu’Aurélien Lévy (qui m’aide beaucoup sur ces plugins) fait déjà très bien, régulièrement, on va plus loin que ce que les standards proposent pour faire mieux en pratique. On sait très bien que ce n’est pas parfait, mais il vaut mieux faire quelque chose que rien du tout.

Franchement, ne serait-il pas plus simple de partir de ces standards (qui me semblent plutôt bons), de les améliorer et d’éduquer ou d’aider l’utilisateur ?

CSS et sa légendaire facilité (le 06/04/2016)

Des fois, CSS a l’art de m’amuser. La difficulté n’est pas toujours là où l’on croit.

Je travaille actuellement sur un template monstrueusement compliqué, et au milieu de plein de trucs bien retors, j’ai une chose simple à faire. Faire un lien précédé d’un « > ». Enfin, je dis « simple », à vous de juger.

Le site en question a supprimé le soulignement des liens par défaut et l’active quand on les survole ou quand on a le focus clavier dessus. Rien de bien extraordinaire.

Je me dis qu’un pseudo-élément before suffira. Très logiquement, je fais ainsi :

.arrow-left:before {
content: '>\a0';
speak: none;
}

Petit souci, quand on survole le lien, le soulignement apparait en-dessous du « > ». Pas de souci, je me dis que je vais l’annuler. Sauf que cela ne marche pas, la propriété du pseudo-élément est héritée du lien. Sauuuuuuuuuuf…

En cherchant un peu, je trouve une solution dans la spécification CSS 2.1 de text-decoration (oui rien que cela).

Note that text decorations are not propagated to floating and absolutely positioned descendants, nor to the contents of atomic inline-level descendants such as inline blocks and inline tables.

Le soulignement n’est pas propagé si le pseudo-élément est de type inline-block. Soit.

.arrow-left:before {
content: '>\a0';
display: inline-block;
speak: none;
}

Sauvé ! Cela marche partout. Sauuuuuuuuuuf…

Sous Internet Explorer 8… jusqu’au 11 compris. C’est un bug. En continuant de chercher, je trouve une solution bizarre, mais fonctionnelle.

.arrow-left:before {
content: '>\a0';
text-decoration: underline;
display: inline-block;
speak: none;
}
/* IE… */
.arrow-left:before,
.arrow-left:focus:before,
.arrow-left:hover:before,
.arrow-left:active:before {
text-decoration: none;
}

En gros, tout redéfinir explicitement pour ré-écraser le tout après. Là notre ami Internet Explorer ne bronche plus. Voici un pen qui montre le tout.

Qui a dit que CSS était simple ? Hé bien, qu’il/elle sorte. :)

Note de lecture : CSS3 Flexbox de Raphaël Goetter (le 20/03/2016)

J’ai eu le plaisir de recevoir très rapidement le dernier livre de Raphaël Goetter, sobrement intitulé « CSS3 Flexbox, plongez dans les CSS modernes ». Ce livre est sorti depuis le 18 Février de cette année.

CSS3 Flexbox de Raphaël Goetter

Que dire de plus sur l’auteur, est-il encore besoin de le présenter ? Enragé des CSS et des Knacss, coutumier des bons livres et… coutumier des interventions sur Flexbox depuis un certain temps. Et maintenant le livre !

Ma foi, ne tournons pas autour du pot, les livres de Raphaël, c’est comme le riz d’Oncle Ben’s, c’est toujours un succès. Et ce livre sur Flexbox ne fait pas exception.

Dans un format très court de 130 pages (et donc vite et bien lu, je crois l’avoir lu en deux soirées), on a droit à un tour assez complet de ce « nouveau » mode de positionnement CSS. Je mets « nouveau » entre guillemets car cela fait de nombreuses années que Flexbox existe, vous apprendrez d’ailleurs peut-être dans le livre que son histoire a été plutôt mouvementée.

Pourtant Flexbox est souvent considéré comme relativement jeune, la faute à un support défaillant dans les Internet Explorer inférieurs au 10 (et même sous ce dernier, c’est un peu le cirque comme vous le découvrirez peut-être dans le livre), heureusement que Microsoft pousse ces vieilles versions vers le cimetière des navigateurs. Idem avec les vieilles versions de Flexbox sous Webkit, elles ne sont malheureusement pas patchées comme il faut sur bon nombre de sites, vous pouvez lire à ce sujet (en anglais) l’édifiant billet de Karl Dubost sur ce sujet : Web Compatibility in Japan.

Que dire, ce mode de positionnement est un must et permet des choses parfois délicates à obtenir avec les positionnements plus classiques, je l’ai utilisé par exemple sur les templates de la page d’accueil du Haut-Commissariat des Droits de l’Homme, sur cette petite partie sur le site de Parenti Design (pour le sacro-saint centrage vertical), sur d’autres sites… toujours en amélioration progressive (avec un modernizr, ou encore mieux, dans un @supports ce qui permet de cibler directement Edge et de passer outre les Flexbugs parfois pénibles sous IE 10/11…).

Le livre regorge d’exemples et explique très bien ces nouvelles possibilités (ordonnancement, positionnement, etc.). Point très fort, c’est très bien vulgarisé, car Flexbox est parfois quelque peu compliqué à comprendre sur certains points un peu avancés. Je me suis fait piéger quelques fois, notamment en croyant à un bug sous Firefox qui en fait n’en était pas un mais une mauvaise utilisation de ma part, ainsi qu’un mauvais comportement sous Chrome. Coquin de sort !

Au moins, avec ce livre, vous allez faire un tour d’ensemble bien complet et bien agréable de Flexbox avec des infos fraiches, bien expliquées, et vous aurez de quoi vous amuser dans vos prochaines intégrations. Vous aurez donc compris que je ne peux que vous recommander de lire ce livre.

Et y a sûrement plein de choses à imaginer pour nos prochains sites. :)

Pour trouver le livre, c’est chez Eyrolles : CSS3 Flexbox et il y a un mini-site dédié avec des ressources.

Les unités en CSS, mise à jour (le 18/03/2016)

Tiens, comme Twitter discute des unités en CSS, je participe au troll… heu, à la discussion avec mes habitudes personnelles en la matière (ce n’est pas du tout une vérité absolue, ça dépend comme on dit).

Les pixels (px)

Ils sont toujours utiles, en tout cas pour discuter avec un graphiste, s’accorder sur une idée générale, pour se comprendre dans une guideline, etc.

Mais en CSS, je reconnais que je les utilise maintenant très peu. Hormis une taille fixée arbitrairement (ça peut arriver), pour les bordures, les ombres portées, faire un hr, des fois pour fixer quelques éléments de formulaires, éviter les arrondis foireux de Chrome sur des icônes dimensionnées en em, pour les coins arrondis… et encore !

Ils sont toujours totalement bannis de la typographie et de tout ce qui peut l’impacter chez moi, notamment sur le reset sur html ou body.

Les pourcentages (%)

Je les utilise toujours beaucoup pour des grilles et tout ce qui doit/peut être fluide. C’est toujours utile pour qu’un site pas prévu pour être redimensionné le soit in fine. Une valeur sûre quoi qu’on en dise !

Les em

Clairement, depuis 5 à 6 ans, c’est l’unité que j’utilise le plus. En fait, elle sert à tout ce qui doit/peut être proportionnel à la typographie. Et comme énormément de choses peuvent être fonction de la typo en matière de web (margin, padding, width ou max-width pour éviter des lignes trop longues, etc.), je les utilise énormément.

Utiliser cette unité me permet beaucoup de choses, le tout en permettant de respecter les préférences de l’utilisateur, et en permettant un zoom.

Sur les sites en responsive, les media-queries en em ont des avantages indéniables, par exemple, zoomer fortement sur le site de Prezenz vous fera afficher la « version » mobile en très gros caractères sur votre ordinateur (même en zoom texte), cela permet d’avoir à tout instant une version dont les contenus restent agréables à consulter quel que soit le niveau de zoom.

Certaines classes atomiques de Röcssti me permettent même d’avoir un niveau d’abstraction, je ne fonctionne par exemple plus en pixels pour ajouter une marge, mais en em, c’est tellement plus pratique, et cela permet de respecter par exemple le rythme vertical du texte sans même y penser.

Certes ils peuvent être compliqués à gérer dans certains cas précis (genre beaucoup d’intervenants ne se rencontrant dans aucun dimension sur des projets très compliqués, et encore), mais la quasi-totalité de mes cas ne tombe pas dedans, donc toujours pas d’excuse.

Les nombres bruts

Dans pas mal de cas, autant éviter les unités inutiles. Pour line-height, pas besoin d’unité, pour une valeur nulle (ex : border: 0;) non plus, autant utiliser une valeur auto dans d’autres cas, etc.

vh et vw

Je les utilise de temps en temps, je disais il y a deux ans que cela viendrait, et effectivement : un de mes derniers projets (dont je n’ai pas le droit de parler) les utilise énormément. Unités intéressantes, à utiliser de manière éclairée.

Autres

Hormis un cas d’utilisation bien précis dans Röcssti (pour fixer un interlignage disgracieux en cas d’utilisation des balises sub et sup), je ne me sers jamais des ex. Idem pour les en, dont j’ignore toujours le support réel. Pareil pour les ch, je ne m’en sers jamais.

Hormis quelques cas bien particuliers de besoin de mise en forme précise pour le media print, je ne me sers jamais des mm et autres cm, idem pour les pt (points), les in inches) et les pc (pica).

Les rem sont très intéressants, mais pour le moment, je ne m’en sers que très peu, cela me fatigue clairement de devoir gérer une solution de secours en em pour les très vieux navigateurs alors que je peux clairement tout faire en em les 99% de mes cas.

Et en fait, tout le monde a pris le pli d’utiliser les em au travail, donc le besoin des rem n’est pas critique.

Il existe d’autres unités, mais elles sont tellement anecdotiques pour mon utilisation pratique…

Ma gentille stagiaire (le 11/03/2016)

J’écoutais CPU Programme sur les femmes dans la tech, et j’avoue être très circonspect sur le fait que des femmes puissent douter d’avoir leur place dans le domaine. Cela m’a donné envie de partager un retour d’expérience plutôt sympathique.

Il y a quelques mois, j’ai encadré une stagiaire.

Comme tous les stagiaires que j’ai eus à encadrer, j’évalue rapidement leurs connaissances/lacunes et je fais deux choses :

  • Je les mets en zone d’inconfort ;
  • Et je teste leur curiosité.

En l’occurrence, ladite stagiaire ne connaissait rien à PHP, et je lui ai demandé de faire quelques bricoles basiques. Je me fous de savoir si elle va y arriver ou pas, l’idée est plutôt de voir la réaction face à cet inconfort (si elle va s’entêter, essayer, questionner, etc.). Cela, c’est le premier test.

Après, si par exemple on voit les positionnements CSS, je vais lâcher un « tiens, je te conseille de lire tel bouquin/article sur le sujet, et on en recause demain hein ? ». Cette innocente phrase cache le deuxième test. Le ou la glandu(e) qui ne m’en reparle pas d’ici un jour ou deux y échouera lamentablement.

Ce ne fut pas le cas de ma stagiaire qui s’est accrochée. Elle aurait pu se dire « mais quel salaud celui-là, il me file un truc impossible » ou je-ne-sais-quel-truc à la noix, mais elle ne l’a pas fait. Certes, je n’attends pas d’un stagiaire de lire et de maîtriser un pavé sur CSS en 2 jours, je ne suis pas un salopard non plus.

Et du coup, étant content de cela – croyez-le ou non, ça me fait vraiment plaisir que quelqu’un s’intéresse à ce que je prends le temps de lui raconter –, je lui ai mitonné un programme d’enfer (j’adore enseigner). Elle voulait avoir une bonne vision d’ensemble du front-end, elle a été gâtée. Qualité web, accessibilité (avec démos et cas concrets), intégration, responsive, animations/transitions/méthodos CSS, JavaScript, jQuery, du Röcssti, de la pratique et de la théorie, on s’est même amusés à bidouiller des trucs que je voulais découvrir à la ligne de commande (Gulp) afin qu’elle voie comment on fait quand on ne connait pas un truc, etc.

Certes, je ne peux pas lui transmettre mes 12 ans d’expérience en quelques semaines, mais je me suis fait plaisir à faire le tour de ce que je connais avec elle. Le moins qu’on puisse dire, c’est que cela a été intense.

Vous ne remarquez rien ? Il n’y a aucun pré-requis lié au sexe, manifester de la curiosité et de l’intérêt n’est pas l’apanage d’un genre en particulier. Cela me débecte de le dire tellement c’est idiot, mais au boulot, que vous ayez une chatoune ou une zigounette, je m’en fous.

On m’a déjà suggéré de faire une forme de discrimination positive, façon « vu qu’il y a moins de femmes dans la tech., tu pourrais être plus cool ».

Sûrement pas.

À compétence égale entre deux personnes, je n’ai pas d’avis sur la question. Mais dans mon cas, je crains que ce soit le meilleur moyen d’instaurer justement un doute sur les compétences (« oui, elle a eu un super stage parce que c’est une femme »). Là dans notre cas, cette stagiaire a prouvé sa motivation sur le même test pour tous les stagiaires sous mon aile, et cela ne souffre aucune discussion, et aucune remarque sexiste.

Si vous en doutez encore, certains mecs ont réussi et d’autres ont échoué lamentablement. Tous ont eu un stage en rapport avec la curiosité et le respect qu’ils ont manifesté. Hé oui, manque de chance, je connais parfaitement les bouquins que je conseille, idem pour les articles (qui sont parfois des articles que j’ai écrits…). Le dernier qui a voulu me rouler dans la farine n’a pas fait long feu.

Maintenant, vous comprenez que le titre de ce billet n’est pas de la condescendance ou quelque chose de péjoratif, j’ai vraiment eu une gentille stagiaire, avec tout ce que ce mot a de positif. Et des comme ça, j’en veux bien encore.

Retour d’expérience sur un plugin accessible (le 26/02/2016)

Sur le dernier plug-in accessible jQuery accessible autocomplete list récemment mis en ligne, j’ai rencontré quelques surprises que je vais vous relater dans un mini-retour d’expérience ici-tout-de-suite.

Plugin autocomplete

Un bref historique

Grosso modo, l’idée est partie d’un exemple de Heydon Pickering. Aurélien l’a repris, amélioré et m’a soumis un prototype, afin que je le « package » dans un plug-in. Je commence à avoir l’habitude, j’en suis à mon neuvième plugin. :)

On a fonctionné en tandem : Aurélien m’amenant le prototype, les comportements attendus et la connaissance fine des problématiques d’accessibilité (oui rien que cela !), et moi amenant le côté pratique/industrialisation/amélioration progressive du tout.

Amélioration progressive

Autant j’étais chaud pour certains plug-ins, autant je n’ai pas compris l’intérêt de celui-là… au début. Pourquoi réinventer la roue ? Un input avec un datalist fait très bien le job.

Oui, sauf que… non, pas du tout, j’étais lourdement à côté de la plaque.

Un rapide test sous Firefox/NVDA - depuis l’atelier de Paris Web, je n’hésite plus une seconde - me confirme que les suggestions d’un input/datalist ne sont pas du tout vocalisées. J’étais persuadé du contraire, bien mal m’en a pris.

Du coup, je révise complètement mon jugement et je me dis que cela pourrait effectivement être bien. Aurélien a déjà bien prémâché mon travail, j’ai un exemple qui fonctionne, et je n’ai « plus qu’à » le reconstruire.

Comme j’aime bien l’idée de l’amélioration progressive, je vais repartir d’un input/datalist (qui est déjà fonctionnel au clavier et sans JavaScript) et à partir de ces données, re-construire l’exemple. Grosso modo, prendre ces données, les stocker dans un tableau, manipuler le DOM pour obtenir ce qu’Aurélien m’avait donné dans son prototype, ajouter les événements qui vont bien et ajouter des options pour customiser le tout et le rendre plus facilement déployable/réutilisable.

Sortir le moins possible des comportements naturels

Si vous avez déjà utilisé VoiceOver sur un iPad, vous pouvez naviguer de manière analogue à des tabulations sur un clavier « classique », en gros, vous faites glisser votre doigt sur l’écran de gauche à droite pour faire une tabulation Tab, et de droite à gauche pour faire une tabulation inverse Maj+Tab.

Cela nous a indiqué à Aurélien et moi de ne pas restreindre la tabulation. Au moins l’utilisateur de ce mode de navigation sous VoiceOver sur iPad ne sera pas bloqué.

À un moment, je rencontre le souci suivant : quand on active une suggestion, cela la met dans le champ, puis… cela réactive les suggestions, vu qu’on est dans le champ et qu’on a encore le doigt sur Enter. Dommage, vu que la suggestion est juste après le champ dans l’ordre… on vient de créer un magnifique piège à doigt sur VoiceOver sur iPad, et aussi un piège à clavier.

Idée : interdire l’utilisation de Enter dans ce champ (vu que taper Enter dans la suggestion activait aussi Enter dans ce champ, ce qui lançait les suggestions, ces dernières s’activant dès qu’on touche au clavier dans le champ, vous suivez ?). Super, cela marche et cela résout mon problème !

Enfin, c’est une magnifique… fausse-bonne idée, voici le pourquoi ci-dessous.

Tester, tester, tester

À un autre moment, le développement était bien avancé, les suggestions s’affichaient bien, on pouvait tabuler dedans sans souci. Le plug-in marchait ! Il marchait tellement bien que j’en avais oublié l’essentiel : comme j’avais interdit certaines touches dans le champ, si l’on faisait Enter dedans (pour soumettre le formulaire)… cette touche était bloquée. Gag.

C’est un problème que je constate souvent : en voulant trop bien faire ou dans le feu de l’action, on finit par couper ou casser un comportement basique. N’oubliez jamais que votre test peut avoir d’autres champs à côté, avant ou après, et testez toujours les contrôles de bases.

Du coup, retour au problème qui m’a emmené dans cette mauvaise direction, l’activation d’une suggestion. Finalement, une idée toute simple résoudra le tout, mettre un imperceptible délai. Plus besoin de bloquer Enter, et donc plus de problème pour soumettre le formulaire.

Méfiez-vous de l’évidence

A posteriori, on peut toujours dire que c’est bateau, c’est évident, c’est grossier comme erreur… sauf que pas du tout. Dans le feu de l’action et avec des tests pas totalement naturels, c’est très facile de commettre ce genre d’erreurs, même avec les meilleures intentions. Surtout avec les meilleures intentions.

N’oubliez jamais de sortir la tête du guidon quand vous développez/testez, particulièrement en matière d’accessibilité. Testez au clavier, à la souris, avec une synthèse vocale, à la tabulation, sur tablette, sur tablette avec une synthèse vocale, etc.

Dites-vous bien que moins vous vous éloignerez des comportements de base, moins vous prendrez de risques.

Chère Fondation Mozilla, tu me permettras de te tutoyer (le 10/02/2016)

Chère Fondation Mozilla, tu me permettras de te tutoyer, et je t’appellerai MoFo afin de faire plus court.

Une chose me fascine chez toi, c’est ta singularité. Tristan Nitot, un de tes anciens « cadres », disait très justement lors d’une interview pour les 10 ans de Firefox :

Rien n’est jamais facile chez Mozilla : nous existons pour défier le statu quo.

Je trouve dommage que bon nombre de personnes oublient cette singularité. C’est peut-être la rançon de la gloire, les gens oublient que ton existence même est une singularité. Des milliers de bénévoles, une relative « petitesse » calée entre d’énormes acteurs avec d’énormes moyens financiers (Google, Apple, Microsoft…), un statut à part, pas d’actionnaires, etc. Quoi qu’on en dise, la MoFo, c’est une curiosité !

Je suis comme ça, ne m’en veux pas : quand je vais voir un concert, je suis presque plus fasciné par la foule que par le concert en lui-même. J’aime regarder les gens, c’est au moins aussi fascinant que la performance en elle-même.

Ajoutons à cela que ton histoire n’est pas triste non plus : tu es née de la mort de Netscape, qui a été lui-même ultra-dominant et qui s’est fait étouffer par Internet Explorer. En matière de résilience, c’est une histoire… singulière. On en revient tout le temps à ce mot. :)

Et pourtant, tu déchaines les passions. Autant chez tes détracteurs que chez tes supporters. On dit que l’amour n’est pas très différent de la haine, ce proverbe n’a jamais été aussi vrai qu’en ce qui te concerne. Et ce n’est pas nouveau, on en parlait par blogs interposés déjà en 2011, et ça interrogeait encore des personnes 2 ans plus tard. Et on n’est pas les seuls, loin de là.

En fait, je m’interroge sur le pourquoi de cette passion.

Mon avis personnel – qui assume clairement les limites de sa clairvoyance – est que tu incarnes une forme d’utopie dans la perception qu’on a de toi. Le petit poucet, le compétiteur qui n’est pas mû par l’argent, l’acteur qui veut incarner une forme d’intérêt général. Quoi qu’on en dise, incarner cela déchaine autant les passions positives que négatives. Les fans adorent, les antis n’y croient pas. Fais-en l’expérience : fais lire ton propre manifeste à un fan ou à un anti, cela ne peut pas ne pas les faire réagir. Les fans vont mettre la main sur le coeur et enlever leur couvre-chef, les antis vont le mettre à l’épreuve ou le critiquer.

Moi-même, je n’échappe pas à cette passion : tu es liée à ma propre histoire. Casser le monopole d’Internet Explorer 6 nous a fait sortir d’une période moyenâgeuse pour le Web. Quand je vois aujourd’hui que des (grands) gamins ronchonnent parce qu’ils ne peuvent pas utiliser des trucs cools comme Flexbox ou je-ne-sais-quel-truc comme GridLayout, j’ai envie de leur rappeler qu’il y a un peu plus de 10 ans, les trucs dingues qu’on voulait faire étaient… des coins arrondis ou du display: table en CSS. Hé oui, nous sommes partis de très loin. Rien que pour ta contribution à promouvoir des standards et une saine concurrence, je t’en suis redevable. Et j’aime à penser qu’un compétiteur non mû par l’argent (même s’il en a besoin comme tout le monde) est nécessaire.

Et quoi qu’on en dise, tu n’as jamais été ménagée. Je me souviens du séisme annoncé du rapid release process pour Firefox 5. Et tu y es arrivé. Et il n’y a pas eu de séisme. Et les exemples sont légion, peut-être les devins de tous poils aiment annoncer ou commenter à grands renforts de mots exagérés. Laissons-les dire, cela les occupe.

Je trouve que tu n’es pas épargnée non plus ces temps-ci. Critiquée par beaucoup, à tort ou à raison, ce n’est même pas ce dont je veux te parler ici, il y en a suffisamment qui le font déjà, parfois de manière assez juste, parfois de manière acerbe. C’est le lot de la passion. Je ne veux pas être l’énième à le faire. La passion me fatigue.

On dit que dans les moments difficiles, les amis ne sont pas là pour accabler encore plus, mais pour permettre de respirer. Les amis sont là pour te dire les choses avec tact mais sans pour autant oublier le fond. Et te rappeler pourquoi ils t’aiment.

  • J’aime le Mozilla Developer Network. De plus en plus maintenant que je me mets sérieusement à JavaScript.
  • J’aime ton inspecteur de code sous Firefox. De plus en plus aussi.
  • J’aime les efforts que tu as fait pour que Firefox bouffe moins de mémoire et soit devenu très très rapide, particulièrement à mon boulot.
  • J’aime aussi le fait que tu soies un maillon important dans le respect de ma vie privée (ça j’ai toujours aimé).
  • J’aime aussi les extensions de Firefox (ça aussi j’ai toujours aimé).
  • J’aime aussi ton niveau d’accessibilité (ça aussi j’ai toujours aimé, et de plus en plus).
  • J’aime ton manifeste.
  • Et je n’aime pas seulement les points précédents.

Pourquoi je te dis cela ? J’aime rétablir une forme d’équilibre. Quand beaucoup te critiquent, je veux te rappeler pourquoi je t’apprécie. Et tant pis si je suis le seul, j’assume ma propre singularité d’amateur des causes difficiles. :)

Et en bon ami, je me fais du souci pour toi. Car je ne vois pas comment te le dire autrement : nous avons besoin de toi. Pour le Web, pour la diversité, pour les standards, pour 10000 raisons… et à plus modeste échelle ne serait-ce que pour mon travail. Pas en situation de monopole, pas flamboyante à 75% de part de marché, je ne veux pas te demander l’impossible. Mais dans une bonne forme. Car les constructeurs de navigateurs sont devenus une pièce maîtresse sur le Web, on s’en est enfin rendu compte.

Je veux croire à ta capacité de résilience. À ta capacité de défier le status quo et à faire mentir les prophéties auto-réalisatrices. Même si ça n’est pas toujours facile ou agréable. Ton bébé phare est à l’origine un Phoenix qui a su prendre son envol. Je veux que tu ailles bien car le Web sans toi, ce n’est pas pareil. Le Web a une place importante dans ma vie, c’est mon travail, ma passion, etc.

Sans toi, tout cela n’est pas pareil.

Pensez à renvoyer l’ascenseur (le 03/02/2016)

Hier soir, j’ai reçu un petit mail qui m’a beaucoup fait plaisir. Je rentrais d’une journée très dure de travail où j’en avais plein les bottes, et je tombe sur un message tout simple. Une personne bien aimable m’a indiqué qu’elle a utilisé un de mes plug-ins accessibles et m’a suggéré une amélioration. Ledit mail faisait 4 lignes, et c’était très aimable. L’amélioration m’a pris 2 minutes à mettre en place.

Dans le même genre, j’avais tweeté ceci de manière humoristique en plagiant ce cher ami Brassens :

Ce n’était qu’une pull-request mais elle m’avait chauffé le cœur et dans mon âme elle brule encor’ merci @ffoodd_fr

J’imagine que sur des projets d’énorme ampleur, plutôt bien installés, recevoir dix mille e-mails par jour (même sympas) doit être assez fatigant. Clairement, ces projets ne sont pas nécessairement dans la même optique.

Par contre, sur des projets « modestes » comme mes plugins accessibles, je peux vous assurer que j’apprécie d’avoir des retours. Un simple « merci » doit coûter environ une minute à taper, par contre, pour moi, cela met vraiment du carburant dans la machine.

Sans prendre la parole à la place de tous les développeurs qui font pareil en mettant plein de choses à disposition, je suis sûr qu’un message sympathique et aimable leur fera toujours plaisir.

Certes, certaines demandes doivent attendre, les développeurs ne peuvent pas répondre dans la minute à tout. Ne serait-ce que par simple manque de temps ou de connaissances (bah oui, nous n’avons pas la science infuse, loiiiiiiiin de là). Ou parfois, la demande n’est pas une priorité absolue pour nous, ce qui ne veut pas dire qu’elle ne sera pas traitée pour autant.

Ceci dit, pour aider les gens qui développent des choses et qui peuvent/pourraient avoir du mal à sauter le pas de continuer à offrir tout cela, pensez à renvoyer l’ascenseur. Pour vous donner une idée, sur ces plug-ins, je suis allé loin dans le lâcher-prise :

  • Aucun code de suivi genre Google Analytics sur les pages de présentation ;
  • Une licence MIT très permissive.

Grosso modo, je ne sais pas qui en parle ni qui les utilise, ni où. Le noir absolu. Cela vous parait incroyable ? C’est le choix que font des milliers de gens qui mettent du code, de la connaissance, des outils, etc. à disposition. C’est idiot de le dire, mais la plupart ne sont pas payés pour tout ce travail (pas du tout ou pas directement). Non pas qu’il faille leur envoyer de l’argent (ce n’est pas le sujet), mais ils pourraient faire le choix de regarder un film ou d’aller pêcher des truites, même si le code/l’écriture/etc. est une de leur(s) passion(s).

Qu’on s’entende bien : personne de sensé n’a besoin d’avoir 1000 e-mails par jour vantant ses mérites (sauf problème manifeste d’ego surdimensionné). Mais une fois de temps en temps, vous avez une idée, vous êtes content, c’est simple : dites-le.

Pourquoi pensez-vous que je fasse sur ce site des notes de lecture sur les livres qui me plaisent ? Simplement pour modestement dire merci aux gens pour leur travail. Même s’il m’arrive d’acheter leur travail (un livre par exemple), je me dis que c’est un petit geste qui fait plaisir et qui va leur mettre aussi du carburant dans la machine. Idem pour les rapports de bugs, des fois, je consacre une soirée pour un outil que j’aime bien, et j’envoie des bugs/suggestions. Ou je file un coup de main sur ce que je sais faire.

Dites-vous bien que vos super-héros ne sont que des gens, qu’ils peuvent être fatigués, en avoir marre, etc. Soignez vos super-héros. Faites-les durer.

Les super-héros sont là pour vous sauver, ça vous l’avez lu dans bon nombre de comics. Perso, j’ai un paquet de super-héros et de super-héroïnes sur le Web. Ce que les comics disent moins, c’est que vous êtes là pour sauver vos super-héros. Et peut-être, vous serez les super-héros de vos super-héros.

Note de lecture : Design d’icônes : le manuel (le 31/01/2016)

Une opération de financement participatif a été récemment lancée à l’initiative du Train de 13H37, et ce pour coucher sur le papier deux ouvrages. J’avais déjà eu le plaisir de lire la dette technique, par Bastien Jaillot, et je l’avais beaucoup apprécié. Au final, cette opération a été couronnée de succès, et donc j’en ai reçu la version papier.

Ce deuxième ouvrage qui s’est vu imprimé est le livre de Sébastien Desbenoit : « Design d’icônes : le manuel », également reçu.

Design d’icônes : le manuel, par Sébastien Desbenoit

Une fois n’est pas coutume, citons la page de présentation dudit livre :

Les icônes sont partout. Sur nos voitures, sur nos téléphones, sur les étiquettes de nos vêtements, sur le web…

Hé oui, c’est vrai. Les icônes sont partout. Je m’en suis rendu compte, comme je lisais ce livre dans divers endroits, du coup je me suis mis à y faire plus attention. Du coup, les blagues sur les icônes vides de sens ou mal pensées me parlent beaucoup plus, maintenant que j’ai lu ce livre.

Autant le dire sans plus de détour : ce livre est tip-top. Sébastien arrive à expliquer avec beaucoup de simplicité ce sujet… loin d’être simple. Surtout pour un béotien sur le sujet comme moi (n’étant pas versé dans le design, et encore moins dans ce domaine spécifique). Les nombreux problèmes de différences culturelles, d’internationalisation, de standardisation, de contre-sens, etc. ne m’avaient jamais effleuré l’esprit.

J’avoue honnêtement ne pas m’être posé tant de questions quand il m’est arrivé d’utiliser des icônes. Enfin, jusqu’à présent. :)

Sébastien pose également le vocabulaire, le pourquoi de leur omniprésence, l’importance du contexte dans lequel ils sont utilisés, ainsi que le cheminement pour leur création (en 3 actes). Autrement dit, c’est très complet.

Bref, vous l’aurez compris, je ne peux que vous recommander de lire cet ouvrage : c’est très bien écrit, le format court et le texte parfaitement condensé et bien équilibré en rend la lecture très aisée, sans pour autant en sacrifier sur la richesse ou la technicité du sujet. Et cela me fait du bien de varier les plaisirs de lecture.

Pour trouver ce livre, c’est par ici : Design d’icônes : le manuel, par Sébastien Desbenoit.

Message privé à l’auteur : je me suis même surpris à me faire la remarque : l’icône de l’horloge page 82 (celle du milieu), elle me fait aussi penser à un viseur de lunette de fusil, braqué sur un oiseau (tu vérifieras ;)).

2016, rêver le futur, le futur rêvé (le 03/01/2016)

Assurément, 2015 restera comme une année bizarre, surtout sur le contexte extérieur au web : terrorisme, xénophobie qui ne se cache même plus en France (et pas que), raccourcis faciles, pauvreté intellectuelle, etc.

Si j’osais une analogie Star Wars-ienne, je dirais que le voile du côté obscur s’est déchiré, pour citer ce cher Yoda.

Yoda

Bilan étrange

Même sur le côté professionnel, c’est contrasté : j’ai pu travailler sur des projets très intéressants… et sur des choses qui le furent un peu moins. Sur certains projets, j’ai clairement pu me marrer comme un cochon en CSS en m’autorisant des choses que je ne pouvais pas faire jusqu’à présent.

Et sur le « à côté », c’est également contrasté : j’ai pu écrire un nombre plutôt bon d’articles, mais je n’ai pas eu le temps d’écrire la moitié de ce que j’avais en tête. Le refonte de ce site a pris beaucoup de retard. J’ai pas pu lire tout ce que j’avais prévu aussi. Bref, je suis à la bourre.

Clairement, je n’ai pas envie de retenir le négatif. J’ai envie de me souvenir de belles choses.

  • Un Paris Web particulièrement réussi, pareil pour la Kiwiparty et mon premier Web In Alps ;
  • Des rencontres grâce au web toujours plus agréables et enrichissantes, des moments de pur bonheur ;
  • Construire Opquast V3, c’est toujours stimulant !
  • Pleins de choses apprises en accessibilité ;
  • Idem en CSS ;
  • Röcssti qui continue bien son bonhomme de chemin (via le builder, l’amélioration du site, etc.) en mode force tranquille ;
  • Les vieux Internet Explorer qui sont prêts à mourir, remplacés par un rutilant Edge ;
  • Etc.

Et pour 2016 ?

Il y a une loi tacite chez moi qui dit que soit le côté « projets persos » tire le côté professionnel, soit c’est le côté pro qui tire vers le haut les projets persos. C’est ainsi que j’ai toujours progressé. Avant c’était par alternance, maintenant, c’est en même temps, foisonnement du Web et du front-end obligent. :)

Typiquement, CSP est une découverte que je rentrerais plus dans la case projet perso (fait sur mon temps libre), et ça tire vers le haut le côté pro (le déployer m’a beaucoup fait progresser).

Les connaissances que j’ai apprises côté pro ne se voient clairement plus sur mon site personnel : cela sera un gros chantier pour 2016, et c’est déjà commencé pour tout dire.
Un autre chantier sera sur mes plug-ins accessibles : sachez qu’un petit nouveau arrivera bientôt, et les actuels se verront gratifiés de versions en VanillaJS. Oui, ES6/2015 sera un énorme chantier pour moi, je pars de très loin, et j’y travaille déjà activement.

Côté Openweb, je suis au regret de vous annoncer… que j’ai toujours le feu sacré ! Ce projet aura sa part de mon temps en 2016.

Pour conclure

Histoire de finir sur une note plus légère et toujours Star Wars-ienne : j’ai senti des réveils dans la force. Les avez-vous sentis ?

Ils sont nombreux. Des gens au potentiel énorme. Vraiment costauds. Des étoiles montantes. Du solide. De gros mouvements de fond. Des valeurs sûres. De grands changements. Des valeurs sûres, encore. Des trucs dingues. Des femmes qui assurent. Beaucoup. Encore. Tout le temps. Sans arrêt. Et j’en oublie des giga-tonnes.

Il n’appartient qu’à nous de laisser de côté l’inintéressant et de (sup)porter toutes ces choses qui nous importent. Humblement. Avec détermination. Parce qu’on n’a pas besoin de justification. Tout cela va nous nourrir. 2016 pourrait vraiment envoyer du pâté.

Et disons-le clairement pour 2016 : Merde au syndrome de l’imposteur, cette année, on lui pète sa tronche à celui-là, plus d’excuse !

Designer en tant que développeur ? (le 24/12/2015)

Je profite de la sortie en vidéo de la chouette intervention de Marie Guillaumet à Paris Web 2015 « Design de soi : valoriser son identité et son expertise sur le web » pour rebondir sur les questions posées en fin de cette vidéo. Je vous conseille de voir absolument cette vidéo !

Comment faire quand on n’est pas graphiste/designer/etc. ?

La première chose, sauf si vous êtes un pur de dur qui ne fait que de l’assembleur et qui n’a pas vu un être humain depuis sa plus tendre enfance parmi les loups et autres sta et bne (des commandes d’assembleur), c’est déjà de vous dire que vous ne partez pas de zéro. Jusqu’à preuve du contraire, vous êtes capable d’exprimer un sentiment, un objectif, une envie, etc. !

Certes, je sais bricoler sous Photoshop, mais pour tout dire, je suis « un benêt à deux mains gauches dans le même sabot droit » quand il s’agit de concevoir un design from scratch sous Photoshop ou Illustrator, et j’imagine que je ne dois pas être le seul développeur/intégrateur dans ce cas.

La seconde chose, c’est d’arrêter de voir les personnes étranges qui manipulent Photoshop/Illustrator comme des artistes (sous-entendu : perchés, qui carburent à la coke, déconnectés de la réalité) et de les voir comme des designers. Si si. J’entends par là qu’ils ne sont pas là pour faire ce qu’ils veulent mais ce dont vous avez besoin : ils vont écouter votre besoin, votre envie, votre intention, etc. et ils vont devoir traduire ça en terme d’identité graphique, univers, etc. C’est même un bon moyen de différencier des doux planeurs de vrais designers.

La troisième chose, c’est de ne surtout pas être gêné d’utiliser un designer. D’ailleurs, vous n’utilisez pas cette personne (sauf si vous l’avez enfermé dans une cave et que vous le nourrissez de bouts de rats), vous utilisez ses compétences. On peut tourner le problème comme on veut, mais à un moment, il faut reconnaitre que c’est un métier et point barre.

Même si :

  • en bon curieux, je lis plein de choses sur le sujet ;
  • mon métier me fait beaucoup travailler avec (je traduis des designs en responsive) ;
  • à force de travailler avec mon graphiste, je choppe certains de ses réflexes (Aère ! Cherche des alignements ! Etc.) ;
  • et finalement, je suis même capable de dire si un design est réussi ou pas.

Hé bien, je reste bien incapable d’en pondre un, techniquement parlant. C’est normal, ce n’est pas ma spécialité, ce n’est pas mon métier.

Pour vous donner un exemple, prenons le site de Röcssti, et entrons dans le processus créatif.

La conception du design de Röcssti

Au tout début, j’avais fait une petite page toute bête avec quelques blocs, et un logo improvisé vite fait. Vous pouvez voir l’ancienne page sur WayBack machine . Ce n’est pas honteux, pour la bonne et simple raison que c’était un tout petit projet personnel pour lequel je n’avais pas prévu de faire plus.

Donc mes maigres compétences étaient largement suffisantes pour mon besoin : permettre que les gens lisent une page.

S’est trouvé que là où je travaille, mon graphiste de l’époque était d’accord de me pondre un design (logo plus site). Et j’avais envie de donner un plus bel écrin à ce projet personnel.

Avant même qu’il ne commence quoi que ce soit, mes intentions étaient les suivantes, voici exactement ce que je lui ai dit :

  • Jouer à 600% la carte Swiss-made, Swiss-quality (avec un nom tel que Röcssti, on assume totalement)
  • Quelque chose de chaleureux, surtout pas de page froide, technologique et glaciale (on doit se sentir dans un châlet Suisse)
  • On ne se prend pas au sérieux !
  • Et l’intégration en responsive est souvent vu comme quelque chose de compliqué, donc je veux donner une intention globale de simplicité et de facilité. Il faut que cela rassure.

Vous voyez, pas besoin d’être designer au sens strict pour donner une ou des intention(s). Et selon moi, c’est capital que vous le fassiez ! Mettez vos valeurs, vos envies, etc. sur la table !

Du coup, on s’est posé la question suivante : dans l’imaginaire collectif, à quoi pense-t-on quand on parle de Suisse ? Le chocolat, le drapeau, l’edelweiss, le fromage, les montagnes, les montres, les prés verdoyants, la qualité, etc.

La première chose à venir fut le logo, dans une forme très proche de la version finale. Faire un logo est quelque chose de très difficile pour moi, mon graphiste l’a posé bien plus vite, bien mieux et bien plus efficacement que ce que j’aurais jamais pu faire.

Une première maquette (que je n’ai malheureusement pas retrouvée) était avec une jolie montagne, façon là-hauuuuuuuuuuuut sur la montagneuuuuuuuuuuuuu. L’idée était sympa et le côté micro-framework des montagnes fonctionnait bien. Toutefois, le graphiste n’était pas complètement satisfait.

Une seconde maquette donnait ceci.

Une maquette du site Röcssti

On était déjà très proches du résultat final. Bref, quelques retouches après, le design global fut posé. Grosso modo, on l’a juste simplifié afin de ne pas non plus en faire des gigatonnes. On avait eu des idées délirantes comme animer le bandeau, etc. mais on a fait le tri.

Le design ne s’arrête pas au « graphisme »

En gros, ça y est, j’ai un bon début d’univers graphique. Mais il y a encore beaucoup de travail, et c’est là que – même si je ne suis pas designer au sens strict – je vais quand même fortement participer à ce processus de design. Si si, un développeur peut être créatif.

Le contenu et sa mise en forme via CSS est une solide étape. En voici quelques exemples.

Typiquement, les boutons CTA ont une cohérence : flèche fine pour le téléchargement, triangle pour les liens, flèche de sortie pour les liens externes.

Le travail typographique est important aussi : faire une esquisse de rythme vertical, respecter les conventions micro-typographiques selon la langue (c’est peut-être un détail pour vous, mais pour moi ça veut dire beaucoup), c’est du travail de design. La typographie, c’est quand même très important sur le web.

Aérer tout cela, faire des boutons suffisamment gros qui donnent envie de cliquer, pondre des contenus aussi attrayants que possible, faire marcher le tout en responsive, etc. c’est aussi du design et de la conception.

La vache que vous avez vu sur les premiers designs a été réutilisée pour la page d’erreur 404 par exemple, en clin d’oeil pour mon graphiste qui adorait cette vache.

Et une de mes intentions était de ne pas se prendre au sérieux. Les 42 Röcssti-quotes, le Konami code, les vannes comme le bouton pour générer un build, les bêtises dans les nouvelles en-dessous de la date, les sottises dans les crédits, etc. On est bien d’accord, ce sont peut-être des détails, mais cela participe à l’intention de base du site. Je ne peux pas envisager Röcssti sans ce côté sympathique, je laisse les pages glacées aux super-frameworks.

C’est un parti pris, qui peut totalement déplaire, mais c’est ainsi que je veux le définir.

En conclusion

N’ayez pas peur de vous servir des compétences d’un designer. Je le redis, il n’y a aucune honte à aller chercher des compétences que vous n’avez pas. Reconnaitre ses incompétences, c’est déjà faire preuve de sagesse. Personnellement, je suis peut-être pas mauvais pour responsiver un design mais je suis totalement incapable de pondre un logo (même si je peux dire si un logo est bon ou pas) ou un graphisme (idem). C’est comme ça, c’est pas grave.

Il ne va pas parler de vous à votre place, il va juste vous aider à mieux le faire. Regardez la page de départ de Röcssti et le site actuel, c’est dur de ne pas dire que c’est mieux maintenant.

Je suis d’ailleurs en train de faire le même chemin pour ce site personnel, qui va subir un lifting profond, aussi vite que possible. Encore une fois, le processus créatif est le même : les intentions, se définir, etc. On a déjà le logo, le design suivra. Mon graphiste a d’ailleurs adoré que je donne des intentions, et du coup, il s’amuse plutôt bien à créer un petit univers autour de tout cela, qui va être radicalement différent de celui de Röcssti.

Ne dites plus : je ne sais pas. Vous êtes capables d’exprimer des émotions et des intentions. Vous êtes capables de vous définir (même si c’est pas toujours facile) ou de définir quelque chose. Croyez-moi, définir un univers pour une « marque » (aussi humble soit-elle comme celle de Röcssti), c’est super sympa.

J’adore cet exercice pour ma part… et il n’y a aucune raison que vous en soyez incapable.

Joyeux Noël !

Animation, accessibilité et CSS (le 04/12/2015)

Sur le dernier site sur lequel je travaille, mon graphiste m’a gentiment demandé d’animer mon plugin hide-show system, pour que les contenus apparaissent progressivement avec un bel effet de fondu. En cogitant un peu avec ma gentille stagiaire, nous sommes arrivés à une solution que je vous détaille ici.

PLugin Hide/Show

Les seuls moyens de rendre un contenu non focusable (au clavier) sont :

  1. soit de le cacher avec un display: none ;
  2. soit avec un visibility: hidden ;
  3. ou soit de rendre non focusables tous les éléments (dudit contenu) pouvant l’être via un tabindex="-1".

Mon plug-in avait utilisé la solution la plus simple, la première : display: none. Mes burger-icons utilisent la troisième, vu que les éléments cachés sont de type liens (et donc plus ou moins connus et prévisibles).

Quelques points à savoir :

  • Comme je l’avais écrit dans mon billet , on ne peut pas animer la propriété height de 0 à auto, il faut une valeur numérique. Dura lex sed lex.
  • Il faudra donc animer la propriété max-height de 0 à une valeur suffisante mais pas trop afin que l’animation soit rapide…
  • … et seul problème, un élément avec un max-height même à une valeur de 0 laisse son contenu focusable.
  • La propriété display n’est pas animable ou « transitionnable ». Dura lex sed lex².

Comme je n’ai aucune prévisibilité sur le contenu – il peut y avoir déjà des éléments avec tabindex="-1", cela devient très casse-pied, il faut les marquer pour les retrouver, etc. – j’ai écarté d’emblée la troisième solution. Comme la propriété display n’est pas animable, exit aussi. Il me reste donc la propriété visibility en roue de secours.

Rappelons son fonctionnement : cette propriété rend visible ou non le contenu auquel elle s’applique, mais elle ne change pas la place qu’il occupe, qu’il soit visible ou non.

J’ai bien essayé quelques animations CSS, mais hormis des résultats rigolos qui vous feraient vous inquiéter sur ma santé mentale, rien de bien tangible. Bref, l’idée est de revenir aux bases, les transitions CSS (après tout, on parle bien d’une transition entre deux états).

Bref, mon plug-in hide-show permet de connaitre l’état caché ou non caché une fois que le JavaScript applique lesdits états. Donc en supposant que j’ai utilisé l’attribut data-hideshow-prefix-class="animated" qui va donc préfixer les classes appliquées par ledit plug-in, cela nous donne .animated-expandmore__to_expand pour le contenu dans l’état « affiché » et [aria-hidden=true].animated-expandmore__to_expand pour le contenu dans l’état « caché ».

Pour être même plus précis : .animated-expandmore__to_expand cible tous les états et [aria-hidden=true].animated-expandmore__to_expand cible uniquement l’état caché (qui peut donc surcharger le précédent).

La première idée fut de faire cela (je mets le code sans préfixes pour des raisons de longueur) :

/* ouvert */
.animated-expandmore__to_expand {
display: block;
overflow: hidden;
max-height: 80em;
visibility: visible;
transition: visibility 1s ease, max-height 1s ease;
}
/* fermé */
[aria-hidden=true].animated-expandmore__to_expand {
display: block;
max-height: 0;
visibility: hidden;
}

Cela semble logique, toutefois, cela ne donne pas le résultat attendu : la propriété visibility n’a pas d’état « intermédiaire », c’est visible ou invisible. Si je ne la mets pas dans la transition, quand on cache le contenu, tout devient invisible d’un coup et se ferme ensuite. Pas génial.

Du coup, la propriété opacity va rentrer dans le jeu :

/* ouvert */
.animated-expandmore__to_expand {
display: block;
overflow: hidden;
opacity: 1;
max-height: 80em;
visibility: visible;
transition: visibility 1s ease, max-height 1s ease, opacity 1s ease;
}
/* fermé */
[aria-hidden=true].animated-expandmore__to_expand {
display: block;
opacity: 0;
max-height: 0;
visibility: hidden;
}

Là cela marche bien. Il y a toutefois un truc qui me chagrine, c’est l’état « indéfini » de la propriété visibility durant la transition. Cette propriété ne me sert in fine qu’à cacher le contenu au clavier. Du coup, cela me fait deux cas :

  • Quand on affiche le contenu, il faut que je passe de suite visibility de hidden à visible ;
  • Et quand on cache le contenu, il faut que visibility passe de visible à hidden uniquement à la fin de l’animation.

Bien sûr, hors de question – même si c’est faisable, je l’ai fait sur mon carrousel – de commencer à placer un listener pour récupérer en JavaScript la fin de l’animation CSS, c’est bien trop compliqué.

Je mets en gras les différences :

/* ouvert */
.animated-expandmore__to_expand {
display: block;
overflow: hidden;
opacity: 1;
max-height: 80em;
visibility: visible;
transition: visibility 0s ease, max-height 1s ease, opacity 1s ease;
transition-delay: 0s;
}
/* fermé */
[aria-hidden=true].animated-expandmore__to_expand {
display: block;
opacity: 0;
max-height: 0;
visibility: hidden;
transition-delay: 1s, 0s, 0s;
}

En fait, l’animation sur visibility se fera de suite… mais je place un délai sur la transition sur cette propriété dans un sens. Voilà comment il faut le comprendre :

  • Quand on va de fermé à ouvert, visibility passe instantanément à visible sans délai (on verra le contenu quand il va s’étendre) ;
  • Et quand on va d’ouvert à fermé, visibility passera de visible à hidden après l’animation, donc au bout d’une seconde.

Là, l’effet fonctionne bien, vous pouvez le voir sur la page de mon plugin hide-show system, je viens d’ajouter une rubrique Bonus: some animations?.

Voilà pour cette petite étude. N’hésitez pas à compléter/confirmer/infirmer, je suis preneur de retours avisés.

Séduction, communication et terrorisme (le 23/11/2015)

J’observe beaucoup en silence les réactions des gens suite aux événements de Paris. Grosso modo, je vois deux tendances en schématisant un peu.

  • le « on va réagir à ça »
  • et le « encore plus de tolérance »

J’eusse aimé que le « on va réagir à ça » se traduisât en « encore plus de tolérance », ce qui eût permis une synthèse rapide, efficace et – à mon humble avis – pleine de bon sens (et je n’aurais pas eu à taper ce billet).

Malheureusement, le « on va réagir à ça » est plutôt du genre :

« Fonçons tête baissée, si tu n’es pas d’accord avec moi, tu es un salaud de terroriste pas patriote avec ton hakik, je te pète la gueule, et tant pis au passage pour les amalgames ». (comme dirait mon dentiste)

En fait, à force de lire des billets sur le « encore plus de tolérance », je crois que j’ai compris un truc. Et afin d’être plus léger pour tenter de l’expliquer, prenons un sujet moins grave (et plus rigolo-gène) : la séduction.

Comme je l’indiquais dans le billet « Pitié sors avec moi », le vrai défi de la séduction est de convaincre la personne visée que vous êtes intéressant·e et qu’il/elle doit vous choisir !

Encore une fois, vous avez deux méthodes :

  • passer en mode vendeur, afficher le produit (= vous) autant que possible, matraquer (au figuré) la cible pour abaisser des défenses, etc.
  • ou rendre votre personne tellement intéressant·e que la décision de l’autre se fera toute seule à votre avantage (ou pas).

La première peut marcher – et même bien, certain·e·s sont très forts pour le faire. Elle semble aussi plus naturelle de prime abord : « c’est quand même à l’autre de comprendre que je suis bien pour elle/lui à la base » (qui ne l’a jamais entendu ?). La seconde est beaucoup plus incertaine, car vous n’imposez rien aux autres. Vous allez essayer de convaincre indirectement, mais c’est « la glorieuse incertitude du sport ». Et surtout, elle a le mérite de prendre en compte le libre-arbitre de l’autre. Cela a l’air idiot de le dire, mais c’est quand même important !

Connaissez-vous la chanson Man in the Mirror de Michael Jackson ?

I’m starting with the man in the mirror
I’m asking him to change his ways
And no message could have been any clearer
If you wanna make the world a better place
Take a look at yourself, and make the change

Traduction approximative :

Je commence avec la personne dans le miroir
Je lui demande de changer ses habitudes
Et aucun message n’aurait pu être plus clair :
Si tu veux faire du monde un endroit meilleur
Regarde-toi toi-même, et change.

C’est plutôt beau comme paroles, n’est-ce pas ?

Qu’y a-t-il en filigrane dans la séduction et dans cette chanson ? L’idée est surtout de partir du postulat que votre interlocuteur est suffisamment intelligent pour juger de votre qualité, et de travailler sur votre personne. Il y a bien aussi une (petite) notion d’humilité. :)

En fait, le « encore plus de tolérance » est dans la même veine. Si l’on pousse la réflexion plus loin, partir de l’idée que le monde est suffisamment intelligent pour comprendre cela, cela en dit long sur l’estime que vous lui portez, et c’est tout simplement « changer sa vision du monde ».

En clair, si je reprends les deux types de réactions :

  • j’impose ma vision au monde pour qu’il change.
  • je change ma vision du monde, j’accepte de me remettre en cause et d’être meilleur, et peut-être que le monde me le rendra.

Demandez-vous toujours, si une personne vous plait, si elle est plus dans le premier cas ou dans le second (car ce n’est pas binaire bien sûr). Notez que je parle de personnes, mais ça s’applique aux médias, aux politiques, etc.

De grands défis (le 16/11/2015)

J’avais prévu d’écrire un mot suite à une discussion animée, mais je tairais cette discussion, vu les évènements qui se sont passés à Paris ce dernier vendredi. L’idée reste étonnement la même, je vous livre ces pensées en vrac. Je suis stupéfait par un tel déchaînement de fureur meurtrière. Même si c’est le temps du deuil et ce temps est nécessaire, je ne peux m’empêcher de penser à l’avenir.

Il y a une loi en physique qui dit qu’une réaction implique une contre-réaction de force égale pour obtenir un équilibre. Je me dis qu’avec de tels événements immondes, nous allons devoir générer une contre-réaction proprement énorme.

Un premier défi va déjà d’être impeccables dans notre façon de parler. Les mots ont un sens et une portée, et même un petit détail peut avoir son importance.

Prenons un exemple rigolo, si je dis « les hommes sont des imbéciles », je mets tout le monde dans le même sac d’emblée. Changeons une lettre, si je dis « des hommes sont des imbéciles », même l’homme que je suis ne peut qu’acquiescer, il me suffit d’en trouver deux, et vu les évènements, j’ai bien peur qu’il en existe plus de deux.

Imaginons des propos à l’emporte pièce assénés comme des vérités. Là, c’est beaucoup moins drôle.

Ce qui m’amène à un second défi : il va falloir refuser la facilité. Même si cela fait « parfois du bien », vérifier le moindre truc que l’on va faire suivre sur les réseaux sociaux ou ailleurs. S’il n’existe qu’un seul contre-exemple à quelque chose que l’on veut asséner, autant se taire. Évitons les « hoax », les réactions à chaud non vérifiées.

Et voilà notre troisième défi : ne pas fonctionner à l’émotionnel. Certes l’émotion est ce qui fait de nous des humains, et moi le premier je ne peux cacher mon émotion devant ces personnes tuées, blessées ou meurtries. Seulement il y a un temps pour l’émotion et un temps pour la réflexion, et la réflexion devra aller plus loin que le bout de notre nez, le bout des frontières ou qu’une réaction de rage.

C’est notre quatrième défi : pousser la réflexion plus loin que des solutions simplistes. Les problèmes complexes n’ont pas de solutions simples. Le monde n’est pas manichéen. N’en déplaise à nos « gentils » politiques qui ont le sens de la phrase rapide, il va falloir aller beaucoup plus loin que cela. Et pas que les politiques d’ailleurs. Il va falloir prendre beaucoup de hauteur. Et pour longtemps.

Voila notre cinquième défi : faire durer tout cela. Je veux croire que le simple savoir-être peut changer le monde. Regardons nos politiques : ils sont à notre image. Raisonnons en idiots, et ils nous donneront de l’idiotie en nous traitant comme tels. Punchons-les avec de la finesse et de l’intelligence, et ils seront obligés de s’y mettre. Même si pour certains, cela semblera nouveau.

La seule chose qui permet au mal de triompher, c’est l’inaction des hommes de bien.

Les personnes de bien ne vont pas manquer de boulot.

Et notre dernier défi va être de taille, si je reprends l’idée du début, il va falloir comprendre que la contre-réaction devra non pas être de la haine, mais de l’amour, de la compassion et de l’empathie. Et beaucoup d’humour pour faire passer tout cela.

Donner un verre d’eau en échange d’un verre d’eau n’est rien, la vraie grandeur consiste à rendre le bien pour le mal. Gandhi

Nous allons tous avoir des choix à prendre en toute conscience. Politiques, citoyens, personnes, gens, tous.

Généraliser abusivement ou être impeccable. Choisir ou refuser la facilité. Laissez nos hormones nous gouverner ou les remettre à leur bonne place. Être simpliste ou aller plus loin. Faire cela trois jours ou le faire pour de bon. Choisir la haine ou l’empathie.

Le choix a ceci de beau qu’il est incroyablement simple. Il n’est pas nécessairement facile, mais il est simple.

Retour d’expérience sur ma conf sur CSP à Paris Web 2015 (le 27/10/2015)

À l’instar de Marie qui explique comment elle a préparé sa conférence à Paris Web, je vais vous expliquer l’envers du décor pour une intervention de 15 minutes sur CSP.

TLDR : comment faire rentrer un an et demi en 15 minutes.

Les débuts sur CSP

J’ai découvert CSP il y a un peu plus d’un an et demi, grâce au service Dareboost, qui teste la qualité des sites. J’avoue que sur le coup, je n’avais jamais entendu parler de ce truc : CSP, kézako ?

En lisant quelques documentations, je comprends l’idée principale : dire ce que l’on autorise à s’exécuter sur le front-end, sachant que tout ce qui ne sera pas autorisé sera bloqué (pour éviter des failles XSS, des contenus indésirables, etc.).

Je me dis, c’est simple, je vais tester cela vite fait, c’est l’affaire de 10 minutes. Effectivement, j’avais lu que déployer CSP prenait 5 à 10 minutes sur un post sur CSP sur Github. Par contre, ce que je n’avais pas lu, c’est que souvent, c’était que le vrai challenge était de faire fonctionner son site avec.

Plein d’entrain – j’étais en fin de journée au boulot – je me décide à tester cela sur un petit site en me disant que cela serait assez facile : mon code front est plutôt clean, ça ne devrait pas être bien dur. Hé oh, quand même, j’ai été élevé au grain Opquast et à l’orthogonalité moi !

Grossière erreur : CSP m’a montré que j’avais oublié plein de petites bricoles. Pas bien graves, mais CSP ne faisant pas dans la demi-mesure, je m’y suis cassé le dentier. Vous vous doutiez bien que je n’avais pas inventé la mise en garde que j’ai faite durant l’intervention : si je dis que c’est idiot de déployer CSP sur un site en production sans tester, c’est que j’ai été le premier à faire cette connerie !

Bref, rétro-pédalage complet, j’enlève l’en-tête HTTP CSP sur ce site. Le moins qu’on puisse dire, c’est que le premier contact avec CSP fut rude.

L’envie d’y arriver quand même

La plus grande vérité du code étant la suivante :

If all else don’t work
{
Read the manual
}

Et m’étant cassé les dents, j’ai donc lu la doc. Je me suis dit qu’il faudrait que je teste cela sur un site relativement simple et que je maîtrise totalement, en l’occurrence ce sera sur Röcssti. Je mets en place de bon matin un CSP en mode report only avec un bête envoi de mail. Le soir, au calme, j’ai reçu quelques notifications. Rien de bien méchant :

  • un attribut onerror pour le fallback PNG du logo en SVG. Déporté sur une fonction externe.
  • Les event trackers de Google Analytics étaient sur des onclick, idem, déportés sur une fonction externe.
  • Le code inline de Google Analytics fut aussi envoyé dans mon fichier JS qui contient tout.
  • Etc.

Bref, en une petite heure à peine, les soucis étaient réglés, et en prime, j’ai pu industrialiser certains comportements et j’ai enfin trouvé un compagnon pour vérifier certaines bonnes pratiques d’orthogonalité. Finalement, je suis gagnant sur plusieurs tableaux.

Le second contact est bien plus agréable !

Un long travail de fond

Plutôt content, je me dis que je vais essayer de le mettre en place sur certains sites en cours de développement au travail. J’ai fait des essais en douce sur une petite dizaine de sites. Et petit à petit, je corrigeais les petits défauts. Bien entendu, les derniers sites bénéficieraient de ce travail de fond.

Mes plugins accessibles auront aussi droit à leurs directives CSP bien strictes, afin de me servir de garde-fou au cas où j’aurais un instant de faiblesse.

Même si ces essais ne passent pas toujours en production, les améliorations vont bon train. Je me dis que CSP gagnerait à être plus connu. À peu près toutes les personnes à qui j’en parle me regardent avec des billes à la place des yeux, et j’entends toujours la même remarque : inconnu au bataillon.

Le sujet va plus loin

J’ai pu déployer CSP très tôt durant une refonte de site, et durant l’inventaire des contenus (repris d’une ancienne version), CSP va révéler un potentiel auquel je n’avais pas pensé. Ayant interdit les styles en ligne et plusieurs personnes s’occupant de faire l’inventaire des contenus, ils vont sans le savoir me faire remonter les adresses des pages où un nettoyage des anciens contenus s’impose. Bénéfice supplémentaire : ces vieux styles en ligne ne seront pas chargés, ne détruisant pas les efforts de mise en page sur la nouvelle version. Non seulement, les infos remontent toutes seules, mais en plus les vieux cancrelats ne viennent pas salir la nouvelle version. C’est-y-pas beau ?

Entre temps, j’ai commencé à avoir quelques notifications bizarres, voir incompréhensibles. Il m’a fallu un certain temps pour comprendre que les premiers messages étaient des erreurs d’extensions sous Chrome, n’utilisant que très peu ce navigateur. Ayant du mal à reproduire ces erreurs, je me suis mis en tête un soir de faire un proof of concept, une bête page avec CSP activé qui serait identifiée de manière unique, dont les notifications seraient envoyées dans une base, et qui ferait un bête appel AJAX pour ressortir les notifications CSP qu’elle aurait déclenchées (et aussi pour soulager ma messagerie de ces notifications).

Je crée le système à l’arrache la plus complète mais le tout marche. J’essaie de tester, curieusement, je n’arrive pas à reproduire le bug sous Chrome… là je me dis, super j’ai fait tout cela durant une soirée pour rien.

Mais j’en trouve un sous Firefox le lendemain ! Assez pénible ce bug d’ailleurs, je reçois des tonnes de notifications CSP dès que j’utilise l’inspecteur de code sur un site où CSP interdit strictement les styles en ligne.

Des bugs sous les navigateurs

J’en fais part à Julien Wajsberg – qui travaille chez Mozilla – histoire d’avoir son avis. Le bug est reproductible, je le reporte : Bug 1195302 sur CSP.

L’expérience qui suit me fut plutôt agréable : rapidement, des gens de chez Mozilla font le lien avec d’autres bugs, les discussions vont bon train, et un patch est proposé sur des nightly. À la fin, on m’annonce que le bug sera fixé sur Firefox 43. Mais une personne indique mon bug et demande s’il ne serait pas possible d’accélérer la manœuvre (uplift), car « un développeur est impacté par ce bug ». Autant le dire de suite : ce genre d’attention est très agréable et très apprécié.

Finalement, le patch sera appliqué sur Firefox 42, qui ne devrait pas tarder à sortir au moment où j’écris ce billet.

Entre temps, j’arrive de nouveau à reproduire des bugs sur Chrome et Safari, à force de collecter des données. Même démarche, sur Blink/Chrome, le problème sera pris en charge. Entre temps, des devs de chez Chrome m’inviteront à poster aussi chez Safari.

J’avais reporté un autre soupçon de bug chez Firefox sur un autre sujet (flexbox), mais il s’avérera que c’est bien Firefox qui suit la spec. Du coup, les mozilliens ouvriront un bug sur Chrome.

Bref, si vous croyiez que les développeurs de navigateurs ne travaillent pas de concert, ce n’est pas du tout l’expérience que j’en ai eue. Le légendaire supposé manque d’amabilité des développeurs en a pris aussi un coup.

Proposer un sujet sur CSP ?

Finalement, arrive le moment où je me dis que cela pourrait faire l’objet d’une conférence. Cela tombe au moment de l’appel aux sujets pour la Kiwiparty. Je le propose… et c’est un refus.

Entre temps, je décide de proposer des articles sur le sujet, qui eux par contre sont acceptés. Malheureusement, j’ai pris beaucoup de retard, mais croyez-moi sur parole, ces articles sortiront ! :)

Puis arrive l’appel à orateurs de Paris Web 2015. Je propose un sujet sur CSP sans trop y croire et un sur les plugins accessibles que je développe depuis un certain temps. Le sujet sur CSP sera retenu, pour ma plus grande joie. Le seul souci : comment faire rentrer dans un sujet de 15 minutes tout ce que j’ai en tête et tout ce qu’il y a à dire sur le sujet ?

Cela me paraît impossible.

Proposer « une expérience multi-canaux »

Comme je vais au travail en voiture, j’ai du temps inutile à rentabiliser. Du coup, j’improvise et je répète mes conférences durant les trajets. Certes j’ai l’air d’être un peu dingue à parler tout seul, mais du coup, les trajets passent bien plus vite et sont beaucoup plus utiles !

Les premiers essais que je fais atteignent les 30 minutes. Bref, c’est la catastrophe sur le timing, même si cela m’aide beaucoup à sortir un plan et voir l’essentiel.

D’un autre côté, j’ai aussi un autre souci : de quel niveau sera le public ? Souvent à Paris Web, le niveau du public est assez élevé… et plein de gens me disent qu’ils n’ont jamais entendu parler de CSP. Diantre, que choisir ?

J’ai bien pensé à faire un sondage, mais je suis plutôt réfractaire à cette approche. Bref, je me creuse la tête, et finalement, je vais appliquer mes propres propos : je suis le premier à dire qu’il ne faut pas larguer les débutants, et vu que bon nombre de gens semblent ne pas connaître, je m’en tiendrai à la base, et à quelque chose d’utilisable dans le monde réel. Exit CSP Level 2 qui n’est pas encore implémenté partout, exit les trucs trop compliqués.

Comme je trouve aussi dommage que les idées n’aillent pas plus loin que des conférences (sujets refusés ou acceptés d’ailleurs), je me dis qu’il y a peut-être la solution à mon problème : proposer « une expérience multi-canaux ».

La conférence sera destinée à expliquer les grands principes (merci Élie Sloim de m’avoir non sans peine appris à me centrer sur le principal), les avantages et montrer un exemple. Les prochains articles approfondiront, et mon dépôt Github sur CSP aura des exemples pratiques, des astuces, des ressources, etc.

La conférence proprement dite

Bref, après avoir énormément élagué mon plan, et hormis le fait que je fus stressé, la conférence ne se passa pas trop mal, j’ai juste débordé d’une grosse minute sur le timing, et bêtement oublié de mentionner que CSP sera probablement dans Opquast v3 (ayant fait des pieds et des mains pour que ce soit le cas).

Pour l’occasion, et afin de montrer le premier côté un peu aride de CSP, j’avais fait un t-shirt pour l’occasion, juste pour le plaisir de détourner le « Keep calm and… ».

Utilisez CSP, mais restez calme

Les retours furent plutôt bons, apparemment le message est bien passé : c’est une techno interessante, les bugs sont surtout de l’ordre du confort et il n’appartient qu’à nous de les faire remonter pour que cela devienne top à utiliser. De nombreuses personnes m’ont posé des questions, et mes slides sur CSP ont été beaucoup consultées et partagées sur Twitter. J’ai même eu droit à des compliments de personnes plutôt calées en sécurité. :)

Quelques tweets juste après la conférence

Certes, j’aurais apprécié d’avoir plus de temps pour montrer toutes les possibilités de CSP (notamment la vérification d’intégrité des scripts, c’est énormissime), mais ce format court m’a forcé à être un peu « créatif » pour faire rentrer un an et demi d’essais en 15 minutes.

Aller encore plus loin ?

Gag : en discutant avec quelqu’un sur place à propos des bugs sur tous les navigateurs, il me dit : « t’en aurais pas trouvé un sur Edge des fois ? ». J’utilise ma petite page qui a servi à trouver les autres bugs… et elle me sort un bug bien énorme sur Edge. Du coup, ce fut remonté chez David Rousset, un gars super bien de chez Microsoft.

J’aimerais pousser le dépôt Github plus loin en mettant des exemples de code ainsi que d’autres ressources.

En testant d’autres choses et en discutant, je me suis aperçu que certains bookmarklets sont aussi affectés par les directives CSP d’un site. Bug reporté, je fais encore des essais pour les autres navigateurs. La réponse est éloquente :

Recently we got more complaints, which means that more pages are adopting CSP apparently:

Anyway, when we do our next triage I will make sure that we re-prioritize that issue and put some more resources on fixing it. Thanks for filing the bug.

En clair : beaucoup d’infos remontées, la priorité du bug va être augmentée. Si vous hésitez à remonter des bugs en vous disant que cela a déjà été fait, n’hésitez plus, faites-le. En plus, je trouve que cela crée un lien avec les navigateurs, même si c’est très modeste, j’ai l’impression d’avoir contribué à ces derniers.

En conclusion

Je crois beaucoup en CSP, comme je ne cesse de le répéter, cela gagne à être connu. D’autres conférences ont refusé le sujet, mais qu’à cela ne tienne, j’aimerais continuer à démocratiser les possibilités de cette techno. Plus elle sera utilisée, mieux elle sera implémentée.

Ne vous arrêtez pas à un premier contact qui peut être rude, cela vaut vraiment le coup. J’ai pu faire énormément de progrès grâce à cette techno. Je trouve que c’est en quelque sorte l’hygiène du front-end. Utiliser CSP force à savoir exactement ce qu’il se passe sur le front-end, et invite à diminuer l’empreinte de nos sites.

Et accessoirement, un peu de sécurité ne fait pas de mal.

Voici donc la petite histoire, ou « Comment faire rentrer un an et demi en 15 minutes ».

Pour moi, internet reste un mystère… (le 25/10/2015)

Une fois n’est pas coutume, je laisse la place à quelqu’un d’autre, ma douce et tendre, manifestement inspirée par Paris Web.

Au début, même Google est une planète extraterrestre, et Wikipédia le nom d’un zoo. Faire une recherche par mot clé reste encore compliqué et j’ai souvent besoin de mon mari, car sinon je reste au point mort.

Bref, quand mon mari a commencé son boulot de développeur web, autant dire qu’il passe du côté obscur.

Moi, je suis infirmière en chirurgie, du concret avec des gens vivants et des problèmes concrets avec des protocoles connus et des manières de travailler codifiées.
Du code mon mari en fait, mais dans des langages que même Maître Yoda ne connais pas. HTML, JavaScript, CSS et des domaines divers et variés que personne ne sait à quoi cela correspond. Web design, qualité, sécurité, graphisme, intégrateur front, back, chef de projet, accessibilité, responsive…

Vous surfez tranquille sur internet sans vous douter que tout cela ce cache derrière ce que vous regardez…

Il est quoi ?

Maintenant, moi ce que j’adore répondre quand on me demande ce que fait mon époux, c’est « développeur guichet »… Et là, les yeux s’agrandissent, et la bouche reste ouverte…
« Développeur web ? » Pas mieux.
« Il crée et gère des sites internet ». Là, c’est déjà mieux, mais pas encore très clair. Bien souvent dans les démarches administratives il n’y a même pas de case correspondante.

« Il travaille dans l’informatique ? J’ai un problème avec mon ordi… »

Non, il n’est pas technicien réparateur, mais développeur… L’informatique, mot générique qui regroupe tout et n’importe quoi pour le commun des mortels. Mais non, ces professionnels du web ne sont pas des touche-à-tout sur le matériel. Cet impasse linguistique contribue à l’incompréhension de ces métiers.

Une perturbation dans la force

Mais bon, un peu plus sérieusement, après des années de vie commune, je deviens très critique quand je surfe tranquille.

Rien ne s’affiche comme cela devrait, impossible de surfer correctement selon le support. C’est quoi ce menu de m… qui ne défile pas correctement ou pourquoi quand je change de colonne le menu disparaît. En plus, comme mon chéri fait des conférences, j’écoute de manière distraite mais je trouve encore le moyen de donner des conseils alors que sur le fond… je n’y comprends rien. CSP, c’est pas des Cadres Sociaux Professionels ?

Pour finir, je porte des vêtements qui à mon boulot ne veulent rien dire, mais dans l’univers de mon amour tout est plus clair. Je porte un t-shirt avec un singe, non c’est un logo de mail, ton t-shirt ne veut rien dire, trop sympa le jeu de mot en code… Sympa tes lunettes, mais les couleurs sont spéciales… ah le « W » c’est WordPress ?

Comme quoi même l’univers du code a ses propres codes.

Rejoins-moi du côté obscur

Bref, j’ai mis un pied moi aussi du côté obscur. Sans vraiment en avoir conscience mais en plus sans vraiment être consentante. Mais à l’insu de mon plein gré quand même. C’est bien moi qui ai posé des questions et cherché à comprendre le métier de mon mari.

Oui, ce n’est pas physique, mais la pression de la mise en ligne, des exigences peu précises ou trop du client, les contraintes de la présentation du site ou des impératifs du langage utilisé et vous obtenez une boule de stress, de pression et de défauts de communication aboutissant à des situations problématiques. Cela, personne ne le comprend pour eux. Combien de fois ma famille m’a sorti :

« mais c’est pas fatigant, il est sur un ordi toute la journée ».

Un geek pour moi, c’était le cliché classique, un mec maigre pâle solitaire accro aux écrans, ne sachant parler que de trucs hyper compliqués. Mais dans la réalité, il n’en est rien, tout ce petit monde de passionnés et compétents chacun dans leurs domaines respectifs est avide de partager et de compléter leurs connaissances et leur savoir-faire. Parfois à un point difficile à imaginer, cela fait partie de leur ADN. Et ils sont chiants, car s’ils n’apprennent pas, ils deviennent comme des lions en cage.

Ô miracle, la plupart ont une vie sociale, de famille… Bref, le cliché tombe, comme celui de l’infirmière nue sous sa blouse. Oui, vous n’êtes pas les seuls à avoir des clichés sur votre profession.

Encore plus hallucinant, il est branché qualité web, et on est capable de discuter qualité… de soins. J’ai du mal à le croire quand je lui parle de la qualité des soins à domicile que je veux atteindre, et qu’il me répond : j’ai l’impression que tu me décris mon métier. Et le pire, c’est qu’il met des mots sur les questions que je mets sur la qualité des soins.

Mais on est de quel côté en fait ?

Tout cela pour dire qu’il est parfois difficile de comprendre les méandres de ces métiers du web et de l’engagement que cela demande pour rester à niveau dans un milieu où tout évolue rapidement et où la formation se développe tout doucement.

Il est important, je pense, de conserver ce mouvement d’émulation et de partage. Tout cela reste subjectif puisque je suis extérieure à ce petit monde, mais c’est ce que je ressens. L’union fait la force.

Même si, du mon point de vue d’épouse, ce temps-là nous est un peu volé. Bref, même quand on comprend, on n’est pas toujours d’accord malgré tout. Sans blague.

C’est le gluten des sulfites de nos sites (le 14/10/2015)

L’autre jour, je discutais avec une connaissance en mangeant un bon morceau. Je fus surpris de son choix culinaire : ce dernier m’indiquant qu’il avait une intolérance au gluten, intolérance que je ne lui connaissais pas.

« C’est le gluten, cela me pompe littéralement mon énergie, c’est pour cela que je n’en mange plus » m’explique-t-il.

N’y connaissant rien en allergies alimentaires – dont je suis heureusement épargné – je le crus sur parole. À la fin du repas, il s’autorisa un petit dessert gourmandise – avec gluten donc – et, juste après l’avoir mangé, me fit : « tu vois, j’en ai mangé un tout petit peu, et je sens que je fatigue déjà ! »

En bon scientifique terre à terre, j’aurais également retenu l’hypothèse le gluten n’est pas nécessairement la cause de sa fatigue (même si ses effets peuvent être importants sur les personnes y étant sensibles), mais peut-être que la quantité proprement monstrueuse de nourriture qu’il avait ingurgité serait aussi une cause possible de sa fatigue, la digestion de tels repas prenant effectivement beaucoup d’énergie. Soit.

Autre cas de figure, lors d’un repas de famille, je discute avec un oncle éloigné grand amateur/consommateur de vins divers et variés. En dégustant un verre d’un Alsace blanc, je fus surpris de le voir refuser cet excellent vin. « Dans les vins blanc, il y a des sulfites, et c’est mauvais pour le cœur. Tu sais, avec mes problèmes cardiaques… ». Du coup, il ne but que du vin rouge.

Encore une fois, mon ignorance en chimie du vin me le fit croire sur parole. Je le revis quelques mois plus tard, et il m’expliqua qu’il ne buvait plus de vin rouge non plus, car il y avait je-ne-sais-plus-quoi qui n’était pas bon pour lui. Du coup, il ne buvait plus que du whisky.

Encore une fois, en bon scientifique terre à terre, j’aurais retenu l’hypothèse que le problème n’est pas un composant des vins/liqueurs (même si les sulfites ont bien des contre-indications pour les personnes y étant sensibles), mais plutôt sa consommation assez « élevée » et régulière d’alcool, tout simplement. Soit.

Où veux-je en venir ? À une analogie avec nos sites.

Nous pouvons avoir la meilleure stratégie de chargement/mise en cache pour avoir de bonnes performances – ce qui est très bien, je ne le remets pas en cause – ce qui donne aussi une bonne sensation de rapidité.

Nous pouvons aussi avoir les meilleures modales les plus accessibles qui soient – je suis bien placé pour le savoir, j’en ai programmé une – ce qui permet aux utilisateurs de pouvoir les utiliser sans souci.

Nous pouvons avoir les meilleurs serveurs qui montent en charge, parfois avec du load-balancing (répartition de charge) pour encaisser des charges toujours plus importantes.

Etc.

Ce n’est pas parce que nous pouvons avoir tout cela que nous devrons nous dispenser d’être plus économes de ressources et/ou de fonctions.

Les systèmes de load-balancing, c’est bien et c’est utile. Toutefois, il faudrait peut-être se poser la question de la pertinence d’un système qui ne fait que cacher le côté ogre d’un CMS ou d’un site qui bouffe trop de ressources.

Une modale accessible c’est très bien. Se passer de l’utiliser pour afficher une publicité non sollicitée, c’est mieux.

Mettre en place des chargements différés c’est bien (je le fais aussi). Ceci dit, pour moi, ce n’est que décaler une partie du problème. À l’instar des sulfites évoquées plus haut, le vrai problème est le poids des pages. Charger tout simplement moins de contenus ne serait pas un mal.

Cela n’empêche pas de continuer à optimiser/améliorer nos sites, mais je pense – j’espère – qu’à un moment, la question de l’eco-conception et de l’empreinte minimale sera une bonne fois pour toutes mise sur la table, tout comme celle de la conception universelle via l’accessibilité. L’obésité des sites n’a que trop duré, tout comme leur non-universalité.

Et si nous mettions en place un plan et des indices de développement durable ?

Une novice dans l’immensité du petit monde du web (le 12/10/2015)

Une fois n’est pas coutume, je laisse la place à quelqu’un d’autre, qui vous avait déjà parlé du petit univers du Web, et qui m’a accompagné au dernier Paris Web (ma douce et tendre).

Le plus comique est de croire que le petit monde du web n’a pas de code.

Je pensais que les codes vestimentaires étaient inexistants, la décontraction de rigueur. Bref le geek solitaire et qui se moque des us et coutumes du commun des mortels dans la relation sociale. Mais il n’en est rien. Il y a bien les t-shirts de geek, mais avec bien souvent des messages que seul les initiés peuvent comprendre, et toutes les excentricités ne sont pas forcément de mise.

Attention, le tutoiement est obligatoire pour maintenir une bonne communication. Et il faut parler de tout en toute décontraction mais pas trop pour rester accessible. Bref, tout est aussi codé que dans toute relation de travail. Et tout est plutôt obscur pour la novice que je suis.

De plus je pensais que le geek est un peu excentrique, original, voir antisocial, mais il n’en est rien.

Le petit monde du web a besoin de rencontres, d’espaces de dialogue et d’échanges, et de communication pour continuer de faire vivre un savoir-faire qui n’existait pas il y a 20 ans, et le faire évoluer. Voilà ce que j’ai compris au contact de toutes ces personnes formidables, qui font partie du petit monde du web.

Mais, je suis surprise d’apprendre que tout cela est menacé. Comme dans tout métier il y a des évolutions, et l’émulation par l’échange est moins au centre de ce petit monde qu’avant. Qu’il y a des gens qui pensent n’avoir besoin de personne.

Même pour une novice comme moi, je trouve très dommageable la disparition de cet esprit convivial et bon enfant qu’est le petit monde du web. Parti d’un monde d’artisans qui se sont tous entre-aidés. Un petit cri d’une novice dans l’immensité du petit monde du web.

Ne perdez pas de vue d’où vient le net et quel est son but premier.

Soutenez des initiatives comme Paris web, Sud Web, Kiwi Party… Les personnes sont bénévoles pour organiser des événements de pure technique, et même s’il faut payer pour assister, le bénéfice est énorme. Même pour une novice comme moi, qui rencontre des gens formidables et passionnants et… passionnés.

Paris Web 2015, ce feu intérieur (le 09/10/2015)

Comment qualifier cet événement ? Grosso modo on vous colle au milieu de gens passionnés et passionnants, et tout le monde est là pour discuter, échanger, partager… jusqu’à plus soif. Ce qui n’est pas un problème, car on peut toujours boire un verre pour repartir de plus belle. Et vous vous sentez moins seul dans vos galères du quotidien.

Une fois n’est pas coutume, je vous livre ici quelques pensées personnelles d’abord, et je détaillerai les conférences et les ateliers dans de prochains billets.

Paris Web 2015, j’y étais

L’effet Paris Web

Je commence à « connaitre » un peu l’ambiance, car c’est ma cinquième édition de Paris Web, j’ai commencé à mi-chemin en somme, vu que c’était la dixième édition cette année.

Le choix (li-)cornélien des conférences

Mon approche a évolué par contre. Si aux premiers Paris Web que j’ai faits, je fonçais surtout sur mes sujets de prédilection, j’ai tendance à préférer maintenant ce que je ne connais pas, ou moins. Bon, je ne crache pas sur un atelier sur l’amélioration progressive non plus, faut pas déconner !

Si j’étais un peu critique sur le format des informelles la première année qu’elles ont eu lieu (je n’en voyais pas l’intérêt), j’ai bien changé d’avis sur le sujet… vu que j’en ai proposé une en duo (j’y reviendrai), et que j’aime bien ces off.

J’ai l’impression que dans ces échanges plus feutrés se cachent beaucoup de grands sujets.

Des choses qui me plaisent…

Les ateliers m’ont fait entendre des choses très sympas.

Certaines personnes ont pris du recul (et pas que des vieux croûtons), j’ai entendu plusieurs fois des réactions du genre « c’est chouette ces technos, mais c’est pas adapté à ma situation » ou « on a choisi cela parce que cela convenait à notre cas et pas parce que c’est un truc tendance ». Cela me fait vraiment plaisir d’entendre cela.

Comme Montaigne, je préfère « une tête bien faite » plutôt que « bien pleine ». Et là, j’ai vu des têtes pensantes. Cela me plait énormément.

… et d’autres qui me font peur

Bien malgré elle, une participante nous a demandé : « mais c’est quoi cette explosion de bulle internet dont vous parlez ? ». Ce qui me fait peur, ce n’est pas que des gens ne connaissent pas l’histoire du Web, mais surtout qu’ils soient tentés de faire les mêmes bêtises parce qu’on ne leur aurait pas apprise.

D’ailleurs, j’en ai entendu des bêtises qui ont déjà été faites (avoir un seul navigateur, etc.). N’oubliez pas que l’Universalité du Web n’est pas une faiblesse, mais une force.

Le syndrome de l’imposteur

Je ne reviendrai que brièvement sur ce sujet. Ok, on l’a tous – moi le premier – et il nous bloque parfois.

J’ai pu discuter avec un excellent développeur, un puits de science (SVG, typographie, intégration, JavaScript, CSS, etc. la liste est trop longue). Ce qu’il m’a révélé m’a surpris : lui aussi avait été paralysé par ce syndrome avant. Je n’en revenais pas. Lui, ce monument, cette ceinture noire 8e dan du web. Comment peut-il avoir ce syndrome, vu qu’il est tout sauf un imposteur !

La seule différence que je vois entre ceux qui se lancent et ceux qui n’osent pas, c’est juste qu’ils mettent cette voix de côté – sans la faire disparaitre – et essaient quand même.

Apprenez à écouter cette voix, mais ne la laissez plus vous torpiller. Vous êtes légitime tant que vous êtes humble et motivé.

Un petit calcul

Définitivement, le Web francophone a des choses à dire et n’a pas à rougir de ses connaissances. Au bas mot, je suis sûr qu’un paquet de participants à Paris Web pourraient écrire des articles sans souci, même s’ils en doutent fortement.

D’ailleurs, l’Openwebien qui sommeille (peu) en moi vous propose un calcul. Chaque année, Paris Web reçoit des centaines de sujets et de propositions. Imaginons qu’on en recycle un peu, mettons une petite centaine, sur des sites communautaires comme Openweb, Alsacréations, etc. Nous aurions deux articles à lire par semaine et la vie de ces sites serait largement assurée. Quand on voit que de nombreux sites communautaires ferment ou peinent à être alimentés, ça fait réfléchir.

Et je n’ose imaginer si chacun publiait sur son blog… les réseaux sociaux seraient remis à leur juste place : non plus des contenus mais de simples caisses de résonance pour de vrais contenus. À méditer.

À propos d’Openweb

De nombreux membres étaient présents. Dans le panthéon de mes héros du web, ils ont tous une place bien particulière.

J’espère bien en voir émerger de nouveaux, certain(e)s ont un potentiel monstre. Que ce soit sur Openweb ou ailleurs, d’ailleurs.

Des rencontres, de fugaces instants de grâce

J’ai été ravi d’apprendre à mieux connaitre des personnes, même si ce ne fut que trop bref. Thanh, Marie, Enza, Carine, Morgane, Sylvain, etc. vous êtes si nombreux que je ne pourrai tous vous citer.

Étonnamment, l’ambiance est telle qu’on en arrive à se confier ou à parler de choses très personnelles très facilement. De belles tranches de vie comme dirait l’autre. Les armures et les masques qui tombent.

J’ai coutume de dire que Paris Web est ma cure de thalasso et que cela devrait être remboursé par la sécurité sociale, cette année, j’ajouterai que ça a un effet libérateur que même le meilleur des psys ne pourrait pas donner ! :-D

Deviens-je un vieux croûton ?

Pour ma part, j’ai encore énormément appris lors de cette édition. Donc, pas pour cette fois, merci ! J’en ressors même encore plus motivé pour continuer mes projets et participer à d’autres.

Quelques maître-mots que je retiens

Congruence : être en accord avec ses idées. Enfin, on parle d’être au naturel, en accord avec ses convictions, et… sans artifices.

Empathie : l’ami Élie le disait justement : l’histoire de Paris Web n’est pas un lieu de Bisounours, mais bien la Mecque de l’empathie, cette qualité qui nous rend meilleurs.

Se lancer : suivre des conférences, écrire, etc., cela va vous donner des sensations. Il y aura un avant et un après, vous aurez l’impression de monter en puissance beaucoup plus vite (impression que plusieurs personnes sur place m’ont confirmée). Vous allez avoir l’impression de vous (r)éveiller.

Bref, (r)éveillez-vous, et engagez-vous.

Appelez cela comme vous le voulez (la pêche, l’effet Paris Web, etc.), mais des événements comme Paris Web vont vous allumer un feu intérieur. Ne le laissez pas s’éteindre, laissez-le vous porter. Et même, cultivez-le toute l’année.

Je n’ai jamais ressenti aussi fort qu’à cette 10e édition de Paris Web que nous étions maîtres de nos destins et acteurs du Web, pas de simples spectacteurs. Le futur, c’est ce que l’on en fera. Je refuse catégoriquement le pessimisme ambiant ou le laisser-aller : nous sommes des êtres éclairés, agissons donc en tant que tels.

Ce feu intérieur va vous porter plus loin que vous l’imaginez, vous nourrir et même vous aider à vous débarrasser du dispensable. Rien que pour cela, je m’incline devant le staff : vous avez contribué à changer ma vie avec ces événements, et j’espère que cette dixième édition, fût-elle très réussie, ne sera pas la dernière.

Pour une raison très simple : j’ai encore bien trop à apprendre.

Continuer une « refonte » du site de l’agence (le 18/09/2015)

Fin 2013, j’écrivais un billet sur la refonte du site de mon agence, une histoire de CSS responsive en mobile-first.

Allez savoir pourquoi, je n’avais pas pu y revenir !

J’exprimais quelques regrets sur la CSS, notamment des problèmes de factorisation. Un peu plus d’un an après, j’ai eu un (tout petit) peu de temps, et il y a quelques changements pas inintéressants à partager avec vous.

Prezenz

Sass, un an après

Le plus dur a été de faire redémarrer Sass un an après, c’est dire si c’était difficile après… quelques minutes. J’avais utilisé Sass pour industrialiser certaines tâches, notamment la gestion des très nombreuses icônes dans leurs divers formats, impossible à faire à la main.

Du coup, j’ai repris ces classes et j’ai fait exactement ce que j’aurais dû faire à l’époque, utiliser des classes icon-service-48-<ici_le_service>, qui me permettront de cibler tous les éléments correspondants via un simple [class*=icon-service-48-].

Certes, l’économie semble mineure. Toutefois, sur une longue liste d’icônes (avec des surcharges en prime), l’économie a été plus que substantielle, cela s’est compté en dizaines de kilo-octets. Pas négligeable et bien plus propre en prime !

Les micro-datas changent

Bon, disons-le clairement, ça aurait pu me passer sous le nez. Le schéma a légèrement changé, rendant invalides certaines des micro-datas que j’avais semées ici et là.

Notamment, la relation makesOffer ne peut plus offrir de itemtype="http://schema.org/Product" mais bien un itemtype="http://schema.org/Offer". Ce qui peut sembler logique, mais à l’époque, on pouvait offrir des produits, maintenant on ne peut plus offrir que des offres ! (exemple avec les Rich Snippet Tools)

Autre curiosité, si vous précisez un logo pour une corporation, il faut préciser un itemprop="url" sinon le validateur va gueuler en vous disant que c’est obligatoire !

Rien de bien gênant, quelques tests et quelques corrections règleront cela rapidement.

SVG, mon amour

J’avoue ne pas avoir été très longtemps fan du doublement de résolution pour des images pour les écrans retina. In fine, c’est plutôt lourd à gérer et ça m’a amené plus de problèmes qu’autre chose pour les icônes (les graphistes ne sont jamais contents du rendu en prime).

Comme ces dernières venaient d’Illustrator : passage immédiat en SVG !

J’ai installé en prime un Modernizr (il n’y en avait pas). Au lieu de mettre à disposition les images en PNG et de surcharger avec celles en SVG (ce que j’aurais fait à l’époque), j’ai pris le parti inverse (on est en 2015, mer… !) : d’abord le SVG et une solution de repli en PNG via le no-svg ajouté par Modernizr.

Surprise : les images des sprites en SVG semblaient plus lourdes que leurs équivalents en PNG. Mais avec la compression GZIP activée (hé oui !), elles furent quand même bien moins lourdes (presque deux fois plus légères pour certains sprites).

Des ajouts qualitatifs

Quelques rapides tests sur Dareboost me rappelleront d’ajouter quelques éléments que je ne connaissais pas à cette période : Header set X-Frame-Options "DENY", Header set X-XSS-Protection "1; mode=block", Header always set X-Content-Type-Options "nosniff" pour des aspects de sécurité (à retrouver dans mon fichier htaccess de référence).

Quelques bêtes oublis comme <meta property="og:type" content="website" /> seront corrigés.

Au passage, l’ajout des webfonts au format WOFF2 permettra encore d’alléger un peu le site.

En conclusion

Ce n’est pas parfait, c’est toujours améliorable… mais c’est toujours mieux que ce que c’était. Rendez-vous à la prochaine salve d’améliorations.

Plug-ins de réseaux sociaux à la noix et performances (le 04/09/2015)

Après cette courte pause estivale pour ce blog, c’est reparti pour une rentrée. Et je ne résiste pas au plaisir de partager quelques chiffres qui m’ont bien choqué.

J’ai récemment mis en ligne un site de concours photo pour les HUG. Outre le fait que c’est mon premier site en .photo, j’ai eu le temps de faire quelques tests vite faits au moment de la mise en ligne, cette dernière s’étant très bien passée. Précisons que je n’étais pas dans une quête de performance absolue, plus de simple curiosité.

Une Waterfall

Cela fait plusieurs conférences et autres articles que je vois qui indiquent de bien différer le chargement et l’exécution des scripts non critiques. Je me disais que ça ne pouvait pas être si terrible que cela sur le site dont je vous parle. Il n’y a qu’un script de partage et un script qui indique les « J’aime » (idiot innocent que je suis).

J’avais posé le script officiel de Facebook sans plus d’optimisations. Je lance une analyse… le document complete (page affichée) et le document fully loaded (tous éléments chargés) sont quasi-équivalents, mais le tout me semble plutôt lourd (+ de 700ko). Je suis un peu surpris, le site en question me semblait assez léger (hormis deux grosses images et un fichier JavaScript, rien de bien méchant). Le Speed Index est plutôt bon : vers 1500 (plus c’est bas, meilleur c’est, la moyenne étant à 4500).

Je décide de juste différer le chargement et donc l’exécution du script de Facebook, quand le DOM est prêt (grosso modo, la page sera construite, elle chargera ce script non prioritaire seulement à ce moment). Je relance les tests dans la même configuration (depuis l’Angleterre avec une bonne connexion), et là… grosse surprise !

Le résultat est là : affichage du site avec un chargement différé.

Le document complete est à 307ko et le document fully loaded est à 710ko ! En clair, ces deux boutons et leurs fonctionnalités ne pèsent pas moins de plus d’une fois le poids complet du site. Le Speed Index chute à 1327. Le site s’affiche en moins de 2,5 secondes, ce qui est plutôt satisfaisant.

Je ne sais pas pour vous, mais moi, je trouve cela choquant. Surtout à l’heure où l’on se plaint d’avoir des sites lourdingues, là c’est un peu fort de café.

De rage, je bricole en vitesse pour que ces boutons ne se chargent pas du tout sur le mobile. Je fais un essai avec une connexion moins performante sur mobile avec cette « petite » optimisation, le verdict tombe : 170ko (ce qui me semble très raisonnable), temps d’affichage correct. Je n’ose pas imaginer si je n’avais pas fait cette optimisation.

Un rapide test qualité sur Dareboost achève de m’engrincher au sujet de ce plug-in : les problèmes remontés viennent aussi de ce plug-in. Grmlbmlbmlb…

Je sais que la plupart de mes clients n’y pensent pas (et même certains s’en foutent complètement), mais pour de bon que ça m’interpelle. Ok, on peut me taxer de râleur à propos des réseaux sociaux. Il n’en reste pas moins qu’un tel impact sur la performance d’un site est bien trop important pour qu’on l’ignore.

En tout cas :

  • il va vraiment falloir évangéliser auprès de nos clients sur le coût qu’ont ces plugins mal dégrossis qu’ils nous réclament sans même savoir pourquoi.
  • Utiliser des solutions beaucoup plus légères comme Simple Sharing Buttons, et ne pas céder à la facilité des plug-ins officiels.
  • Ou mieux… s’en passer.

La dernière option me plait bien. :)

Stop pushing the web forward : mon avis (le 02/08/2015)

Je suis tombé sur un article de PPK intitulé Stop pushing the web forward. Article qui bien entendu déchaine les passions.

Très honnêtement, même si je trouve l’idée radicale (comme tout bon article générateur de trolls), j’avoue que cette idée qui semble saugrenue trouve un certain écho chez moi. Et curieusement, elle trouve d’autres échos sur des profils assez différents du mien, notamment chez Matthias Dugué, que je vous invite à lire (je vais régulièrement le mentionner dans ce billet).

Cet article de PPK génère donc quantité de réactions, j’en mets donc la plupart de côté (même si certaines, comme celle de Christian Heilmann sont assez éclairées), car disons-le clairement, les 140 caractères de Twitter ne sont pas assez pour sortir de la caricature.

Heu attends, tu parles de stopper tout pendant un an ?

Oui oui, c’est bien moi, qui fustigeait la lente évolution du web il y a quelques années. Si si.

Si vous n’avez pas connu cette époque, nous sortions de la guerre des navigateurs, le web – du moins son évolution – se mit doucement… à dormir pendant quelques années. Comme le dit très justement Matthias, c’est une sorte de Moyen-Âge obscurantiste. Et j’ai été très content d’en sortir il y a quelques années, enfin on peut se marrer et faire des trucs incroyables avec CSS et tout le reste.

Car si nous avons désormais le matériau le plus flexible qui soit (on peut le tordre à souhait en responsive), il y a quelques années, ce n’était pas du tout aussi agréable. Si vous pouviez montrer à quelqu’un en 2002 les trucs hallucinants qu’on peut faire ne serait-ce qu’avec les media-queries aujourd’hui, il aurait probablement pleuré de bonheur à l’époque.

Un moratoire ?

Grosso modo, l’article de PPK invite à tirer le frein à main dans cette course aux nouvelles fonctionnalités, car selon lui, « la machine à innovation tourne à pleine vitesse dans la mauvaise direction ». Il propose donc de stopper l’ajout de nouvelles fonctionnalités pendant un an.

L’argumentaire est très percutant et à la limite de la condescendance pour les fabricants de navigateurs. Clairement, j’élude cette partie de l’implémentation dans les navigateurs : comme je ne connais pas assez ce monde, je dirais sûrement des âneries (donc je vais m’en abstenir). Je m’intéresse plutôt à cette idée du point de vue des développeurs, et du point de vue de l’artisan du web que je suis.

À première vue, pas de moratoire

Personnellement, ce foisonnement permanent de nouveautés côté navigateurs et langages ne me gêne pas, il aurait même tendance à me ravir. Je me dis que c’est chouette, on a de belles choses qui vont arriver dans les navigateurs.

Car oui, je fais beaucoup de veille, mais je raisonne en « temps industriel ». En quelque sorte, je vois ce qui est raisonnablement utilisable ou non dans l’état actuel des navigateurs et des cahiers des charges de mes projets. Typiquement, plein d’articles parlent par exemple du Grid Layout, et je suis cela avec attention. Par contre, actuellement, je me vois pas utiliser cela en production, le support en étant très limité (seulement sur Internet Explorer 10+ au moment où j’écris ce billet).

J’appelle cela aussi le principe de réalité. On peut grogner contre le non-support de telle propriété sur tel navigateur, toujours est-il qu’on doit faire avec. Cela fait partie des règles du jeu (à mon humble avis), et il est de ma responsabilité de dire quand on sort de ces règles (demandes non-sensiques d’un client ou d’un graphiste).

Certes cela peut me limiter ou me faire m’arracher les cheveux parfois, mais comme on dit, de la contrainte nait la créativité. :)

Une vision biaisée

J’ai été élevé au grain OpenWeb et aux standards du web depuis plus de 10 ans. Pour moi, les concepts d’accessibilité et d’universalité du web sont tellement évidents que je n’arrive même pas à imaginer qu’on ne pense pas ainsi.

Faire du webkit-only ne fait pas partie de mon code génétique pour donner un exemple, je n’arrive pas à le comprendre.

On a déjà fait cette erreur avec Internet Explorer il y a des années à trop vouloir faire du IE-only et certains s’en sont mordus les doigts, ce n’est pas pour refaire les mêmes bourdes 7 ans après.

Sauf que…

Des signes inquiétants

J’ai l’impression que tout le monde ne fonctionne pas ainsi. On a déjà eu une salve violente il y a quelque temps avec un appel de Daniel Glazman pour une sombre histoire de préfixes. Avant, on pouvait charger les navigateurs de ne pas respecter les règles du jeu, mais là, c’est bien l’usage qui a contraint les navigateurs à sortir des clous. Autrement dit, ce sont les développeurs qui n’ont pas respecté les règles du jeu.

Un billet de Karl Dubost intitulé Vendor Prefixes And Market Reality m’a choqué récemment. Je vous le résume.

Karl est impliqué dans la compatibilité des sites, il a testé les 100 plus gros sites au Japon. Si les premières versions (-webkit) de flexbox étaient supprimées (ce qui devrait être le cas, elles sont basées sur d’anciennes spécifications), 20% des sites seraient cassés.

C’est profondément choquant. Objectivement, le billet de Karl m’interpelle violemment, même si j’avais bien des doutes.

Cela veut dire qu’on est sur du bancal. Ironie du sort, le Web a été voulu comme quelque chose de solide, et là nous sommes sur des béquilles bien tremblantes. À mon avis, un premier problème est qu’on a un seul Karl Dubost qui se soucie de la compatibilité pour 10 (100, 1000 ?) enragés qui vont sauter sur le premier truc instable comme des gosses.

J’imagine que les ordres de grandeurs sont les mêmes dans le monde entier. Et ce qui me fait encore plus peur, c’est qu’il n’y a pas de raison que cela se calme, Webkit étant ultra-dominant sur le mobile. Et Google Chrome devient aussi dominant sur le desktop, même si c’est un peu moins marqué.

Ironie du sort : à trop vouloir se jeter sur les nouveautés, ces comportements vont freiner… l’arrivée de nouveautés. Ou du moins fragiliser l’évolution.

Et les polyfills ?

Matthias mentionne aussi le sujet des polyfills. Là, j’ai moins d’expérience que lui sur ce sujet, je ne m’en sers quasiment plus. J’y ai surtout été confronté quand Internet Explorer 6 et 7 étaient la norme, et clairement, cela me débectait d’utiliser des tonnes de JavaScript un peu bancals pour émuler une propriété. Depuis, j’ai banni ces rustines mal dégrossies, le concept de la dégradation gracieuse a fait son chemin.

Notons que le problème est autrement plus violent avec les API, là on ne parle pas d’émuler une petite propriété CSS, mais bien quelque chose de plus compliqué.

Selon Matthias, bon nombre de développeurs vont se ruer dessus et faire de la merde. J’aimerais qu’il ait tort, mais je crains que ses observations ne soient malheureusement assez justes…

Et les futurs débutants ?

Comme l’indique Matthias, les débutants sont aussi une préoccupation.

Je vais peut-être être *salaud*, mais je préfère clairement avoir été un débutant en intégration il y a quelques années que maintenant, même si ce n’est pas toujours comparable.

Notez que même avec plus de dix ans d’expérience… je m’inclus dedans, je suis débutant dans plein d’aspects vu que pleins de nouveautés sortent sans arrêt. Et on ne peut pas tout savoir. Bref, on va tous être débutants à un moment ou à un autre (et c’est normal, on ne peut pas tout savoir).

Sauf que les débutants commencent à devenir angoissés sur la veille technologique. Et je pense qu’il y a une obligation morale de le transmettre et d’en faire comprendre les enjeux, sans quoi on ne peut pas reprocher aux débutants de faire des bêtises. Surtout celles qu’on a déjà faites. N’oublions pas que ce sont nos futurs collègues dont on parle, donc in fine de notre propre santé mentale.

Arrêter tout pendant un an ?

Soyons clairs : je pense que cela n’arrivera probablement jamais, et c’est très bien. Je ne veux pas revivre ce Moyen-Âge, et je pense que personne ne veut le revivre. Après… qui peut prédire l’avenir ?

Si je mets en perspective, c’est assez logique même. On est passé d’une période de lente évolution propice à beaucoup de réflexion (des thinkers) à… l’exact opposé, une période de très forte évolution propice à l’action (des makers).

Si vous empêchez un organisme vivant d’évoluer ou de se mouvoir, quand vous le libérez, il va se déchainer et partir dans tous les sens. C’est exactement ce qu’il se passe sur le front-end actuellement : nouveautés, outils, frameworks, etc. ça foisonne de tous les côtés, il ne se passe pas un jour sans qu’il y en ait un nouveau – révolutionnaire  qui va laver plus blanc que les précédents. À mon humble avis, le bonheur est dans l’équilibre entre ces deux tendances.

Néanmoins, si Matthias utilise une élégante métaphore d’élastique, je le cite :

Accélérer encore, c’est faire avancer cette mutation à marche forcée, là ou les processus naturels ont besoin de temps. À trop tirer sur la corde, on risque de se prendre l’élastique dans la gueule.

Perso, j’en aurais une beaucoup moins élégante :

Un organisme qui bouffe trop a parfois besoin de roter. Et parfois, il va tout simplement vomir le surplus. Et s’il bouffe n’importe comment, il va avoir des carences.

Les préfixes étaient un sacré rot, on en sent encore l’odeur fétide. J’ai peur que le renvoi ne soit pas loin d’ailleurs.

Qui ne me dit pas que de nombreux rots ou renvois ne sont pas en train de se préparer ? Au hasard :

  • des pages super-lourdes qui ne réduisent pas leur poids
  • l’accessibilité qui peine toujours
  • des problèmes de compatibilité
  • la jungle des e-mails au format HTML
  • etc.

À ma petite échelle, je développe des plug-ins accessibles, et c’est parfois la misère pour assurer une compatibilité correcte (oui, VoiceOver, c’est toi que je hais).

Quand aux débutants, je peux bien leur conseiller de prendre le temps d’absorber, ils risquent de poser de sacrés rots aussi. J’ai encore vu un splendide tutoriel en JavaScript récemment. Superbe, sauf que l’auteur aurait pu faire tout ce qu’il expliquait avec le positionnement tabulaire en CSS, avec deux lignes de code. Ce n’est pas de sa faute, peut-être n’a-t-il jamais appris cela.

Mettez ce genre de petites erreurs à la puissance 10. Cela ne va pas réduire notre empreinte.

En conclusion

Bref, je ne suis pas pour dire d’arrêter, c’est impossible, et même pas souhaitable.

Mais je reconnais que ce rythme complètement dingue pose aussi des problèmes. De prime abord, je me dis qu’une utilisation raisonnée et éclairée suffirait à régler de nombreux problèmes, mais ce n’est pas le chemin qui semble se profiler.

Effectivement, ce billet m’interpelle.

J’aimerais bien lire des billets chez les fabricants de navigateurs à ce sujet, et de la part d’autres développeurs/profils. À vos claviers !

Pourquoi la diversité est importante (le 10/07/2015)

Cela ne vous aura (peut-être) pas échappé, l’atelier Opquast V3 a été récemment ouvert, c’est donc la troisième version du référentiel des bonnes pratiques du web qui est en train de se faire.

Opquast V3 (refait par un expert en Photoshop)

Je ne saurais que trop vous conseiller d’aller y faire un tour et même d’y participer, vous vous rendrez service en apprenant sûrement plein de choses. Rien qu’en suivant les discussions, j’ai déjà eu le plaisir d’apprendre plein de choses bien intéressantes !

Vous vous rendrez service… et vous rendrez service à cet atelier en amenant votre singularité.

Moi, une singularité ?

Oh que oui, et même bien plus que vous ne pensez.

Car le succès de ces ateliers n’est pas uniquement basé sur le talent de ceux qui y participent, mais aussi par la diversité des intervenants : leur niveau, leur environnement, leur spécialité, leurs expériences, etc.

Celui qui travaille sur plein de sites en agence web, celui qui ne travaille que sur un seul site à plein temps, celui qui fait des applications, etc. Tous sont utiles, car tous ces contextes sont différents.

Et même les débutants sont importants : une formulation trop pointue ou mal comprise est aussi un problème potentiel, car elle induira des erreurs d’interprétation.

Plus il y aura de variété parmi les personnes qui vont discuter ensemble, plus le référentiel sera solide : il y aura moins de risques d’être passé à côté d’un cas auquel personne n’a pensé.

Vous attendez encore pour amener votre singularité ? N’attendez plus, allez-y !

Retour sur la kiwiparty édition 2015 (le 28/06/2015)

Je n’avais pas eu le plaisir d’être de l’édition précédente, je me suis du coup rattrapé avec cette édition 2015 de la Kiwiparty qui a eu lieu vendredi dernier, le 19 juin donc. Autant le dire de suite, ce fut un régal à tous les niveaux.

Kiwiparty

::before

Coquin de sort, je me baladais au hasard dans Strasbourg la veille, et je tombe sur le groupe des orateurs au hasard d’une rue. Du coup, me voilà embarqué avec cette joyeuse équipée pour un repas avec une très bonne ambiance. Me voila fin prêt pour la journée du lendemain !

Icon-fonts vs SVG sprites

Vincent de Oliveira est un habitué de la kiwiparty, orateur depuis au moins 4 éditions, cette année il s’est intéressé à deux techniques d’insertion d’images vectorielles : les icon-fonts et les SVG. En les comparant sur divers points, il montre leurs points forts et leurs points faibles.

Avantage final pour SVG, et cela me conforte sur le fait d’en utiliser toujours plus au boulot. Et j’ai appris plein de trucs !

Les personas : comment les concevoir et les utiliser

Gwennola Pierre nous a présenté les personas, leurs intérêts et ce qu’ils peuvent apporter à la réflexion autour des publics d’un site.

Toujours intéressant pour les concepteurs de sites ainsi que pour les clients, qui ont parfois tendance à oublier leur(s) cible(s) : personnifier des publics permet de mieux les servir.

Le debug d’applications web simplifié

Etienne Margraff et David « Yoda » Rousset ont présenté Vorlon.js, qui permet de debugger des sites sur mobile. Vraiment très impressionnant, je compte suivre de très près ce projet, qui pourrait bien créer une petite révolution au quotidien : piloter le debug sur mobile depuis une interface, un Firebug universel en somme.

Le tout basé sur des standards, c’est vraiment un projet top. Les devs de Microsoft ne ménagent pas leurs efforts pour qu’on les adore, et vous savez quoi ? On les adore.

Le chasseur-cueilleur, Hannibal Lecter, et autres considérations ergonomiques.

Antonio Capobianco nous a expliqué l’utilité de la cognition spatiale dans l’utilisation de nos sites, et comment l’exploiter pour mieux permettre leur utilisation. À l’aide d’exemples et de contre-exemples, il nous a montré comment certains cas (pourtant à la mode) sont totalement contre-intuitifs pour cette capacité.

J’adore ce genre de sujets que l’on n’attend pas : c’est surprenant et intéressant !

Le pseudo-élément, c’est bon !

Enfin, cela faisait un moment que j’attendais que Matthieu Bué montre l’étendue de son savoir sur ce sujet ! Et je n’ai pas été déçu du voyage : des tonnes de bonnes idées, un sujet bien maîtrisé, une présentation marrante, c’était un régal. Au vu de ce que j’ai entendu autour de moi, je n’étais pas le seul à apprécier.

Là aussi, j’adore ce genre de sujets : comment pousser une possibilité pour faire des trucs proprement géniaux sans Javascript !

Le web et ses sales caractères

Damien Senger, en bon amoureux de la typographie, nous a présenté diverses astuces et techniques à propos de la typographie. De l’utilisation de local() pour éviter de télécharger des fichiers inutiles, en passant par une utilisation correcte de la syntaxe, etc., c’est une bonne revue de la syntaxe @font-face.

En grand fan du sujet, je fus conquis d’avance. :)

Faire passer un mammouth dans un tuyau d’arrosage (aka la performance sur mobile)

Jean-Pierre Vincent, Monsieur Performance, nous a fait un point sur les techniques et bonnes choses à savoir sur son sujet de predilection, avec exemples à la clef.

Que dire de plus ? Des années que j’écoute tout ce qu’il dit sur le sujet… et je ne m’en lasse pas !

UX design & hackathon : un guide de survie

Laurence Vagner nous a proposé un sujet digne d’elle : original et inattendu. Les game jam et autres sont des projets Armageddon où l’on n’a même pas le temps de stresser, on doit foncer et se concentrer sur l’essentiel.

Ou comment survivre sur des projets où le temps est très limité. Instructif et très rigolo !

Le responsive côté serveur

Rémi Grumeau pose avec justesse des questions pertinentes : par exemple, si vous utilisez un modernizr, vous posez à chaque page les mêmes questions au même navigateur : supportes-tu ceci, cela, etc. ? Effectivement, il y aurait des choses à optimiser côté front sans pour autant sacrifier son universalité.

C’est là que la réponse apportée m’a chiffonnée : même si les pistes ne sont pas inintéressantes, il y a un problème à la base. Ces techniques s’appuient sur de la détection de user-agent, avec la fiabilité et les effets de bord que l’on sait. Vraies questions, mais réponses gênantes à mon humble avis.

Et si on parlait productivité ?

Nicolas Birckel démonte avec brio des mythes à propos de la productivité (en parlant de l’état de flow, etc.), et… mais Dieu que ça fait du bien, ces propos devraient être martelés ! D’ailleurs je me demande si on ne devrait pas prendre un botin et taper sur le crâne de nos chefs de projet pour qu’ils le comprennent de gré ou de force !

Excellent, cela me parle particulièrement, étant confronté régulièrement à ces mythes qui ont malheureusement la vie dure.

L’UX sans Utilisateur n’est que pornographie

Raphaël Yharrassarry nous a relaté trois expériences sur l’UX, et comment on peut limiter la casse si l’on n’a pas d’utilisateurs à disposition. Toujours instructif et bon à prendre !

J’ai particulièrement adoré la méthode « Arobert », pendant négatif des méthodes « à Gilles » (agiles), qui m’a fait hurler de rire à plusieurs reprises ! :)

Au final

Si vous pensez que je suis dithyrambique à propos de cet événement, essayez d’y participer, vous comprendrez. À la kiwiparty, les choses sont simples : on ne se prend pas la tête, on apprend des choses intéressantes et ça fait juste du bien.

En plus, l’organisation est au top, on est gâté (mamma mia le goutaÿ !), on rigole beaucoup, et le temps s’écoule bien trop vite, même si l’after de l’after s’est fini à 4H du matin. :)

Même si l’on papote joyeusement technique, j’ai été surpris de la dimension humaine de cette édition. Derrière nos réseaux sociaux à la con et les postures inhérentes à ces derniers, il y a des êtres humains, avec leurs doutes, leurs peurs, leurs joies, leurs envies, leur histoire, etc. Incroyable de voir comme les psycho-drames des réseaux sociaux font « pschit » quand on discute de visu. Je m’intéresse de plus en plus aux histoires derrière le code, j’aime cette mise en perspective.

Je croyais que les côtés humains et le savoir-être perdaient du terrain au profil de l’esbroufe des réseaux sociaux, le code, etc. Cette kiwiparty m’a rassuré. De nombreuses personnes avec qui j’ai pu discuter y sont très sensibles.

« N’oublions pas que nous avons été débutants »

Combien de fois ai-je entendu cette phrase. Je dirais même que nous sommes tous débutants : il est impossible de tout savoir. Je suis le débutant de plein d’autres, et d’autres peuvent être mes débutants.

Je me demande si finalement, le web n’est pas qu’une question de valeurs. Maintenant, il nous appartient de faire rayonner ces valeurs et de moins mettre en lumière ce qui nous déplait.

Je ne sais pas si c’est le web que nous aurons, mais en tout cas, la kiwiparty, c’est le web comme je l’aime. Bravo Alsacreations.

Travailler la réduction à « ma dépendance » (le 08/06/2015)

Un tweet de STPo exprime bien un sentiment qui me dérange de plus en plus dans mon métier. Grosso modo, la phrase qu’il cite donne ceci (traduction approximative et incomplète).

La pire partie du développement web est la quantité de temps dépensée à investiguer chaque petit nouvel outil qui sort. Cela pourrait être utile ou non, comment le savoir tant qu’on ne l’a pas essayé soi-même ?
[…]
Enfin, qu’arrive-t-il quand vous quittez votre job et que quelqu’un arrive un an après ? Oh, ce pré-processeur Sass ne marche pas ? C’est quoi Angular, un outil pour faire des mesures ?

Effectivement, et ce n’est pas la première fois que j’en parle ici et ailleurs (notamment dans la veille technologique), il y a actuellement une espèce de course à l’armement point de vue outils sur le front-end (mais pas que).

Une blague qui revient d’ailleurs souvent étant qu’il ne se passe pas une journée sans qu’un nouveau framework JavaScript/CSS ne sorte. Sans compter tous les outils de workflow : pré-processeurs, post-processeurs, imparfait-du-subjonctif-processeurs, etc. Ils ont d’ailleurs des noms bizarres, Grunt (pour moi le cri d’un Orc), Gulp (quelqu’un qui avale sa salive, ça ne met pas en confiance), etc.

Comme tout curieux, il m’arrive d’en tester, d’en utiliser, d’en adopter, d’en créer, etc. Je me dis que tout ce qui est « cool » et qui apporte un vrai bénéfice ne peut pas tarder à être adopté.

Sauf que non, pas du tout, enfin, pas toujours. Laissez-moi vous raconter quelques mésaventures.

L’autre jour, on me demande de revenir sur un site que j’avais intégré. J’avais fait un boulot millimétré, hyper carré (variables, conventions, etc.) avec la version Sass de Röcssti. Sauf que le site en question a été modifié entre temps par un autre, bien malmené, le tout sur la CSS générée et non la version Sass. Oui, vous pourriez me répondre que celui qui a fait ça mérite des baffes (et je suis 100% d’accord), il n’empêche que ça arrive, et in fine, j’ai été emmerdé par mon propre choix.

Autre cas de figure : j’avais utilisé Sass pour un autre site, et dès qu’une modification doit être effectuée dessus point de vue CSS, je suis systématiquement appelé (configuration, etc.). Et pareil pour plein d’autres très bons outils.

Ce n’est pas mal en soi que je sois référent sur la CSS de certains sites ou sur certains outils, mais clairement et pour le dire vulgairement : moi ça m’emmerde d’être le maillon incontournable.

J’adore rendre service. J’adore expliquer des trucs, des techniques. En tutoriel, dans des billets, des articles, des conférences ou de vive voix, c’est un des plus grands plaisirs de mon métier. Mais comme tout développeur, j’ai aussi besoin qu’on me foute la paix quand je code. Et je déteste être dérangé en congé ou en vacances parce que j’ai mis en place un truc que je suis le seul à maitriser (et encore dans certains cas, repassez sur un développement vieux de deux ans, des fois, vous écarquillez les yeux, même sur votre propre code).

Et la seule loi qui prévaut, c’est celle de l’emmerdement maximum, autrement dit la loi de Murphy. Si je peux être emmerdé sur 5 projets, je vais être emmerdé sur 5 projets. Au final, quel est le plus important ?

  • Que j’utilise un outil qui me fait gagner 2 heures mais où je peux être dérangé 10 fois à l’avenir ?
  • Que je permette qu’on reprenne mon travail sans moi ?
  • Que je sois future-ready pour des trucs instables ? (j’adore les gens qui prédisent le futur dans notre métier, ils devraient postuler chez les voyants)
  • Que je me facilite la vie sans penser aux conséquences ?
  • Ou que je réduise la dépendance à l’outil ?

Alors oui, pour certaines intégrations, je ne voudrais et ne pourrais pas me passer de Sass car le temps pour faire certaines choses à la main serait monstrueux. Mais depuis une année, je remarque… qu’on s’en passe très bien dans de (très) nombreux cas, surtout quand on a un peu de méthodologie. Et une CSS reste une CSS, même dans 3 ans. Qui me dit ce qui restera dans 3 ans des outils ?

Que ce soit clair, je ne suis pas anti-outils, j’adore l’outil de calcul de rythme vertical de Pascal pour n’en citer qu’un parmi beaucoup. Et il y a pas de risque à utiliser les valeurs qu’il génère, c’est de la CSS.

J’adore l’approche de Kaelig quand il explique comment faire le pont entre les développeurs et les designers. C’est brillant et le contexte est parfaitement adapté.

Clairement, je travaille à réduire la dépendance à ma personne (et donc à l’outil). Déjà, parce que j’ai décidé d’arrêter de sauver le monde. Et surtout pour penser aux autres, que j’emmerde tout autant que moi. Et curieusement, je n’ai jamais autant progressé que depuis que je réfléchis ainsi. Cela force par exemple à faire des scripts aussi simples et souples que possible. À être hyper carré dans mes CSS.

La fin est dans l’amélioration qualitative globale, pas dans les outils. Les outils ne sont qu’un moyen. Il devrait y avoir une mesure de l’empreinte que l’on fait sur ces choix. Une mesure de la quantité de doigts que l’on met dans un engrenage…

Les trucs qui prennent du temps (le 29/05/2015)

Parfois les gens (clients, patrons, développeurs, etc.) croient que « parce qu’on est sur le Web », ça va forcément aller vite, on peut tout changer. Effectivement, c’est un domaine qui bouge vite, très vite. Il m’arrive d’assister à des conférences, et ce qui y est dit arrive dans mon boulot la semaine suivante, de manière parfois brutale et très concrète. Tout se met à jour très vite. On peut fixer un problème en dix minutes.

Mais parfois, certains points demandent du temps, beaucoup de temps. À titre personnel, je vous raconte une histoire sur un point de qualité qui m’a pris un temps fou à mieux maîtriser. C’est une histoire personnelle, peut-être cela vous semblera simple, peut-être butez-vous sur d’autres points, c’est un exemple.

Il y a presque dix ans, je m’intéressais déjà à l’accessibilité et à la qualité, et un point a toujours forcé mon admiration pour ceux qui y arrivaient :

Il est possible de faire un zoom texte de 200% sans rendre le site inconsultable

Grosso modo hein, je n’ai plus l’intitulé exact. Je parle bien d’un zoom texte, pas d’un zoom global.

Je faisais des intégrations pas trop mal pour l’époque, mais ce point, je n’y arrivais jamais, il y avait toujours un cas où ça foirait lamentablement. Le graphisme pétait, les dépassements étaient légion, etc. et tout cela était insoluble pour moi.

Il a fallu dans un premier temps :

  • que je me mette à travailler en unité relatives, notamment les em ;
  • et que je maîtrise mieux la conception de CSS, notamment à « penser en dehors de la boite ».

Cela, c’était déjà la première étape, et ça ne s’est pas fait en deux jours. Mais même avec cela, certains designs n’étaient pas adaptables (en tout cas, pas de manière triviale). Pendant des années, je me suis dit que c’était proprement impossible de faire cela facilement, car il y avait toujours un cas qui foirait.

Puis est arrivé le responsive et les media-queries. Entre temps, je travaillais à avoir plus de propreté et de qualité globale sur mes feuilles de style (rythme vertical, etc.), Röcssti en résultant un peu plus tard. Enfin, avec les media-queries, on pouvait adapter facilement un design selon la réalisation. Bien entendu, il fallait maîtriser un peu mieux ces nouveaux concepts. Donc pratique supplémentaire exigée pour cette seconde étape.

Et avec les media-queries en em, des CSS plus propres et mieux conçues, l’utilisation des em de manière globale, enfin il m’est possible d’envisager ce point de qualité de manière plus sereine. J’arrivais enfin à le faire. Même si cela n’est pas absolument parfait, cela peut se voir sur le site de Röcssti, sur Arcora Monaco, ici-même, etc.

On est bien d’accord : je ne vais pas oser prétendre que j’y arrive à tous les coups et que c’est parfait à chaque fois, car ce n’est pas le cas. Mais je suis passé de « c’est hyper difficile voire insoluble » à « c’est faisable et tout à fait envisageable » ou au pire à « je peux y arriver en temps raisonnable ».

Seulement, tout cela a pris beaucoup de temps. Des années de pratique. Et j’apprends encore sur ce point. Donc, ne vous inquiétez pas si vous peinez sur certains points, des fois, cela met du temps. Même sur le Web où tout va vite.

Amélioration progressive, capacités et CSS (2/2) (le 16/05/2015)

J’ai eu l’immense plaisir de réaliser un site pour le Haut-Commissariat des Droits de l’Homme, ce site s’intitule « People with albinism, not ghosts but human beings ».

Je vous propose deux billets montrant quelques astuces sympathiques mêlant accessibilité, amélioration progressive, orthogonalité et intégration CSS. Le premier parlait d’un burger-icon avec de l’ARIA et des transitions CSS. Voici le second !

De l’amélioration progressive avec Modernizr

Un souci s’est posé sur les images/liens des histoires. Quand on les survole, ils doivent faire apparaître le nom de la personne (et mettre en couleur la photo), comme indiqué sur la capture ci-dessous.

Touch events, transition CSS

Seul problème, sur les iPad et autres iMachins, ce comportement induit un « changement » de contenu. J’avais déjà décrit ce potentiel souci ici : Touch events et contenus cachés au survol.

Dans ce cas-là, c’est particulièrement désagréable et contre-intuitif pour l’utilisateur : il faut taper à deux reprises sur un lien, ce que personne ne pensera à faire sur un site. Encore une fois, l’amélioration progressive va nous sauver de manière transparente pour l’utilisateur.

L’idée est très simple : les informations seront affichées par défaut en-dessous ainsi que la photo en couleur.

Touch events, sans élément caché

Et Modernizr permet de détecter si la capacité touch est présente ou non. Dans mon cas, c’est uniquement quand la classe no-touch sera ajoutée sur l’élément html que je pourrais faire l’effet souhaité, autrement dit positionner le bloc avec le nom en bas, et déclencher une transition pour le survol.

Donc pour l’image en noir et blanc :

/* cachée par défaut */
.story-link__imgblack {
opacity: 0;
}

/* et affichée si on a pas de touch */
.no-touch .story-link__imgblack {
opacity: 1;
}

/* au survol du lien */
/* on la fait disparaitre */
/* ce qui fait apparaitre celle en couleur */
.no-touch .story-link:focus .story-link__imgblack,
.no-touch .story-link:hover .story-link__imgblack {
opacity: 0;
}

Tout simple. Pour le nom qui doit apparaitre, idem : quand on n’a pas la capacité touch, on le positionne en-dehors, et au survol, on le fait remonter :

.no-touch .story-link__text {
position: absolute;
left: 0;
bottom: -100%;
right: 0;
z-index: 2;
/* préfixes ! */
transition: bottom .5s ease;
}
/* de -100% à 0 */
/* le bloc remonte */
.no-touch .story-link:focus .story-link__text,
.no-touch .story-link:hover .story-link__text {
bottom: 0;
}

Et l’effet est là, tout simple en amélioration progressive en CSS avec Modernizr. Le gros avantage de faire ainsi est de ne pas mobiliser de JavaScript là où il n’y en a pas besoin, CSS faisant très bien son boulot ici.

Un lien qui défile vers sa destination

Ces liens sont par exemple sur la page de Connie Chiu ou les autres histoires.

Là aussi, avec un peu d’amélioration progressive, c’est très simple. En partant d’un bête lien vers une ancre :

<a href="#video" class="js-scrollto">Video</a>

Une petite fonction jQuery fait le tout sans effort, dans mon cas, comme le header est fixé, je retranche sa hauteur.


$('.js-scrollto').on( "click", function( event ) {
var $this = $(this),
$destination_id = $this.attr('href'),
$destination = $($destination_id),
$header = $('.header-shadow'),
$height_header = $header.height();

$('html, body').animate({
scrollTop: ($destination.offset().top - ($height_header) )
}, 500);

event.preventDefault();
});

Voilà, rien de bien compliqué. En espérant que ces petites astuces vous ont intéressé !

Amélioration progressive, orthogonalité et accessibilité (1/2) (le 16/05/2015)

J’ai eu l’immense plaisir de réaliser un site pour le Haut-Commissariat des Droits de l’Homme, ce site s’intitule « People with albinism, not ghosts but human beings ».

People with Albinism, amélioration progressive et accessibilité

Je vous propose deux billets montrant quelques astuces sympathiques mêlant accessibilité, amélioration progressive, orthogonalité et intégration CSS. En voici le premier.

Un burger-icon avec de l’ARIA et des transitions CSS

Le site comporte un « burger-icon » qui apparait à partir de la version tablette. Grosso modo (je vous passe tous les détails), c’est un lien qui pointe vers une ancre (avant que JavaScript ne s’en mêle :) ). Un détail cependant : il doit faire apparaitre le menu de navigation avec une transition CSS. Donc, en quelque sorte, cela devient un bouton avec JavaScript.

En se basant sur ARIA comme descripteur d’interface, c’est extrêmement simple, naturel et intuitif. Via jQuery, cela nous donne à l’initialisation :

$('#displaymenu').attr({
'aria-controls' : 'navigation-container',
'aria-expanded' : 'false',
'role' : 'button'
});
// ce qui donne
<a id="displaymenu" href="#navigation" aria-controls="navigation-container" aria-expanded="false" role="button">

aria-controls indique qu’il contrôle le conteneur ayant l’id navigation-container, et aria-expanded indiquera si le menu est ouvert ou non.

Ensuite, il faudra mettre aria-hidden sur #navigation-container, qui indiquera que le menu est fermé. À partir de ces états, on a tout ce qu’il faut pour poser les styles nécessaires à la transition CSS.

Au début, mon idée était de faire une transition sur height : c’est somme tout logique, la hauteur varie de height: 0 (état fermé) à height: auto. Sauf que… cela n’est pas possible, on ne peut pas animer ainsi, il faut indiquer une valeur numérique (dura lex sed lex).

La solution est alors d’animer la propriété max-height, elle variera de max-height: 0 (état fermé) à max-height: <une valeur suffisante mais pas trop> pour que l’animation soit complète mais pas trop longue.

.navigation-container {
/* ici les préfixes ! */
transition: max-height 1s ease;
}
.navigation-container[aria-hidden="true"] {
max-height: 0; /* caché */
}
.navigation-container[aria-hidden="false"] {
max-height: 25em; /* ouvert */
}

Comme vous pouvez le voir, les styles pour effectuer la transition sont d’une simplicité à l’épreuve des balles, la transition et les deux états (ouvert/fermé).

Maintenant, il ne reste plus qu’à créer le code pour transformer le lien vers une ancre en un bouton. Si l’on reprend le comportement du bouton, il doit s’activer :

  • quand on clique dessus ;
  • quand on tape entrée dessus ;
  • et quand on tape espace dessus.

Avec jQuery, l’événement click est déclenché quand on clique dessus, et comme la balise est un lien, quand on tape entrée. Il faudra donc que j’écoute quand la touche espace sera pressée sur l’élément #displaymenu.

Autre point de détail, les liens du menu restent focusables même s’ils sont pris dans un conteneur avec max-height: 0 (il faudrait que le conteneur soit en display: none pour qu’ils ne soient plus focusables). Autrement dit, les liens peuvent être atteints au clavier quand le menu est fermé, ce qui n’est pas très logique.

Deux solutions :

  • ajouter un style comme display: none une fois la transition terminée (ce que je fais sur mon carrousel accessible) ;
  • ou rendre les liens non focusables via tabindex="-1".

La seconde solution étant très simple à faire et particulièrement adaptée à mon cas, c’est celle que j’ai retenue. Ce qui nous donne :

// si l’on frappe une touche clavier 
// ou si l’on clique sur le #displaymenu
$('#displaymenu').on( "click keydown", function( event ) {
var $this = $(this),
$navigation_container = $('.navigation-container'), // le conteneur de la navigation
$navigation_links = $('.navigation__link'); // les liens de navigation

// soit un click = clic ou entrée
// soit une touche = keycode 32 => espace
if ( event.type==='click' || ( event.type==='keydown' && event.keyCode == 32 ) ) {

// si le menu est fermé
if ($this.attr('aria-expanded') === 'false') {
// on l’ouvre
$this.attr('aria-expanded', 'true');
// navigation ouverte
$navigation_container.attr('aria-hidden', 'false');
// on vire les tabindex pour les liens
$navigation_links.removeAttr('tabindex');
}
else {
// on ferme
$this.attr('aria-expanded', 'false');
$navigation_container.attr('aria-hidden', 'true');
// liens non focusables
$navigation_links.attr('tabindex', '-1');
}

// on évite la propagation dans ces cas uniquement
event.preventDefault();
}

});

Et voilà comment un lien se transforme en bouton. Bien entendu, ce n’est pas parfait, c’est sûrement améliorable. J’aurais pu utiliser la balise button qui m’aurait évité de faire tout cela : cette balise inclut par défaut les événements que j’ai dû recoder en jQuery. Autrement dit avec un button, pour chopper le clic, la touche entrée ou la touche espace, cela se fait juste ainsi :

$('button').on( "click", function( event ) {

Et pas besoin d’ajouter role="button". Là, vous venez sûrement de comprendre pourquoi j’ai utilisé cette balise dans mon script hide/show (collapsible regions). Avec la sémantique, beaucoup moins d’efforts !

Voilà, nous sommes à la fin de ce premier billet. Le second est disponible : Amélioration progressive, capacités et CSS (2/2).

J’adore Twitter (le 13/05/2015)

Je suis très peu fan des réseaux sociaux en général, mais j’avoue que j’adore Twitter. Même si je n’en fais pas un usage industriel comme peuvent le faire certains (je suis environ 280 personnes), j’y passe assez régulièrement, je discute avec plein de gens, une bonne part de ma veille technologique est dessus, leur application iPad et leurs versions web sont bien faites.

Il y a quelque temps, un tweet « coup de gueule » de ma part a suscité l’inquiétude et la surprise de certaines personnes qui me suivent (du genre, « je vais faire de la merde sur un site en production, et tant pis »).

Comme ces personnes ne manquent pas de bienveillance, elles se sont inquiétées que je ne fasse pas de bêtise (professionnelle) et m’ont donné de bons conseils. Si si, il n’y a pas que des terroristes pédonazi-philes sur le net.

Bien évidemment, en 140 caractères, on ne peut expliquer que le coup de gueule en question est très relatif : il n’a aucun impact sur un site en production, il ne gênera jamais la moindre personne. C’est juste une gueulante défouloir.

Oui, mes paroles dépassent parfois mes pensées. Et même si des fois, comme n’importe qui, j’aimerais mettre du poil à gratter dans le slip de quelqu’un qui me casse les pieds, vous vous doutez bien que je ne le fais jamais à titre professionnel (parce qu’à titre personnel, ça peut se discuter… mais non, je ne l’ai jamais fait non plus, vous croyez quoi !).

Comme disait ce cher Benjamin Franklin :

Il ne faut pas prendre pour argent comptant tout ce qu’on lit sur Twitter.

Bien entendu, il y environ 0% du contexte de chaque minuscule phrase postée, ce qui fait que des fois, 140 petits caractères déchainent les passions, au-delà du raisonnable et de l’objectivité. Et devinez quoi ? Ça n’empêche, j’adore Twitter.

Je n’ai rien à cacher… ou presque (le 05/05/2015)

Un point me surprend beaucoup dans le débat sur la loi sur le renseignement, c’est l’argument « je n’ai rien à cacher donc je m’en fous de cette loi ».

Le début de cette phrase est incomplet, il faut entendre : je n’ai rien à cacher… de répréhensible.

Comme toute personne somme toute « normale » : je n’ai jamais commis de crime, je n’ai jamais agressé une femme ou qui que ce soit, je n’ai pas vendu de drogue, je paie mes impôts, etc.

Donc effectivement, au regard de la loi, je n’ai rien à cacher. Si, comme une voisine le prétendait (une vieille un peu folle là où j’habitais avant), on m’accusait de faire du feu dans mon appartement et (sic) de faire brûler ladite voisine (oui, elle était vraiment dingue), et qu’un gendarme était missionné pour vérifier ces faits, effectivement, je n’ai rien à cacher à la justice, et je lui ferai vérifier de suite que je ne fous pas le feu au lotissement (s’il était besoin de le vérifier…).

Néanmoins, le fait que je n’aie rien à cacher de répréhensible n’implique pas que je souhaite que toute ma vie (privée) soit étalée ou même stockée.

Imaginons que mon truc, ce soit de faire l’amour déguisé en costume de loutre. En soi, même si ça peut être surprenant, ça n’a rien de répréhensible. Vous vous doutez bien que je ne souhaiterais pas que « ce petit plaisir » soit étalé quelque part, même fût-ce dans une boite noire !

Plus sérieusement, imaginons qu’un algorithme mal codé me mette sur surveillance, car j’ai fait une recherche sur le terrorisme. Impossible ? Il faut être fou ou incroyablement naïf pour croire qu’un algorithme n’est pas faillible (et c’est un développeur qui vous le dit). Imaginons que ce soit votre enfant qui fasse cette recherche, pour un exposé ou parce qu’il veut faire le malin devant ses copains.

Citons ce cher Benjamin Franklin :

Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne mérite ni l’une ni l’autre, et finit par perdre les deux.

Autre chose : reprenons l’exemple de la connerie de jeunesse. Qui me dit qu’à l’avenir, ces informations ne seront pas utilisées contre votre enfant ?

Même sans imaginer un truc complètement parano, imaginons qu’à la suite d’un énième scandale de factures de taxi avec de l’argent public, on dise que pour avoir un job en tant que fonctionnaire, il faille ne jamais avoir eu de « casier » dans une boite noire, parce qu’il faut des personnes au-dessus de tout soupçon. Et pourquoi pas ? Votre enfant serait donc emmerdé toute sa vie.

Pire, imaginons que ces boites noires soient piratées. Cela vous plairait que vos données soient entre les mains… de n’importe qui ?

Je crois sincèrement que les conséquences potentielles d’un tel système dépassent totalement ce pour quoi il a été imaginé (changements de gouvernance, lois futures, etc.). En mythologie, on appelle cela une boite de Pandore. Et il ne vaut mieux pas les ouvrir.

Ajoutons à cela que le système ne fait pas de différence entre un voleur de poules et un criminel. Et vous vous doutez bien que ce dernier saura comment ne pas se faire pincer, vous pouvez trouver en 5 minutes comment esquiver ces systèmes…

Note de lecture : Typographie web, de la collection « A book Apart » (le 03/05/2015)

J’avoue humblement que je n’avais pas encore entendu parler de ce nouveau tome de la collection A book part, écrit par Jason Santa Maria, au moment où je l’ai reçu (merci Eyrolles, vous êtes des choux à la crème).

Cette collection est intéressante même si elle est parfois inégale, ou en tout cas elle s’adresse à des publics différents. Typiquement, j’avais adoré Responsive Web Design, HTML5 pour les web designers, ou CSS3 pour les web designers en leur temps, et d’autres tomes m’avaient plus déçu (comme Mobile first).

Typographie web, de la collection A book Apart, par Jason Santa Maria

Là, autant le dire de suite : ce livre tape tout juste dans ce qui me plait. Même si je ne suis pas un expert en typographie (j’ai quelques bases), c’est un sujet qui m’intéresse beaucoup et qui attise fortement ma curiosité. La typographie est un peu comme une drogue : plus on s’y intéresse, et plus on y devient accro.

Comme l’explique très justement l’auteur, la typographie est la « voix » du design et l’outil le plus puissant dont on dispose pour communiquer avec nos lecteurs. Typiquement, je suis le premier à ronchonner sur une typo mal choisie et/ou pauvre, cela gâche la lecture.

L’auteur explique l’expérience de lecture, comment évaluer une police, les choisir et les associer, créer des systèmes typographiques, etc. C’est bien expliqué et c’est plutôt accessible pour quelqu’un de mon niveau.

Comme je l’entends parfois (et j’en suis de plus en plus convaincu), un très fort pourcentage du message d’un site internet est véhiculé par la typographie, il serait donc bien dommage de négliger cette dernière, alors que « ces petites choses qui n’en sont pas » sont tellement agréables, et au final indispensables.

Concernant ce livre, en tout cas, si le sujet vous intéresse, je ne peux que vous recommander de le lire, cela se lit aisément et c’est un très bon moment de lecture. :)

Note de lecture : CSS3 pratique du design web (le 04/04/2015)

Un certain calme régnait en matière de livre en ce début d'année, toutefois, l'accalmie a été de courte durée, Eyrolles ayant été particulièrement généreux à mon égard.

Et là, manifestement, nous avons affaire à du lourd, autant au sens propre (le livre pèse son poids !) qu'au sens figuré. Rien de moins que Hugo Giraudel et Raphaël Goetter, deux de mes super-héros des CSS. Que nous ont-ils pondu, cette bande de joyeux drilles ?

CSS3, pratique du design web

Pour avoir pu « côtoyer » Raphaël (en public de ses conférences, lecteur de ses livres/billets ou en co-conférencier lors d'un atelier à Paris Web avec lui), ainsi qu'Hugo (lors d'une intervention à la Kiwiparty, et en tant que lecteur de ses très nombreux billets), je peux dire sans détour que je retrouve avec plaisir le style et les qualités des deux personnages dans ce livre :

  • les deux sont très précis dans leurs propos ;
  • quand ils s'emparent d'une question, ils ne la traitent pas à moitié ;
  • et ils sont très clairs dans leurs explications, sans pour autant sacrifier la technicité de leur propos.

Donc, même s'ils ne manquent pas d'humilité en disant que leur livre ne s'adresse pas aux experts de la profession, je me permets d'en douter fortement : vu la tonne d'information condensée dans ce livre, je doute sincèrement que même les vieux routards enragés de CSS n'apprennent rien du tout.

Car tout connaitre des sélecteurs CSS3, des nouvelles techniques de mise en page (multicolonne, flexbox, grid layout, position « sticky », régions, masques de formes), les propriétés sur le texte, les transformations, les animations, les variables, les styles conditionnels, etc. excusez du peu.

Certes, si certains chapitres me sont très familiers, notamment le contrôle du texte, la césure (pour avoir écrit un article dessus), si je bidouille de plus en plus les animations et autres transitions, si j'utilise Flexbox en amélioration progressive, certains chapitres m'étaient par contre beaucoup moins bien connus (n'oublions pas que ça fourmille de détails). En production, il est très rare que l'on utilise tout.

Pour ma part, cela m'a permis de bien consolider sur les sélecteurs (les vieux Internet Explorer m'avaient quelque peu désintéressé de la question, compatibilité oblige), et - réalité de la production oblige - certaines propriétés ne sont que très peu usitées dans mes feuilles de styles (je n'ai dû n'utiliser le multicolonne que quelques fois par exemple). Quand à des propriétés comme width: min-content, j'avoue très humblement que j'ignorais même jusqu'à leur existence. Et j'ai enfin compris la propriété will-change ! Bon, vu le support limité de certaines propriétés comme le Grid Layout, pas besoin de s'affoler non plus. :)

Assurément, le parti pris de ne s'intéresser qu'aux techniques modernes de CSS3 fonctionne (pour peu qu'on ne soit pas un total débutant), je craignais un lourd inventaire mais le tout reste agréable et émaillé d'exemples pratiques, ça se lit vite et bien, même si le livre est un bon morceau.

Bref, je ne peux que vous recommander de vous l'offrir et de le lire, c'est assurément l'incontournable de ce début d'année : très complet, précis, pointu sans être inaccessible, c'est un très bon moment de lecture CSS. Félicitations les gars, vous pouvez être fiers de votre bébé.

Le site officiel du livre est là : CSS3, pratique du design web

La connerie a atteint son paroxysme (le 25/03/2015)

J’avais déjà en tête ce billet, même avant que ne surviennent les tragiques événements de Charlie Hebdo. Régulièrement, lors d’affaires d’ados violents, de piratages, et jusqu’à aujourd’hui même, j’entends régulièrement des phrases stupides du genre :

Cet ado avait des armes chez lui, s’est radicalisé, était paumé, et il était sur Internet.

Remplacez « il était sur Internet » par « il jouait aux jeux vidéos » ou par « il s’est auto-radicalisé sur Internet ».

À chaque fois, c’est sur Internet que ça se passe, donc c’est l’endroit terrible, ma bonne dame. Écoutez bien la prochaine fois, vous noterez en général un ton particulier pour « sur Internet ». Et du coup, les politiques de tous bords récupèrent ça et sortent ce genre de phrases :

Nous allons mettre sur la table une question centrale, celle de l’Internet civilisé, je ne dis pas de l’Internet régulé, je dis de l’Internet civilisé - Nicolas Sarkozy

Encore récemment : Manuel Valls a demandé au ministre de l’Intérieur Bernard Cazeneuve de formuler des propositions concernant le contrôle d’Internet et des réseaux sociaux.

Jusqu’à ce matin :

En 2015, Internet offre le visage d’un espace sans foi ni loi, permettant la diffusion du pire de ce que l’humanité a pu produire. Internet favorise l’expression de tous peu importe leur opinion et leur croyance. Aujourd’hui, le pire a atteint son paroxysme - Pierre Charon

Je pose une question : en quoi Internet serait un critère particulier dans un cheminement qui mène à la violence chez un jeune, ou à l’extrémisme religieux ?

Je serais bien tenté de dire une évidence : tout comme énormément de jeunes (et même d’adultes, si si) jouent aux jeux vidéos, énormément de gens vont sur Internet. Il y a une majorité de gens qui jouent aux jeux vidéos et/ou qui vont sur Internet, et jusqu’à preuve du contraire, les jeux vidéos et Internet n’ont pas transformé la moitié du monde en tarés de terroristes.

Je ne suis pas un grand génie de l’histoire, mais il me semble que les extrémistes et la violence n’ont pas attendu Internet pour exister.

Et pourtant je lis ça récemment :

Il y a un antisémitisme que l’on dit historique mais il y a surtout, a-t-il ajouté, ce nouvel antisémitisme qui est né dans nos quartiers sur fond d’Internet, de paraboles, de misère, sur fond de détestation de l’État d’Israël, et qui prône la haine du juif, de tous les juifs - Manuel Valls

Bon, je serais bien tenté de dire que dire que « l’antisémitisme qui prône la haine tous les juifs » est un magnifique pléonasme, c’est effectivement la définition de l’antisémitisme. Je vous remets cette citation en enlevant quelques termes.

Il y a un antisémitisme que l’on dit historique mais il y a surtout ce nouvel antisémitisme qui est né dans nos quartiers sur fond de misère.

Cela sonne différemment ?

Bref, Internet est un endroit non civilisé, de sauvages, de voleurs et qui est une toile à antisémitisme. Notez que je ne dis même pas que l’antisémitisme ou la violence n’existent pas aussi sur Internet.

Qu’on le dise s’il en était besoin : des choses comme l’antisémitisme, le terrorisme ou la violence sont des choses absolument abjectes et indéfendables. Ce qui me gêne c’est qu’Internet y soit systématiquement associé. Imaginons que l’on remplace Internet par la radio. L’idée même de dire que la radio est un lieu non civilisé prêterait à sourire (bien entendu, il faut avoir connu la période des radios libres pour comprendre la saveur de cette phrase…).

Je ne suis pas un expert en radicalisation, mais il me semble qu’en parlant d’Internet avec ce sujet, on charge un moyen, pas la cause. Et j’imagine que les causes doivent être bien plus profondes et complexes. Ces raisonnements sont simplistes voire simplets. Régulons Internet, ça empêchera les gens de se radicaliser. Il faudrait peut-être se poser la question de pourquoi des gens se radicalisent. Au pire, un des moyens (Internet donc) n’est qu’un révélateur d’un mal plus profond.

Vous savez ce qui fait vraiment mal en fait ? Internet est un puissant révélateur en fait d’un gros échec face à ces radicalisations. Internet permet de trouver tout. Et la question qui (me) dérange, c'est pourquoi des gens cherchent ça ? Et c’est bien plus simple pour un politique de dire que c’est la faute à Internet plutôt que de dire… c’est de notre faute.

Internet pour ma part, c’est une part non-négligeable de ma vie. Le Web est mon métier, ma passion, ça m’a grandi et ça m’a rendu meilleur. Par l’apprentissage de l’accessibilité ou la rencontre de gens extraordinaires par exemple. J’aimerais bien ne plus être englobé comme sauvage dans un raccourci fulgurant.

Donc définitivement, politiques de tous bords : c’est votre droit de croire qu’Internet est la source de tous les maux (même si je trouve cela idiot), c’est votre droit de ne pas aimer Internet (même si c’est au moins autant idiot). Mais si vous n’aimez pas Internet, laissez-le au moins à ceux qui aiment ça et surtout à des gens qui le comprennent, cela vous évitera de tenter de le censurer de manière complètement inefficace.

Vous ne comprenez pas le dernier lien ? Voici une métaphore :

Censurer au niveau des DNS, c’est comme enlever un poteau indicateur. Enlever un poteau indicateur n’a jamais empêché celui qui sait où aller d’y aller, et n’empêchera pas celui qui veut trouver un endroit… de le trouver.

Qu’on se le dise…

Positionnement absolu, CSS et « replaced elements » (le 16/03/2015)

Ce matin, j’ai eu un cas un peu bateau qui m’a fait tourner en bourrique pendant une bonne heure. Je cherchais à avoir un button qui prenne toute la largeur de son conteneur parent (qui lui est en position: relative).

Très logiquement, je l’affuble d’un position: absolute et je mets top/left/right/bottom à 0. Logique me direz-vous.

Sauf que cela ne marche pas du coup, et nulle part.

En recherchant un peu et en demandant sur Twitter, j’apprends que certains éléments sont qualifiés de « replaced elements ». En gros, ce sont des éléments dont l’apparence et les dimensions sont définis par une ressource externe. L’exemple typique est l’img (qui a ses propres dimensions), les object (plugins, etc.), mais aussi certains éléments de formulaires, comme les select, les button, textarea, etc. (ce qui peut se comprendre, étant stylés selon les systèmes/navigateurs).

Et des règles assez tordues existent, je vous passe le détail sur les « replaced elements » positionnés en absolu, mais en gros, dans mon cas tout simple du dessus, la spécification indique que la valeur de right sera totalement ignorée (ce qui confirme ce que la démonstration montre).

Ce n’est pas un bug, c’est une feature de la spécification.

Bref, en mettant un width: 100% au lieu de right: 0 dans mon cas, cela fonctionne (voir le pen ci-dessus avec la solution).

Pour en savoir plus sur le sujet :

On en apprend tous les jours avec CSS.

La liberté, je n’avais pas tout compris (le 14/03/2015)

Des fois, il arrive que, quand on entend des conférences, l’on ne réalise pas sur le coup l’importance des choses qui y sont dites. Voici un premier billet sur ce sujet.

À la Kiwiparty 2013, un certain Tristan Nitot présentait une conférence sur Firefox OS, et l’importance de remettre un peu de liberté et de Web dans le monde plutôt verrouillé des smartphones. Même si j’ai énormément de respect et d’admiration pour ce dernier (et je ne m’en cache même pas), pour Mozilla et pour l’initiative même de Firefox OS, j’avoue très humblement que je n’avais pas entièrement réalisé l’importance des concepts dont Tristan parlait.

Autant son discours sur le Web me parlait, étant « OpenWebien » de cœur et de raison, autant la « bidouillabilité»  dont il parle souvent, même si je peux la comprendre par exemple via les styles utilisateurs, sur le monde des smartphones, ça ne m’avait pas fait faire tilt comme on dit (il faut dire que je n’avais pas de smartphone).

Et même, je reconnais que je suis plutôt devenu fainéant de ce côté : autant il y a quelques années je m’intéressais un peu au côté hardware/système, maintenant tout est configuré pour se mettre à jour automatiquement, et ce n’est pas plus mal : cela ne m’intéresse plus, je m’en brosse.

S’il m’arrivait un jour de me rencontrer avec 10 ans de moins, ce serait le choc des cultures sur ce sujet, mon moi d’il y a 10 ans serait probablement furieux et m’insulterait copieusement. Oui, je suis devenu assez paresseux sur ce sujet, il faut dire que je n’ai plus le temps pour cela.

Sauf que récemment, ça a fait « tilt ». Y avait quelques signes avant-coureurs, mais ça n’avait pas tilté.

Je suis l’heureux possesseur depuis Noël d’un smartphone ZTE Open C sous Firefox OS, j’en suis plutôt content (je ferai un billet pour présenter la bête d’ici peu). Connaissant brièvement quelques uns des développeurs de Firefox OS, je me suis un peu intéressé à l’écosystème.

Et j’apprends que la version 2.0 de Firefox OS est sortie, en version stable. J’ai lu des retours plutôt positifs sur cette nouvelle version. Avec d’autres personnes, j’alpague il y a quelques semaines le compte Twitter de ZTE France, pour leur demander si la mise à jour sera proposée pour mon Open C, qui utilisait la version 1.3 si ma mémoire est bonne.

J’attends impatiemment la réponse, elle mit quelques jours à arriver : « pas de mise à jour proposée… mais un nouveau modèle sortira cet été avec ».

Même si je comprends la logique commerciale… très honnêtement, ça m’a foutu en rogne. Clairement, devoir racheter un smartphone alors que le mien est quasi-neuf, moi cela me fait chier. Qu’on ne se méprenne pas, je n’ai rien contre ZTE, c’est grâce à eux que j’ai un smartphone sur Firefox OS, et c’est sûrement ce qui me convient le mieux dans l’offre actuelle (ça aussi, j’en parlerai dans le futur billet sur Firefox OS).

Du coup, piqué au vif (je sortais d’une gastro, je pense que je devais être un peu irritable), je me mets à surfer violemment et à trouver des informations. Il existe des builds communautaires avec la nouvelle version de Firefox OS. Grosso modo, l’idée est de « rooter » le smartphone (prendre les droits « administrateur », root en somme), et d’installer des builds communautaires.

La manipulation comporte des risques, mais je ne fus pas très réceptif aux mises en garde. Je choisis le build dit « bêta », ne souhaitant pas non plus avoir un système trop instable (c’est que je m’en sers de mon téléphone, j’ai besoin que ça marche). La manipulation réussit, et du coup, mon ZTE est désormais en version 2.1.

Firefox OS 2 sur mon smartphone

Du coup, les concepts de « bidouillabilité » et « sans demander l’autorisation » si chers à Tristan Nitot ont pris tout leur sens : j’ai quand même pu obtenir ce que je voulais.

Donc :

  • merci Tristan, même si je peux être long à la détente parfois ;
  • merci dattaz qui met à disposition ces builds et la procédure (continue, c’est génial ce que tu fais) ;
  • et merci aux développeurs de Firefox OS (beaucoup !).

Du fond du cœur.

Note de lecture : la dette technique, par Bastien Jaillot (le 09/03/2015)

J’avais déjà eu le plaisir d’assister à une conférence de Bastien Jaillot à Paris Web sur la dette technique, du coup, j’étais impatient de lire un ouvrage sur le sujet.

Ce livre est édité par la société Wagon 42, le Train de 13H37 si vous préférez :). J’avais déjà eu le plaisir de lire le Petit Précis de Créativité, qui venait aussi de la même gare.

La dette technique, par Bastien Jaillot

Comme toujours, quand on pense dette technique, on pense à une situation d’urgence : en gros il y a le feu à la baraque. Ce n’est pas un hasard si Bastien est surnommé « pompier du code », comme il l’indique dans ce livre.

C’est d’ailleurs ce que je relate dans l’article La dette technique en exemple : un méga-incendie sur lequel il faut intervenir en urgence. Et – si vous lisez un peu entre les lignes – vous remarquerez qu’on traite une maladie (même l’histoire semble plus intéressante du point de vue de la maladie) plutôt que des symptômes.

Et c’est justement le point fort de ce livre : il s’intéresse aux symptômes, au contexte et surtout à l’humain. Cela peut sembler évident, mais la dette technique, cela ne se fait pas tout seul, il faut des personnes pour en produire. Bastien présente le vocabulaire, les différents types de dettes (involontaire, par négligence, assumée, etc.), et explique de manière non dogmatique et très pragmatique les concepts, les conséquences (sur les équipes et les projets), comment prévenir la dette, l’appréhender, la résoudre, etc.

Et au final, on se rend compte que la dette technique est surtout une histoire de personnes : leurs choix, les rigidités dans les projets qui mènent dans le mur (combien de fois ai-je vu cette triste conséquence), les fonctionnalités inutiles, comment une équipe malmenée en vient à produire de la dette, etc.

Son tour de force est d’expliquer de manière hyper-accessible même aux personnes non initiées à ce concept de dette technique, et une fois la lecture terminée, on se dit tout simplement : « c’est tellement évident ce qu’il dit ». C’est évident… sauf que c’est loin d’être évident.

Bref, vous l’aurez compris, je ne peux que vous recommander de lire cet ouvrage, c’est très bien écrit, fluide, léger et ça va à l’essentiel.

Et j’irais même plus loin, en vous invitant à le faire lire (surtout à vos chefs de projet). Assurément un must-read indispensable, du très bon boulot !

Pour trouver ce livre, c’est par ici : La dette technique, par Bastien Jaillot.

Lettre d’une enflure d’intégrateur que tu maudiras, mais à qui tu pardonneras (le 17/02/2015)

Je ne te connais pas, et tu ne me connais probablement pas. Même si tu pourras glaner quelques renseignements sur moi et m’insulter via mon formulaire de contact, je pense que tu ne le feras pas en lisant ce billet.

Sache que ce template que tu dois reprendre, j’y ai objectivement mis toutes mes tripes. Et j’y ai aussi laissé des plumes.

Tu pourrais croire que je n’en avais rien à foutre, et pourtant, je peux t’assurer que j’y ai jeté toutes mes compétences pour le tenir à bout de bras. J’ai même régulièrement pris ta défense, même si on ne se connaissait pas. Je sais que tu te dis que je suis une enflure qui a engendré un monstre à 10 têtes impossible à maintenir et que tu me maudis sur 5 générations minimum.

Laisse-moi te mettre tout cela en perspective.

J’ai été mandaté par un de tes « responsables » pour faire donc le template de <biiiiip>. J’ai senti que, comme dans toute grosse organisation, tout le monde y allait à reculons. Je le comprends et je ne le juge pas : le passage au responsive sur un site aussi complexe, ce n’est pas facile quand il n’y a pas à proprement parler de culture responsive dans ta boîte, et surtout trop ou trop peu de personnes impliquées. Clairement ton responsable avait été lancé dans ce projet parce qu’il en fallait un. Nous l’appellerons « ton chef » afin de faire plus court.

Il a donc fait appel à moi, et quand je dis à moi, je devrais dire à nous. Nous avons guidé ton chef qui était paumé, et qui reconnaissons-le, a été bien content de trouver cette culture responsive qu’il n’avait pas.

Ton chef m’a également challengé, j’ai vu – et c’est tout à son honneur – qu’il s’est intéressé au sujet, il me parlait de pré-processeurs, de frameworks CSS, etc. En bon développeur, je lui ai aimablement expliqué ce que cela impliquait, et cela lui a remis les idées à l’endroit (car bien entendu, il mélangeait tout). C’était principalement en pensant à toi, pour t’éviter que les décideurs viennent expliquer aux techniciens comment ils doivent faire leur métier. Que chacun s’occupe de ses moutons, et les sites seront bien gardés.

Nous avons fait un premier jet (nous aussi, on aime les défis), et cela a dépassé nos attentes et celles de ton chef. Sans aucune prétention, on a envoyé du lourd à tous les niveaux, et ça ton chef l’a compris et l’a apprécié.

J’ai développé tout à la mimine et j’ai insisté pour dissuader ton chef de construire un énième clone de site bootstrap, tu sais, le genre de site « wouhaou » mais qui ressemble bigrement à ses congénères et qui pèse quelques mégas.

Bref, ton chef s’est retrouvé du coup en première ligne sur un projet qui partait avec le soleil devant et le vent dans le dos. Et du coup, comme dans toute grosse organisation, dès que le vent tourne de manière positive, tout le monde monte dans le bateau. Je me permets de te le redire : il n’y a aucun jugement de ma part, les choses sont ainsi.

Et du coup, tout le monde a voulu en être. Et c’est là que c’est parti en sucette. Ton chef a voulu satisfaire tout le monde. Résultat, rien que la page d’accueil était proprement délirante. Trop de contenus, trop de composants, trop de tout. Et ce n’était pas la complexité qui était le pire, mais que tout cela devait fonctionner en responsive. Nous avons bien tiré la sonnette d’alarme à plusieurs reprises, mais ton chef s’est grisé, et il a été poussé par un monstre capable du meilleur comme du pire : la politique.

Si la politique est géniale en sa capacité de donner la direction, elle est aussi capable de faire marcher le monde à l’envers en prenant des décisions irrationnelles.

Je te passe les détails, le projet péchu s’est transformé en monstre de complexité. Tout le monde chez toi y a mis son grain de sel. Et ça a été un festival de fausses-bonnes idées. C’était désespérant de devoir faire un bon en arrière et de re-expliquer 500 fois pourquoi 99% de toutes ces suggestions étaient débiles. Nous avons dû trouver des compromis.

J’ai dû développer des trucs vraiment difficiles. Non seulement ça me faisait mal au sac de faire des trucs délirants (sur le mobile en particulier), mais j’avais encore plus mal pour celui qui allait reprendre, toi en somme. Tu noteras que tout est commenté, rangé, robuste, testé. Par contre, oui, toutes ces petites briques (simples) empilées n’ont rien de simple in fine, spécialement pour toi qui récupère le bébé.

Je ne nous dédouane pas : nous aurions peut-être dû être inflexibles et intangibles, je ne le sais pas. Tout grisé de son aura, ton chef a cru que nos remarques étaient de la fainéantise, et les a clairement ignorées. Tu demanderas à ce dernier pourquoi il a écouté ces fausses bonnes idées au lieu d’écouter ceux dont c’est le métier. J’avoue que je regrette aussi que tu n’aies pas été impliqué, même si je l’ai demandé à plusieurs reprises. Car bien entendu, dans le travail que j’ai fourni, chaque point de détail a son importance. Et vu la complexité dantesque des demandes, l’édifice ne souffre aucune faiblesse ni aucun changement sans une grande prudence.

Bref, toi qui me maudi(ssai)s, maintenant tu comprends mieux pourquoi le travail que tu récupères est aussi complexe : sûrement pas parce que je l’ai souhaité, mais parce que je n’ai pas pu faire autrement.

Grilles, carrés et technique CSS de salopard de platine (le 05/02/2015)

Il y a une petite semaine, j’ai qualifié une technique de grille CSS de « technique de salopard de platine » sur Twitter. Je ne résiste pas au doux plaisir de vous la présenter ! :)

Avant tout troll me disant que c’est n’importe quoi, délirant, pas utilisable à grande échelle ou dans tel cas, mettons au point : je le sais, et je suis même d’accord. C’est un amusement pour un cas donné bien précis, et cela rappelle d’autres bons principes.

Pour les vœux de Prezenz pour cette année 2015, j’ai reçu une petite maquette avec une jolie grille. Le tout prévu pour du 1280 de large, mais devant s’adapter parfaitement en réduisant la fenêtre, et sans utiliser flexbox bien sûr (sinon ça serait trop facile). Particularité : certains blocs doivent être parfaitement carrés.

Page web des vœux 2015 de Prezenz

Comme vous le savez sûrement, chercher à contrôler la hauteur dans une grille est souvent une source d’emmerdes innommables. Il existe bien quelques techniques, comme mettre un padding-bottom en pourcentage calqué sur la valeur de width avec une hauteur nulle, mais je ne les ai pas utilisées.

Le « contexte de production » n’étant pas un simple concept mais une réalité (comprenez moins d’une demi-journée pour faire le tout, tests compris), je décide de me raccrocher à une technique que j’avais utilisée sur la refonte de Prezenz pour faire des blocs qui restent carrés, même en largeur variable.

Grosso modo, l’idée est d’avoir une image de 1px par 1px transparente qui sera étirée à 100% dans son conteneur, ainsi elle dimensionnera ledit conteneur en un carré. Ensuite, le contenu sera positionné en absolu dedans. L’image étant très légère, je l’embarque en Data-URI.

Je passe par une grille en inline-block pour faire les conteneurs, j’utilise ma bidouille pour transformer les blocs en carrés parfaits. Afin de me simplifier la vie, les gouttières principales feront 2% de largeur (pour simplifier les calculs = 32*(3 blocs) + 2*(2 gouttières) = 100%). La gouttière verticale entre les petits carrés devant être la même que les gouttières principales, un rapide calcul me donne 6%.

Problème : l’espacement entre les deux petits blocs et les deux en-dessous doit être le même que la gouttière verticale. Heureusement pour moi, une marge en % est basée sur la largeur du bloc et non sur la hauteur, ce qui résout mon problème en un instant (ça marche aussi avec le padding).

La première ligne est vite vaincue, je positionne les icônes avec un bon vieux top et left à 50% et un margin-top et left négatif égaux la moitié de la hauteur/largeur de l’image.

Problème suivant : le grand bloc en bas à droite est rectangulaire. Qu’à cela ne tienne, je fais la même technique, mais avec une image de 2px par 1px, étirée à 100%. Le rectangle est parfait. Là, je me dis que l’affaire va être vite entendue, même technique pour les deux petits blocs de droite, et on n’en parle plus.

Que nenni !

Les rectangles de gauche dépassent. Sur le coup, je ne réfléchis pas et je ne comprends pas pourquoi cela ne marche pas, après tout, ce sont des rectangles ! En fait, le ratio de ces rectangles n’est absolument pas de 2/1, car la gouttière horizontale vient totalement fausser ce calcul. Bref, après de laborieux essais et calculs (j’étais en mode pressé), je trouve les bonnes dimensions pour l’image transparente (qui sera nommée .img-presque-rectangle histoire d’en rire), et l’illusion est parfaite.

Pour le responsive, ça sera vite réglé : à partir du breakpoint tablette, je linéarise la grille principale. Sur mobile, je linéarise les grilles secondaires. Quelques adaptations vite fait bien fait (à la rache) termineront le tout.

Bien m’en a pris : décision sera prise de réduire le conteneur principal à 960 pixels au lieu des 1280 (l’inté est en em, les valeurs sont en équivalent-em). Une valeur à changer, et le tour sera joué. J’y rajouterai ma touche personnelle.

Jolie technique de salopard, n’est-ce pas ?

Citation du jour (le 04/02/2015)

Faire intervenir votre intégrateur à la fin de la chaine, c’est suicider (à court terme) votre site et votre intégrateur (à long terme).

Faire reposer la réussite de votre projet responsive uniquement sur ses épaules, c’est l’inverse.

Les bonnes résolutions des chefs de projet (le 05/01/2015)

Rions un peu en ce début d’année où il est souvent question de bonnes résolutions : j’ai imaginé ce que seraient les bonnes résolutions… des chefs de projets, enfin de certains chefs de projets.

Je vous invite à rêver d’entendre certains chefs de projets vous dire cela :

  • Je lirai mes e-mails avant de venir te demander quelque chose que tu m’as expliqué en long, en large et en travers via e-mail.
  • Corolaire : j’ai compris que tu étais agacé de répéter exactement la même chose que dans ton e-mail.
  • Corolaire : j’ai compris que venir te demander te fait en plus perdre le fil de ce que tu étais en train de faire.
  • Corolaire : J’ai compris aussi que dire « pas grave, ce n’est pas urgent » ne diminue pas le fait que je t’ai fait perdre le fil de ce que tu faisais. Pire, j’admets que je t’ai dérangé pour quelque chose de pas urgent.
  • Non, je ne ferai plus le piquet derrière toi juste pour regarder ce que tu fais, j’ai compris que c’était pénible de se sentir observé.
  • J’ai compris que les projets qui se gèrent tout seuls sont des mythes. Comme les licornes.
  • Corolaire : peu importe la perfection ou l’adéquation de l’outil utilisé, les licornes restent des mythes. Les projets qui se gèrent tout seul aussi.
  • J’ai compris que si tu me dis « 4 jours » pour faire une tâche, cela ne sert à rien de demander si c’est fini au bout d’une journée.
  • Corolaire : j’ai compris que les 4 jours dont tu me parlais sont une durée et pas un délai.
  • Corolaire : si je viens te rajouter des urgences entre temps, j’ai bien compris que les 4 jours sont incompressibles, donc cela reportera la fin de la première tâche.
  • Corolaire : non, le développeur ne me dit pas cela juste pour être désagréable, mais bien parce qu’il estime que cela lui prendra ce temps.
  • J’ai compris que je devais vérifier un minimum avant de faire suivre bêtement ton travail au client, car j’ai compris que tu n’étais pas infaillible.
  • Non, faire preuve de disponibilité ne veut pas dire « ne plus avoir de vie à côté » !
  • Non, je ne te ferai plus suivre un e-mail sans aucune explication. Promis.
  • Non, je ne mettrai plus un message dans le titre de l’e-mail (en laissant vide ledit e-mail), je sais que c’est très mal élevé de faire ainsi. Juré.
  • J’ai compris que je devais te parler comme à un collègue, et pas en me mettant dans la peau du client casse-pied. Ou alors, je dois t’expliquer que j’anticipe une réaction d’un client.
  • Non, je ne gèrerai plus uniquement quand tout va bien mais bien aussi quand cela va mal. Surtout quand cela va mal. Si si.
  • Je sais qu’il est dur de dire non à un client ou de lui proposer un délai, mais j’ai compris que c’est parfois nécessaire, car il est encore plus dur – comprenez impossible – pour toi de traiter 5 urgences pour « tout de suite ».
  • Non, je n’attendrai pas sur le bon sens des développeurs quand je verrai une incohérence dans le projet, je dois la gérer autant que possible avant qu’ils ne tombent dessus.
  • Non, je ne raconterai plus de bobard délirant à un client en employant des mots techniques au pif.
  • Oui, je peux adoucir un problème vis à vis du client. Mais emballer une merde de papier rose n’en changera pas la nature. J’appellerai un chat un chat, et une merde une merde.
  • Non, changer tout le système utilisé par tout le monde ne se fait pas sur une envie, mais sur des besoins réels.
  • Corolaire : mon besoin personnel de changement est une envie, et pas un besoin réel. Je le traiterai donc comme tel.
  • Corolaire : ce que l’on dit au client (ne pas choisir la solution avant le besoin) vaut pour moi aussi.

Note : c’est de l’humour, nous ne sommes pas parfaits non plus.

Dans le même genre :

Bilan de 2014 (le 04/01/2015)

Ma foi cette année a été plutôt intéressante pour moi. Le site de Röcssti, des réalisations intéressantes (dont bon nombre ne sont pas encore en ligne d’ailleurs), on a enfin dégagé IE7 au boulot, des articles sur pleins de sujets, des idées à faire mûrir, des réflexions, la certification Opquast, etc.

Étrangement, j’ai eu la sensation d’être plus en retrait (j’ai été à moins de conférences que l’année précédente, j’ai écrit moins de billets par exemple), l’objectif était de trouver un meilleur équilibre temps/travail/écriture/etc. Mon compteur d’heures supplémentaires me le confirme d’ailleurs, c’est plus raisonnable cette année.

Et pourtant si je regarde les articles et les nouveautés apprises, je n’ai pas l’impression d’avoir chômé… très loin de là !

Accessibilité

Chaque année, je me disais que je voulais progresser en accessibilité (ce que je faisais d’ailleurs), mais 2014 a été un très bon cru pour ma part. Et je crois que c’est surtout parce que j’ai essayé d’en déployer massivement au travail, pas seulement d’en lire ou d’en saupoudrer.

Comme toujours en accessibilité, il y a des bénéfices induits : pour moi ça a été de progresser avec jQuery.

Si vous me suivez sur Twitter, vous n’avez pas pu y échapper. Mon système de tabs sur Github en est un parmi d’autres. Carrousel, système hide/show, menu déroulant avec sous-navigation, fenêtre modale, etc.

Soyez sûrs que je vais continuer cette initiative de composants accessibles. Pour l’instant, ils en sont au stade fonctionnel mais peu/pas/mal présentés : c’est normal, ils étaient là pour répondre à des demandes au travail, j’avais besoin qu’ils marchent avant tout.

Là pour cette année, je vais tâcher de mieux les présenter et de terminer ceux qui ne le sont pas encore.

Mes observations sur le front

Le front se complexifie. Et à mon humble avis, souvent trop. Avoir 50 000 utilitaires pour soi-disant être future-ready ou ce-que-vous-voulez-ready, c’est très souvent de la masturbation intellectuelle, parfois du sur-armement (pourquoi avoir 10 outils qui couvrent peu ou prou les mêmes besoins ?).

Je suis un peu triste : si c’est super tendance de faire du Vanilla-JS, pourquoi a-t-on encore autant peur de faire du Vanilla-CSS ? Et pourquoi a-t-on peur de faire simple ??? Peut-être par manque de méthodologie.

Je vais le marteler cette année :

  • « simple » n’est pas « simpliste » ;
  • « simple » n’est pas « facile » ;
  • et « simple » devrait être au cœur de nos préoccupations, et peut-être même bien plus que ce que l’on croit.

Attendez-vous à ce que je publie sur ce sujet, ici ou ailleurs.

Pour ma part, je suis plutôt content d’avoir fait entrer des nouveautés en amélioration progressive : ou comment utiliser flexbox sans que les vieux navigateurs n’en souffrent pas, par exemple.

Mes objectifs et mes souhaits pour 2015

Clairement, pour ma part, c’est de terminer/prolonger ce qui a été commencé l’année dernière. Composants accessibles, articles, etc. Le site de Röcssti va avoir sa version anglaise, et ce site pourrait avoir une refonte conséquente si les quelques idées qui me trottent en tête prennent forme.

D’autres sujets que j’ai déjà abordés pourraient se prendre un petit coup de jeune.

Une envie qui me titille depuis longtemps pourrait peut-être enfin déboucher : enseigner. À suivre.

Côté souhait : qu’on revienne enfin les pieds dans la glaise. Qu’on se préoccupe des bénéfices pour l’utilisateur avant de ceux pour le développeur. Rien ne vaut un bon « Back to basics ». Des signaux que j’ai vus en 2014 montrent clairement que si ce n’est pas nous qui le faisons, ce seront d’autres qui se chargeront de nous le faire faire (Google en tête).

Je suis l’heureux possesseur depuis Noël d’un smartphone sous Firefox OS, je compte bien parler de ce système, et diantre : qu’on remette du Web dans nos téléphones !

Sinon… hé bien je ne planifie pas trop, justement pour le plaisir de pouvoir écrire et donner un coup de main sur des projets, au gré de l’eau, sans contrainte. Les idées ne manquent pas, j’en ai toujours à profusion.

Touch events et contenus cachés au survol (le 01/01/2015)

Sur le dernier site que j’ai mis en ligne, j’ai eu un petit souci sous les iPad et autres iPhone à cause d’un comportement tout bête : quand on survole un des liens de la navigation principale du site Arcora, un petit élément apparait pour signaler le lien.

Survol de la navigation principale du site Arcora

Rien de bien méchant, cet élément .navigation-redhover est caché par défaut et je le fais apparaitre au :hover. Sauf que sur iPad et autres iBidules, ce genre de comportement va s’effectuer ainsi si on fait un « tap » sur le lien :

  1. on fait un « tap » sur le lien ;
  2. cela affiche le lien en état hover ;
  3. et il faut faire un second « tap » sur le lien pour l’activer !

Ce qui est particulièrement casse-pied dans ce cas-là : devoir faire deux « tap » à la suite pour activer un lien d’une navigation principale, c’est pénible et contre-intuitif au possible pour un utilisateur lambda.

Sans trop le savoir, même si j’avais déjà constaté ce comportement à l’époque, c’est ce que je déclenchais sur le site de CSM avec l’effet de survol sur les portfolios. Sauf que dans ce cas, ce comportement ne me dérangeait pas, bien au contraire ! Dans ce cas, comme il y avait pas mal d’informations à afficher, je trouvais le comportement plutôt adapté.

Survol d’un élément sur le site CSM

C’est plus ou moins expliqué dans la doc Apple sur les événements.

En clair, si nous sommes sur un lien, et qu’il y a un changement de contenu sur un « tap » (un contenu qui apparait dans mon cas), il n’y a pas d’événement propagé (il ne se passe rien en somme), même sur un lien tout ce qu’il y a de plus standard. Cela peut se comprendre, cela évite de faire perdre une information potentielle aux utilisateurs. Ceci dit, dans mon cas, c’est plutôt fâcheux.

Côté solution, il n’y en a pas des milliers :

La seconde solution ajoutera une classe touch ou no-touch sur l’élément html. Et du coup, l’effet de hover sera à activer seulement si on a la classe no-touch (autrement dit, à rendre visible que dans ce cas), via :

.no-touch .navigation-link:hover .navigation-redhover {
display: block;
}

Ce n’est pas parfait, mais cela évitera quelques tracas sur des tablettes et autres smartphones.

Je suis Certifié Opquast ! (le 23/12/2014)

J’ai eu le plaisir il y a une semaine de passer l’examen Opquast Certified.

Opquast Certified

Décidé sur un coup de tête, je m’inscris un soir au travail. Les mails de confirmation donnent le ton : on parle bien d’un examen sérieux (convocation, pièce d’identité à fournir, etc.), et je retrouve l’ambiance des exam’s ! Mélange d’excitation et d’un léger stress positif, je décide de mettre toutes les chances de mon côté : je relis rapidement – mais avec plaisir – pendant deux soirées la version électronique du livre « Qualité Web », fournie pour le passage de la certification.

J’avais lu le livre il y a un certain temps déjà (un peu plus de 2 ans), ce petit rafraîchissement rapide me confirme que le référentiel Opquast est globalement toujours aussi solide, relire certaines bonnes pratiques fait écho à certains de mes derniers projets.

Arrive la matinée de l’examen, je suis au calme chez moi, prêt à démarrer. La plateforme mise en place me surprend en bien : chaque détail est bien pensé, les informations sont claires, c’est ergonomique. J’apprécie particulièrement l’option « revenir plus tard » qui permet de mettre en orange la question dans la liste.

L’accessibilité n’est jamais loin : mon examinateur – un certain Laurent Denis – a son micro qui n’a pas voulu marcher. Comme je ne suis pas habitué à Skype, nous devrons communiquer pendant 3 mn avec la caméra mais sans le son, je me suis dit que ça serait très drôle de le faire en langage des signes (ce qui aurait été cocasse, vu que Laurent est une des personnes qui m’a énormément appris sur l’accessibilité du Web), mais heureusement nous utiliserons l’option pour chatter avec la caméra, ce qui rendra la discussion plus facile ! :)

La discussion sera de courte durée, car nous sommes là pour du sérieux avant tout, la certification !

Bien évidemment, je ne vous dirai rien de l’examen. L’heure et demie ne sera pas de trop. En bon soldat, je me suis mis en mode « pêche aux points », c’est-à-dire pas de perte de temps inutile sur une question. L’objectif est de faire le meilleur score possible. L’examen évite l’écueil du « par cœur » bête et méchant pour des questions très variées et intelligentes, mon crâne a tourné à plein régime, certaines questions m’ont même bien surpris !

Et au final, je pensais avoir un score correct, mais pas à ce point ! La plateforme m’indiquera tout de suite mon résultat, largement au-dessus de mes espérances : 950 points sur 1000 possibles. Laurent Denis en rajoute une couche en me disant que c’est le meilleur score toutes catégories confondues ! J’en suis ravi, et je me dis que ces 10 années à utiliser et à m’approprier la qualité web viennent de se voir enfin de manière indiscutable. C’est le plus important pour moi, bien plus que le score (même si je ne boude pas un bon 9,3 à Opquast desktop sur une mise en prod non plus). Ce qui sera d’ailleurs indiqué à l’Opquast Day à Paris quelques jours plus tard.

Autre plaisir, mais plus personnel, comme je finis l’année de manière mouvementée, manifestement cette cerise sur le gâteau fait du bien, et je ne boude pas mon plaisir !

Quoi qu’il en soit, je suis bien content que le domaine voie arriver des certifications comme celle-là : ce sont des gages de sérieux donnés par des tiers indépendants. Si en matière de recherche en marketing, c’est ESOMAR et le ICC/ESOMAR Code qui dictent les bonnes pratiques, en matière de qualité web, Temesis a tout ce qu’il faut pour faire autorité. Il m’arrive d’ailleurs régulièrement quand je parle d’un plugin ou d’un site de dire que je « travaille aux standards Opquast ». Tout est dit.

Bien entendu, j’espère bien ne pas m’arrêter en si bon chemin. Mais ce sera sûrement pour l’année prochaine ! :)

Le monde « connecté » et le monde « réel » (le 15/12/2014)

À l’approche des fêtes de fin d’année, je constate une très étrange dichotomie entre ma vie numérique et ma vie analogique, ma vie réelle si vous préférez.

Si vous avez la chance de vivre avec des gens qui ont les mêmes centres d’intérêts que vous ou moi, ils suivent peut-être vos élucubrations sur les réseaux sociaux et/ou autres blogs. Moi clairement, ce n’est pas mon cas. Ou alors très très peu. Pour la plupart de ma famille par exemple, mon métier et mes centres d’intérêts liés sont une boite noire impénétrable.

Là je suis au travail, et je me surprends à adorer écouter sur Youtube un concert de Huun-Huur-Tu. Ce groupe joue avec maestria de la musique traditionnelle Touvaine (une culture régionale mongole). Ces morceaux me transportent littéralement.

Étant connecté, je me dis que Google va savoir d’une manière ou d’une autre mon intérêt pour cette musique. J’ai dû twitter le lien, j’ai fait « +1 » sur Youtube (afin de retrouver ce lien, encore un plus pour Google), il ne me suffirait plus que d’aimer la page Facebook pour compléter le tableau, si j’ose dire.

Par contre, vous vous doutez bien que si je ne dis pas à mes proches que j’adore la musique de ce groupe, ils n’en sauront probablement jamais rien. Et ils auront sûrement du mal à s’en douter… à la base, je n’ai pas grandi ni baigné dans la culture Touvaine.

Vous ne trouvez pas cela bizarre ? Je me dis que Twitter/Google/etc. savent des choses sur moi que mon propre entourage ne sait pas et ne saura probablement jamais (sauf si je leur dis expressément, et encore, ça peut facilement rentrer dans une oreille et ressortir aussi vite par l’autre).

Clairement, cette dichotomie m’interpelle.

L’« angoissant » sujet de la veille technologique (le 05/12/2014)

J’avoue être surpris d’entendre de plus en plus de la part de débutants (et de moins débutants) que la veille technologique devient un sujet angoissant voire anxiogène pour eux.

Certes c’est un sujet important : se tenir à jour est important voire vital dans nos métiers. Mais de là à en faire un sujet anxiogène, non, pas d’accord. Je vais même vous montrer comment – en ignorant plein de trucs – j’organise ma veille et que cela reste un plaisir.

Mes sources de veille

Twitter

Mon principal vecteur de veille au quotidien est Twitter. À l’instant où j’écris, je suis 280 comptes, et c’est relativement stable depuis un an ou deux. Je n’ai jamais utilisé les listes ou des systèmes comme TweetDeck, j’utilise juste la version web et l’application iPad (et je n’en ai jamais été malheureux). Je ne suis toujours pas arrivé à comprendre comment font ceux qui suivent plus de 1500 comptes sans devenir dingues.

Parmi ces 280 comptes, il y a :

  • des gens reconnus pour leurs compétences ;
  • des super techniciens ;
  • des gens avec qui j’aime bien discutailler ;
  • des gens que j’aime tout simplement bien ;
  • et des comptes qui n’ont rien à voir avec la veille technologique, juste pour se détendre l’esprit.

Un point clé : le nombre de followers n’est pas un critère pertinent pour la qualité d’un twittos. Qu’on se le dise ! Je suis quelques perles dont je ne raterai pour rien au monde le moindre tweet, et ils n’ont pas un nombre élevé de followers.

Même si on entend souvent que Twitter n’est pas fait pour discuter, c’est pratique pour appeauter des gens pour avoir rapidement un avis sur un truc.

Les conférences

J’aimerais bien en suivre plus, mais les contraintes de la vie réelle ne me permettent pas toujours de faire tout ce que je veux. :)

C’est un excellent vecteur de rencontres : souvent ces rencontres rebondissent, donnent des idées, font des petits et donnent la patate. L’effet « Paris Web » comme on l’appelle dans les milieux autorisés en est un très bon exemple. Comme c’est un instant ponctuel, l’esprit est là pour cela et pour rien d’autre.

Les articles, newsletters, bouquins et autres blogs

J’ai une grosse trentaine de fils RSS que je suis, pas plus. La syndication a un immense avantage : c’est asynchrone ! Pas besoin de suivre un flux en continu et aucun risque de perdre de l’information. Idem pour les newsletters, je suis particulièrement fan de celle d’Opquast : forte valeur ajoutée et rythme facile à suivre.

Et j’aime bien lire un bon bouquin, je fais d’ailleurs des notes de lecture ici assez régulièrement.

Comment ne pas devenir dingue ?

Choisir ses sources

Je me trouve des sources qui me correspondent, autant côté personnalité que côté niveau. Cela ne sert à rien de suivre un expert qui ne raconte que des trucs hyper-avancés sans les vulgariser si je suis un débutant dans le sujet : je ne vais rien comprendre à ce qu’il va dire. C’est d’ailleurs aussi pour cela que je milite activement pour avoir des articles accessibles, et pas uniquement pour les super-experts avancés.

Un autre critère, plus personnel : je lis très difficilement quelqu’un qui est bon mais abject humainement parlant. Le savoir-être n’est pas une lubie de ma part, mais bien un critère important. Si dans le Web, j’aime bien les bonnes pratiques, dans l’humain, j’aime bien les bonnes manières.

Ne cherchez pas à suivre les héros du Web de quelqu’un sur cette unique raison. Les héros ne sont pas éternels, vos héros ne seront pas les miens et c’est très bien ainsi. Cela évitera en plus à certains de prendre le melon.

Le choix de ce qui est critique ou pas

Là c’est un point critique : priorisez ! Comme je le disait dans le billet de Raphaël : utilisez le principe de réalité. Par exemple, je sais qu’il existe un module CSS3 nommé Grid Layout. J’ai entendu que c’était pas mal. Mais :

  • aucun projet ne l’a nécessité actuellement ;
  • et son support est très faible.

Du coup, à quoi bon se stresser pour l’apprendre et le maîtriser ? Puisque de toutes manières, ça sera inutilisable en production. La seule chose, c’est de savoir que ça existe.
C’est un travers donné par de nombreuses personnes qui ne peuvent s’empêcher de bloguer sur la dernière nouveauté : ok c’est bien, ça participe à la culture générale, ils sont des précurseurs, tant mieux pour eux… mais pratiquement, je m’en fous un peu, même si ça n’est pas inintéressant.

Par contre, ça ne m’empêche pas parfois de passer en mode « je me sors les pouces » car j’estime que je suis trop à la bourre sur un sujet. Quand la performance a commencé à devenir un sujet très sérieux, je n’ai pas ménagé mes efforts pour rattraper le gros retard que j’estimais avoir (c’était en 2009/2010, j’en ai bouffé de la performance à cette époque pour me remettre à niveau…).

En mode déconnecté

Ne vous privez pas de fonctionner en mode asynchrone. Suivre en continu un flot d’information incessant est fatigant. RSS, les newsletters, etc. sont bien plus cools à suivre. J’use et j’abuse du bouton favori de Twitter, qui devrait s’appeler « à lire plus tard » justement pour ne pas passer trop de temps en mode connecté.

Dites-vous bien que si vraiment un article majeur sort, il y a tellement de gens qui vont en parler que vous ne risquerez vraiment pas de le louper. Et vous connaissez le cycle sur Twitter :

  1. « Cette techno est si extraordinaire que j’en parle »
  2. « C’est tellement génial, que vous êtes un minable si vous ne l’utilisez pas déjà  »
  3. « Heu, attendez les gars, y a quelques problèmes là ! »
  4. « Il faut prendre du recul sur cette techno. » (parfois par le même qui a dit le point 1 et 2 ci-dessus)

Sautez directement à l’étape 4. Ne manquez pas de recul. Voyez les conditions limites d’un choix. Et cela ne vous empêchera pourtant pas d’avoir l’enthousiasme de la découverte de la nouveauté… mais sans frustration.

No stress

Il y a des tonnes de choses dans lesquelles je ne suis pas à l’aise ou même monstrueusement ignorant. Je pourrais en faire la liste (Node-JS, Drupal, Git, etc.), mais je pense qu’elle serait si longue que vous auriez le temps de mourir au moins trois fois en la lisant.

Si vous vous inquiétez de ce que vous ne savez pas, dites-vous bien que personne ne peut tout savoir. Même chez les experts, et surtout chez les experts. Selon moi, la veille doit être tout sauf anxiogène : c’est une hygiène de vie, il faut donc y trouver son plaisir. Un peu comme le régime alimentaire : si vous n’avez aucun plaisir à suivre un régime particulier, vous finirez tôt ou tard par revenir aux mauvaises habitudes…

D’ailleurs, j’ai entendu une remarque assez amusante à Paris Web cette année : « vous parlez de qualité, etc. Mais en fait tout cela se met encore en place ? ». Hé oui, parler de sujets ne veut pas dire qu’on en a fait le tour, les orateurs ne savent pas tout, désolé. C’est évident quand on y réfléchit, mais pas tant que cela. Et dites-vous bien que ces choses sont progressives, tout comme la veille.

L’idée c’est d’avoir une vision cohérente. À quoi bon connaitre toutes les spécifications CSS si je ne connais même pas les bases de l’accessibilité ou de l’HTML ? En tant que développeur de navigateur, ça peut me servir, mais en tant qu’intégrateur/dév. front…

Voila, je crois avoir fait le tour… ah non, j’oubliais un point capital !

Que trouverai-je dans cette grotte ? Ce que tu vas y apporter.

Hé bé oui, la veille, c’est aussi ce que vous (en) faites. Ce que vous produisez. Vos réalisations. Vos projets. Les projets auxquels vous participez. Et ne croyez pas que cela se résume à l’utilisation d’une propriété donnée ou juste à faire des commits (bref, à pondre du code). Ceux qui vous disent ça sont soit des andouilles ou n’ont rien compris. Le code est un moyen, pas une finalité.

Expliquer pourquoi vous avez fait ce choix, le partager, échanger dessus est au moins aussi important, ça montrera qu’il y a un esprit derrière ces mains qui codent (ou ces pieds, mais c’est plus rare). Et surtout en faisant ainsi, vous ferez la veille de quelqu’un d’autre. Vous améliorerez votre vision d’un sujet. Dites-vous bien que si vous vous êtes questionné sur un point, il y aura forcément quelqu’un qui sera dans le même cas que vous. Et cette personne vous dira merci.

Comme Élie Sloïm et moi-même l’avions indiqué à Paris Web : le savoir-faire c’est bien, mais le faire-savoir, c’est pas mal aussi.

Les variations entre la maquette et le site (le 01/12/2014)

Chers clients, je comprends votre obstination à ce que votre site ressemble le plus possible à la maquette que nous vous avons présentée. Je dis cela sans aucune moquerie ni méchanceté.

J’imagine que vous croyez que le développeur est un fainéant, que le chef de projet n’a pas vérifié ou que nous négligeons d’une manière ou d’une autre votre site. Hé bien, laissez-moi vous prouver le contraire. Et pour ce faire, je vais prendre mon propre site d’agence, celui donc de Prezenz qui a été refondu l’année dernière, histoire de ne rien vous cacher.

Je vous vois mal me dire qu’on néglige notre propre site d’agence, surtout lors d’une refonte. Nous avons fait exactement comme pour vous :

  • Wireframes ;
  • Maquettes ;
  • Système de gestion de contenu ;
  • Etc.

Comme nous ne sommes pas trop mauvais, nous avons essayé de tout anticiper : les différents formats (tablette portrait, paysage, grand écran, petit écran, etc.), comment le contenu allait s’afficher, etc.

Et pourtant, je peux vous assurer que je n’ai pas fait exactement ce qui a été demandé, et sans pour autant avoir fait d’erreur ou de caprice de développeur front cabochard ! Au hasard :

  • J’ai modifié légèrement certains breakpoints (même parmi les principaux) qui se déclenchent plus tôt ou plus tard quand on redimensionne ;
  • Le menu ne s’affiche pas du tout comme demandé sur tablette en mode portrait ;
  • Certaines coordonnées sont volontairement différentes ;
  • Etc.

Vous voyez, même pour nous, nous avons des différences entre la maquette et le site final ! On ne vous mentait pas, cela nous arrive aussi ! :)

Tout simplement, il y a certains points absolument impossibles à anticiper, petit bestiaire non exhaustif :

  • En faisant le gabarit de base, j’ai trouvé une meilleure solution que celle de la maquette (le cas du menu sur tablette cité plus haut, j’ai réussi à l’adapter sans ce saut à la ligne) ;
  • Le contenu « réel » dicte ses contraintes : par exemple, le menu de droite a un texte un peu plus long que prévu, ce qui m’a forcé à déclencher un breakpoint plus tôt pour respecter le mieux possible la maquette ;
  • Tout simplement certaines choses ne fonctionnent pas : le menu à 6 entrées (qui se met sans problème sur 3 et 2 colonnes) n’en a que 5 dans certains cas… et 5, c’est difficilement divisible par 3 ou 2 pour faire des colonnes (les demi-colonnes, ce n’est pas possible, désolé) ;
  • Il m’est aussi arrivé d’avoir à pousser/adapter certaines dimensions pour certains contenus, car cela ne fonctionne pas bien en responsive (contenus trop entassés, etc.). Idem si des contenus viennent du système de gestion de contenus, si un navigateur n’en fait qu’à sa tête, etc.

Et quand on y réfléchit… qu’est-ce que vous pouvez en avoir à faire si un breakpoint s’effectue à 800 pixels au lieu de 770 ? Ce qui est important, c’est que le site soit toujours le plus agréable pour ses utilisateurs, non ?
Et quel est le problème si les longueurs varient très légèrement, tant que la grille est respectée ?

Dites-vous bien que concevoir un site non trivial en responsive, c’est un jeu d’équilibriste, pas une science exacte. Il y a une citation que j’aime bien qui résume le tout :

Designing for the Web is like visualizing a tesseract. We build experiences by manipulating their shadows. — Tim Brown

Traduction expresse : concevoir pour le Web est comme visualiser un tesseract (un cube à 4 dimensions), on construit une expérience en manipulant ses ombres (nous ne pouvons voir que 3 dimensions).

Rassurez-vous, avec l’expérience, ces soucis s’anticipent de mieux en mieux, et on évite les grosses impasses ! Mais globalement, c’est proprement impossible de faire une maquette parfaite, il y a toujours un impondérable.

Si je ne peux vous donner qu’un seul conseil, lâchez prise sur ce genre de détails. Si le développeur front a fait ainsi, vous pouvez demander, mais il aura sûrement une excellente raison d’avoir fait légèrement différent. D’expérience, les sites qui fonctionnent le mieux sont ceux où l’on a laissé le développeur front faire ce qui était meilleur pour le site, pas pour satisfaire une maquette.

Pour conclure : Non, ce n’est pas grave qu’il y ait quelques variations entre la maquette et le site, c’est même normal et plutôt un bon signe : l’équipe qui s’en occupe n’est pas bornée et s’adapte à la réalité du projet.

Le vrai défi de la qualité Web (le 14/11/2014)

J’ai de plus en plus tendance à comparer la création de sites à un sport de haut niveau : pour atteindre l’excellence et faire un podium olympique par exemple, ce sont des heures de travail, de pratique, une hygiène irréprochable, un mental, de bonnes conditions, etc.

Je ne sais pas si vous avez déjà discuté avec des athlètes de haut-niveau, mais ils le disent tous : atteindre un tel niveau est un sacré challenge. Mais pour ceux qui l’ont atteint, ils vous diront également tous la même chose : le vrai défi, une fois la médaille obtenue est de se remotiver pour y retourner.

J’entends souvent sur la qualité Web que faire un sans-faute sur une checklist est un défi. Certes, selon la taille et la complexité de votre checklist, cela peut l’être. Vous avez sûrement une fois fait un site où vous aviez la banane, la rage au ventre, un mojo en mode Hulk, les conditions s’y prêtaient bien et vous avez fait un « perfect » ou presque (genre un 9,5/10 sur Opquast Desktop et les 0,5 restants sont des mises en garde). Et c’est bien !

Là, tout béat d’admiration (la fatigue fait cela aussi), vous étiez tout content. Et puis le projet suivant est arrivé.

Et probablement, vous aviez moins le mojo, Hulk est redevenu Bruce Banner, etc. Les mauvaises habitudes ont repris le dessus, ou même vous n’aviez pas la même énergie à dépenser ?

Voilà à mon sens le vrai défi de la qualité Web : une fois arrivé au top, comment le refaire ? Ou si vous préférez : une fois arrivé au top, comment s’y maintenir ?

Car dépenser beaucoup d’énergie, ça se fait. Vous avez tous déjà piqué un monstre sprint, vous êtes arrivé le coeur à 200 pulsations/minutes, mais vous y êtes arrivé. Par contre, vous vous doutez bien que piquer tout le temps des sprints, ça va vous mettre durablement dans le rouge. Là, vous rentrez dans un objectif bien différent. Ce n’est plus l’atteindre, mais vous tenir au top.

Regardez dans votre vie, vous avez des millions d’exemples. Le régime qui fait perdre beaucoup, mais qui fait tout reprendre après. Le grand nettoyage de printemps, mais qui va être annulé en moins d’une semaine. La folle soirée où vous avez mis le paquet pour séduire quelqu’un, mais le lendemain vous avez la tronche de travers. Etc.

Là, vous allez devoir :

  • Mettre en place les conditions qui vous ont fait atteindre le top ;
  • Casser les mauvaises habitudes qui vous en éloignent ;
  • Lutter contre la facilité ;
  • Travailler l’excellence mais sans dégager une énergie colossale ;
  • Probablement faire tout cela avec une équipe ;
  • Etc.

Quand on vous dit que cela prend du temps, ce n’est pas pour se donner un genre : ça prend réellement du temps. C’est même un travail constant.

Un vrai défi en somme !

L’intégration se regarde le nombril ? (le 14/11/2014)

Un billet très intéressant chez Raphaël Goetter sobrement appelé « Introspections technologiques » m’inspire celui que vous être en train de lire. Ce dernier explique son sentiment mitigé envers cette course à l’armement qui se passe actuellement en intégration et plus largement dans le front-end. Frameworks, pré-processeurs, post-processeurs, automatiseurs, etc.

Je pourrais expliquer mon avis sur le sujet, mais en fait, je l’ai déjà abondamment fait dans un commentaire. Cela vous fera deux excuses pour aller vite lire ce bon billet.

En fait, je m’interroge plutôt sur le pourquoi de cette course à l’armement. J’ai une idée sur la question.

Comme on le dit, pour comprendre son présent, il faut aller chercher dans son passé. L’intégration a longtemps été le dernier maillon de la chaine, la cinquième roue du carrosse, bref, appelez ça comme vous voulez. Aujourd’hui, avec le responsive, les performances, l’accessibilité, etc. qui concernent le front-end, on remarque une certaine revalorisation de ce métier. Qui n’a jamais entendu de moqueries sur du JavaScript il y a 10 ans ? Ou sur CSS ? Et même encore maintenant même si c’est devenu plus rare (vous oseriez vous moquer d’un bon développeur JavaScript ? Moi pas).

Je pense pouvoir dire que ce domaine a même pris une certaine honorabilité. À juste titre, il y a eu un appel d’air assez formidable et la complexité a fait des bonds de géant. Tellement de choses passent par le front-end. Je vis des situations proprement impensables il y a dix ans. Pour ne donner qu’un exemple : je suis régulièrement sollicité pour exécuter des intégrations, et les domaines qui gravitent avec (back-end et graphisme par exemple) écoutent ce que j’ai à dire et plient à mes volontés. Ce qui ne se serait jamais vu il y a dix ans : on m’aurait dit de fermer ma gueule et de faire exactement comme le graphiste ou le back-end a dit.

Notez que je ne suis pas là pour dire qu’un poste est plus important que l’autre. Je constate un rééquilibrage, plutôt sain d’ailleurs. Le domaine subit en prime d’énormes mutations.

Du coup, l’intégration qui n’a jamais pu se regarder le nombril… se le regarde enfin depuis quelques années. En sont sortis des outils, des méthodes, des approches purement « intégrationnelles », si vous me permettez ce néologisme. Même si – en toute honnêteté – on n’invente pas l’eau chaude ainsi (la conception objet n’est pas née avec OOCSS), on recrée des choses pour l’intégration et uniquement dans ce but.

Je ne dis pas que se regarder le nombril est mal : le domaine en a besoin et c’est normal qu’il réagisse ainsi. Il a besoin de créer ses codes (son code !), de trouver ses repères, de grandir, etc.

Ajoutons à cela qu’avec l’appel d’air évoqué plus haut et le côté tentaculaire du Web, cela ne peut que partir dans tous les sens. Nous sommes dans une grande phase d’exploration, avec ses excitations, ses frustrations, ses erreurs, etc. Seulement, Raphaël Goetter pose bien la question qui tue : quid de la pérennité de tout ce foisonnement à l’avenir ?

J’avais – peut-être pas aussi adroitement que je l’aurais souhaité – essayé de le faire comprendre lors d’une intervention l’année dernière à Paris Web : l’intégration se trouvera une voie en arrêtant de se regarder le nombril, en allant voir ce qui se passe autour (vers 13mn 30s dans la vidéo). En servant des objectifs autres que les siens : la qualité, les utilisateurs, etc.

Certains le font très déjà très bien : regardez l’intervention de Kaelig à Sud Web Mieux communiquer avec son équipe grâce à Sass. Il utilise un outil pour permettre à divers intervenants de mieux se comprendre et de mieux travailler ensemble.

Que ce soit clair : les notions de passé, présent et futur sont très relatives, ce n’est pas linéaire. Il y a des périodes où il faut savoir se regarder le nombril pour ne plus avoir à le faire ensuite, et pour y revenir.

Mais cela n’est et ne doit jamais être un but en soi. L’intégration ne doit pas commettre les mêmes erreurs qui ont été commises à son encontre.

Retour sur la conférence « Qualité Web : l’heure de passer à la caisse » (le 07/11/2014)

Si dans le billet précédent, je parlais du plaisir d’avoir été spectateur à Paris Web cette année, un bon billet s’imposait sur cette conférence, beaucoup de choses à en dire. On dit qu’une histoire a trois façons d’être racontée : vue de l’extérieur, vue des personnes et vue personnelle.

Je vous laisse deviner quelles façons je vais utiliser, car bien entendu je vais me faire un plaisir d’utiliser les trois.

Mon parrain de qualité

Revenons dans le passé, à trois ans. La Delorean vous aura transporté à Paris Web… 2011. C’est ma première édition, j’en ai beaucoup entendu parler, mais je ne m’étais pas décidé à y aller, c’est désormais chose faite. Ma première conférence sera celle d’Élie Sloïm et de Laurent Denis, qui parlaient d’accessibilité agile. J’avais beaucoup aimé ce que ces deux gars racontaient et de la façon dont ils le racontaient. En se renvoyant la balle, en causant du vécu et en allant au final bien plus loin, pour peu qu’on lise entre les lignes.

Si Monique Brunel est mon incontestable marraine de Paris Web (c’est elle qui m’a fait découvrir ce petit monde), Élie en est mon parrain. Ajoutons à cela qu’il s’occupe d’OpenWeb, qu’il est « redoutablement diplomate » et qu’il fait partie de ces gens qui sont très rarement à côté de la plaque, alors je ne peux que l’admirer. Du coup, je me dis qu’on a plus ou moins « une certaine vision » commune de la qualité Web, alors si on tentait ?

La préparation

Le moins qu’on puisse dire, c’est que nous sommes passés par tous les états durant la préparation de la conférence.

Stress car emplois du temps bien pris de chaque côté et la date qui ne recule pas, énervements (nous fonctionnons de manière assez différente, ça a fait des étincelles par moment quand on s’en est rendu compte !), grandes joies quand nous avons franchi des caps durant la préparation (les idées qu’on fait rebondir et qui nous emmenerons plus loin que prévu), balle qu’on se renverra… le chemin a autant été enrichissant que semé d’embûches.

J’adore les personnes qui sont capables de me résister et de me canaliser. Pas juste pour le plaisir de troller (ce que je déteste), mais pour étendre mon champ des possibles. Perso, je suis plutôt du genre gladiateur qui fonce dans l’arène, Élie est beaucoup plus réfléchi. Il pense global, je pense détails et enchainements logiques (le métier d’intégrateur qui met de l’huile partout dans les projets ressort). Ma grosse peur : que le duo ne fonctionne pas et que l’on s’annule. Du coup, Élie trouvera la solution : je serai à contre-emploi pour l’exemple (ce chef de projet qui nie l’évidence est mon total opposé, un vrai rôle de composition pour moi), et je n’aurais qu’à me laisser guider, Élie étant un excellent orateur.

Nous répéterons durant deux semaines, sans arrêter de modifier, d’améliorer, d’élaguer. Je ne sais pas combien d’heures nous y avons passé, mais un paquet. La veille de Paris Web, nous remanierons encore l’introduction, toujours sur ses bons conseils. Je lui glisserai un petit « ne me ménage pas quand je ferai le chef de projet, tu es trop gentil… sois féroce ».

L’heure de passer… sur scène

Bon, on ne va pas se le cacher, ouvrir le bal à Paris Web, on était un peu tendus. Pas qu’un peu en fait. Ceci dit, la salle était chaleureuse, je m’y suis senti bien. Nous attendions, la salle vide, puis deux personnes sont entrées. On s’est dit ouf, on ne sera pas seuls.

Nous ne tenions tellement plus en place que nous nous sommes mis à faire les hôtesses d’accueil, nous allions saluer les personnes qui rentraient. La salle se remplira petit à petit, et au final, une grosse vague arrivera, et la salle sera comble, pour notre plus grand bonheur. Arrive le moment de se lancer, et c’est parti.

L’heure de passer à la caisse

J’espère vraiment que nos messages sont passés. N’hésitez pas à nous en parler, en bien ou en mal, peu importe, mais les retours ça enrichit.

Certes nous avons mis en scène un exemple de manière comique, mais croyez-moi, les petites gamelles qui font très mal, c’est du vécu, je n’aurais pas pu les inventer.

Ce que je constate, c’est que ces petites erreurs aux grandes conséquences font de plus en plus mal. Autant sur les personnes (le moral, l’estime de soi, la frustration) que sur le business (image, etc.). Peut-être même encore plus sur les personnes d’ailleurs : le business, l’argent, c’est important, je ne vais pas le nier : ce sont des métiers de plus en plus pointus sur un secteur de plus en plus compétitif. Mais au final, la personne et son bien-être dépassent cela. Ce chef de projet que j’ai interprété qui nie qu’il est en train de crever à petit feu n’a pas de vision à long terme, il n’a aucun avenir, il n’y a rien de pérenne à fonctionner ainsi, tout juste bon à finir bardé d’ulcères.

Je crois que ces galères de coûts de non-qualité et l’usure sur nos corps et nos esprits sont trop souvent sous-estimées. Tout cela, ce n’est pas une vision durable. Car c’est bien le but de la qualité Web : pérenniser notre écosystème.

Une remarque nous mettra la puce à l’oreille durant la préparation : au lieu de se poser la question de comment éviter/gérer un client chiant, qu’est-ce qui fait qu’un client est génial ? J’ai repensé pour ma part à mon client préféré, et la conclusion était évidente : il ne discutait pas la qualité Web, car il l’a comprise. Vous devriez faire cet exercice, pensez à votre client préféré et demandez-vous pourquoi il l’est.

Et je peux vous dire qu’on n’a pas fini d’en parler, de cette compréhension de nos clients.

Achievements unlocked

Pour ma part, très très forts : ne pas être reconnu par sa propre mère grâce au superbe accessoire capillaire, c’est quelque chose ! Elle ne fut d’ailleurs pas la seule, car ma marraine de Paris Web a cru également s’être trompée de salle, ne nous ayant pas reconnus au premier coup ! C’est l’effet perruque. :)

Et le plaisir de faire un duo avec un de mes héros du Web, ça n’a pas de prix. Parler sur scène de checklists qualité, lui sortir « je crois que tu en connais certaines ? » et entendre un « non » en guise de réponse (quand on connait le personnage et ce qu’il représente), je hurlais de rire intérieurement. Notez qu’on n’a pas prononcé le mot « Opquast » une seule fois sur scène… ce qui constitue un véritable exploit tellement cette marque, ce sceau devient incontournable en matière de qualité Web.

Pour mon parrain de Paris Web

Merci pour ce moment, comme dirait cette chère Valérie. Je me suis enrichi avec et grâce à toi, et vu que la connaissance est une de mes valeurs les plus capitales, je te remercie encore de les avoir autant enrichies. Et je peux te faire une prédiction : en matière de qualité Web, je ne vais pas m’arrêter en si bon chemin.

Et comme disait Serge (pas le lama hein) : moi non plus.

Paris web 2014 vu du spectateur… (le 26/10/2014)

Neuvième édition de Paris Web, nouveaux lieux, un programme différent sans pour autant renier les fondements de l’événement (web design, qualité et accessibilité), j’avoue que je me demandais si le légendaire « effet bœuf » Paris Web serait toujours présent. Je ne parlerai pas ici de mon intervention avec Élie Sloïm mais du point de vue du simple spectateur, le retour sur cette intervention arrivera juste après, car trop de choses à dire.

Le Beffroi de Montrouge

Premier bon point, le lieu ! Certes le palais Brongniart – le lieu de l’édition précédente – était un endroit somptueux, mais un peu froid à mon goût. Ce Beffroi de Montrouge m’a bien plus plu pour ma part : plus chaleureux, tout aussi confortable, des salles magnifiques, j’ai vraiment apprécié. Si on me demande d’y retourner, pour ma part, je signe de suite.

Les conférences/ateliers

Côté conférences, même si certains intitulés me laissaient pantois, je n’ai pas été déçu. Les interventions se suivent et s’enchaînent comme une symphonie, le staff assurant bien en chef d’orchestre si j’ose dire. Peu de déceptions et beaucoup de sujets intéressants et variés. Encore un bon point sur ce coup-là !

Si les informelles de l’année précédente ne m’avaient pas tenté, cette année j’en ai suivi une très intéressante sur la sécurité et la vie privée.

Certaines me font toujours l’effet « wouahou » (David Rousset et son casse-brique sonore entre autres) et d’autres ont été un « gros coup de cœur » :

  • « Things I wish I knew when I started in Digital Accessibility » de Billy Gregory : enfin on repart des bases en accessibilité : pourquoi on le fait et pourquoi on aime le faire. C’était sans fioritures, ça allait à l’essentiel, et surtout c’était très positif. Du bonheur en barre.
  • Le serment du Beffroi de Montrouge, de Jean-Philippe Simonnet m’a beaucoup plu aussi. Encore une fois, un bon « Back to basics » avec un orateur percutant, engagé et positif.

Mentions spéciales aux lightning talks, tous les orateurs ont assuré comme des bêtes, c’est hilarant, pertinent, irrévérencieux, bien envoyé… parfois émouvant. Ajoutons à cela que le fait d’être simple spectateur cette année m’a permis de les savourer bien plus ! Je n’ai pas pu pour autant empêcher mon rythme cardiaque d’accélérer en les voyant se lancer dans cet exercice pas facile. Chapeau bas à toutes et à tous, sans exception.

Bon point, je trouve que cette édition était plus ouverte sur les conférences anglophones. Je note que ces orateurs ont tous été impressionnés par le niveau d’accessibilité de l’événement.

Côté ateliers : accessibilité, performances, enseignement de l’intégration et programmation d’ascenseur (si si), j’en ai appris des choses ! Le plaisir reste de voir d’autres manières de travailler ou d’aborder les problèmes, j’apprécie cet enrichissement.

Les gens

Côté rencontres, j’ai été plutôt bien servi pour ma part, entre les visages connus des habitués et les nouvelles bouilles que j’ai apprécié de rencontrer, carton plein. J’aurais même aimé avoir plus de temps pour toutes ces bonnes ondes… y a pas de mal à se faire autant de bien. C’est un des rares endroits où je laisse très facilement tomber l’armure, il n’est pas rare que je tombe dans les bras de quelqu’un pour un gros câlin !

Papotages rigolos, discussions plus sérieuses, échanges d’expériences… tout cela foisonne. Cette année, un train loupé au retour m’a même permis de profiter d’une conférence en version privée (merci Goulven pour ce délicieux moment !) avec Morgane.

Je suis toujours fasciné par ce fait : même si nous travaillons tous sur des produits différents, même si nous sommes de niveaux différents, on s’y retrouve quand même et l’on se pose plus ou moins les mêmes questions. Les grands thèmes de cette année : partagez (votre code, etc.), confrontez, et apprenez de vos erreurs ! J’ajouterai même un « engagez-vous ».

L’organisation

Le staff doit être comme un bon Bordeaux, sans aucun doute il se bonifie avec l’âge. Je n’ai pas vu la moindre anicroche cette année. Grosse surprise de cette année, les vidéos étaient très (très !) rapidement disponibles, ce qui me permet de voir de suite les conférences que je n’ai pas pu voir, faute de don d’ubiquité. Les bonnes surprises continuent même si l’événement est terminé.

Tout cela me permet de prolonger l’effet Paris Web, et de décerner un bon gros perfect pour le staff. En toute simplicité. Comme je l’avais dit sur Twitter, j’espère qu’ils se rendent compte de l’impact que cet événement a sur nos vies. J’y reviendrai dans le compte-rendu vu de l’orateur.

En conclusion

Bref, l’esprit y est toujours, c’est toujours aussi bon, j’en suis reparti avec la pêche, et plein de bonnes idées. Paris Web est et reste mon indispensable cure de thalasso automnale.

Intégrateur de l’extrême : naviguer sur Kindle (le 21/09/2014)

J’avais déjà eu le plaisir de parler de certains périphériques un peu exotiques comme la tablette Go-Nomad dans « Intégrateur de l’extrême : les tablettes bas de gamme », et j’ai pu remettre ça ce week-end. Cette fois, c’est la liseuse d’Amazon – la célèbre Kindle – que j’ai pu tester.

Bien entendu, je ne parle pas de naviguer sur une Kindle Fire en couleurs, mais le modèle en noir et blanc.

Mon site personnel sur un Kindle

Vous me pardonnerez d’avance mes inexactitudes, je suis en mode curieux. Inutile de me dire que ce périphérique n’est pas prévu pour faire certaines choses que j’ai faites, je le sais. C’est de la curiosité intellectuelle, rien de plus. Je ne vais pas parler de sites dédiés pour le Kindle non plus (cf après).

Le Kindle

Hasard du calendrier, Agnès Haasser – dite « Tûtie » – a écrit quelques billets sur le sujet il y a peu, je vous invite donc à les lire pour mieux comprendre certains phénomènes dont je vais parler ici.

C’est bon, vous les avez lus ? Ok, vous pouvez continuer.

La découverte et déjà les premiers enseignements

Effectivement, voir ses réalisations ou ses sites habituels en noir et blanc est rigolo. Certains sites prennent même un certain cachet – l’élégance du noir et blanc – en étant consultés ainsi. J’avoue ne pas avoir mené des tests intensifs pour vous dire tout sur le sujet.

Les premières impressions sont étonnamment bonnes : le responsive est plutôt bien géré, les versions mobiles de certains de mes derniers sites s’affichent bien. Le rendu est en général très satisfaisant et plutôt agréable. Même si le périphérique n’est pas tactile, on arrive à naviguer sans trop de soucis. Comparé à la Go-Nomad, c’est largement supérieur.

Premier enseignement qui saute aux yeux… les contrastes. Les contrastes insuffisants se remarquent particulièrement vite. Certains contenus sont mêmes invisibles. L’effet de rémanence dû à la technologie décrite par Tûtie ne sont pas exagérés, loin de là. Dès qu’on scrolle sur une page, il arrive que l’on voie encore en filigrane les contenus de l’affichage précédent.

Deuxième enseignement… les performances. Vous avez intérêt d’avoir un site léger, bien optimisé et plutôt léger point de vue JavaScript (idéalement sans). Certains sites ont carrément fait planter le Kindle, trop lourds, trop d’effets inutiles.

L’exemple type est un simple effet de transition CSS sur une couleur de fond, comme sur oXXano dans la navigation principale, cela va faire passer l’écran du Kindle par tous les états si j’ose dire. Idem avec les dégradés, ils sont difficiles à rendre pour le Kindle (cf l’image ci-dessous).

Un rendu de dégradé sur Kindle

Mises à part ces quelques limitations techniques, je trouve que le Kindle se défend pas si mal.

De grandes réussites…

Certains sites sont particulièrement agréables à consulter. Sans aucun favoritisme, celui que j’ai préféré consulter ainsi est OpenWeb. Les contrastes suffisants, l’absence de tonnes de JavaScript, le texte suffisamment gros et aéré, pour un peu, je sentirais le bruit du papier de l’encyclopédie, à m’en demander si Emmanuel Clément n’avait pas prévu le coup :). Alsacréations s’en sort aussi très bien.

Openweb sur KindleAlsacréations sur Kindle

Certaines de mes dernières réalisations (comme oXXano, mon site personnel, Genix, etc.) sont globalement assez agréables, même si vous vous doutez bien que tous ces sites n’ont pas été conçus dans cette approche. Quelques exemples ci-dessous :

SEIC sur Kindle Genix sur Kindle

Et quelques fails bien sentis

Les grosses usines en JavaScript changeant l’affichage de la page font ramer le Kindle (et quand je dis usine, il n’y a pas besoin de grand chose). Au hasard… le carrousel automatique ! Hé bien, c’est très mal. Comme l’indiquait Tûtie dans ses billets, cela fait peiner fortement l’affichage et déclenche de nombreux rafraichissements pour éviter les images rémanentes. Et devinez quoi ? Oui, ça fait ramer le Kindle. La boucle est bouclée. Donc encore une raison de plus de dire que les carrousels automatiques, c’est (le) mal (absolu).

J’ai quelques erreurs de codes unicode, comme sur l’espace fine insécable (première image ci-dessous). J’avoue ne pas les avoir trop compris pourquoi, car par contre sur mon site personnel (où je l’utilise), il est parfaitement affiché.

La page d’accueil de mon site d’agence (deuxième image ci-après) est particulièrement gratinée : les background-size ne sont pas gérés (l’affichage « retina à la con » des icones est cassé), je retrouve un problème de soulignement que j’avais déjà vu sur certains vieux Android, et pour couronner le tout… erreur d’affichage du caractère unicode « ≡ ». Et pan ! Ceci dit, les autres pages restent tout à fait correctes, et le site est utilisable. De là à dire qu’il faut réellement penser à l’information critique et à la façon dont on la véhicule, il n’y a qu’un pas que je suis bien tenté de franchir.

Unicode fail sur KindleTriple combo : carrousel, unicode et background-size

Petit gag, un lien avec un attribut target="_blank" va afficher une pop-up vous disant que ce n’est pas possible d’ouvrir plusieurs fenêtres. target="_blank", prends ça dans ta gueule ! (sur la première image ci-dessous)

Second gag, mes border-radius de Vision Clinique sont rendus carrés. (sur la seconde image ci-dessous)

Pop-up sur target blankBorder radius carré

Évidemment, j’ai testé sur mes propres sites qui sont relativement légers. J’imagine que des grosses usines avec beaucoup de contenus doivent faire bien plus souffrir le Kindle.

En conclusion

Pas de mystères, ce genre de périphérique fait sauter aux yeux les excès des sites, bien plus rapidement que sur des mobiles survitaminés comme certains smartphones. Néanmoins, il est tout à fait possible d’avoir des rendus corrects, et la mission première des sites – naviguer et transmettre des informations – est tout à fait envisageable.

Encore une fois, une conception raisonnée et raisonnable permet de s’en sortir, mais cela, vous le saviez déjà, n’est-ce pas ?

Les demandes « critiques » (le 10/09/2014)

Je reçois régulièrement des demandes, et comme toujours, tout est urgent. Parfois, c’est même le cran au-dessus. La demande est classée alors comme « critique ».

Comme le garçon qui criait au loup dans la fable d’Esope, il faut vraiment se méfier avant de classer une demande comme telle (et encore plus si c’est régulièrement le cas).

Régulièrement, j’ai ce genre de listes de demandes avec ce genre de priorités.

Liste critique

Apparemment, tout est très très très urgent, voire « critique ». Attention, l’emploi de ce mot déclenche normalement un état particulier chez le développeur. Les joueurs appelleront cela le mode berseker, pour des personnes normales, nous appellerons cela le mode « pompier qui va au feu ».

Je ne sais pas si vous avez déjà eu la malchance d’avoir un incendie chez vous, mais grosso modo, les pompiers sont là pour sauver la baraque en urgence (et ses occupants, cela va sans dire). Et ils ne vont pas faire dans le détail : la lance à incendie va effectivement éteindre le feu et éviter que la maison ne s’écroule ou parte en fumée. Bien sûr, vous vous doutez bien que ce qui est dedans va morfler sévère (en général, les téléviseurs ne sont pas étudiés pour résister à 2 bars de pression d’un jet d’eau froide).

Classer une demande comme « critique », c’est pareil. Le développeur va foncer pour éteindre le feu rapidement, et, même s’il peut prendre des précautions, sur une demande « critique », il va peut-être s’autoriser des choses qu’il ne ferait jamais en temps normal. Quelques exemples :

  • Intervenir sur un site en production
  • Débugger directement sur le site en production pour comprendre
  • Intervenir sans gants : affichage de requêtes, de données, etc.
  • Ne pas faire dans le détail, au risque de faire de la casse (moindre) ailleurs
  • Etc.

Les vraies questions avant de classer une demande comme « critique » sont : est-ce que ma demande nécessite de prendre tous ces risques, est une urgence vitale qui ne peut pas réellement pas attendre une seconde et doit totalement occulter tout le reste ?

Si effectivement, vous avez répondu par l’affirmative dans ces trois cas, c’est critique. Sinon cela ne l’est pas. Je ne minimise pas les demandes urgentes en disant cela, que l’on soit bien d’accord.

L’autre danger, c’est qu’à force de tout le temps classer des demandes comme critiques alors qu’elles ne le sont pas du tout, au final, les développeurs ne s’affollent plus du tout, et bien entendu, le jour où ils doivent vraiment s’affoler, il ne le feront pas (comme la fable d’Esope que je mentionnais plus haut).

Un point de détail : les caprices genre « je veux ça tout de suite », le « stressage » gratuit de développeur ne sont pas des demandes critiques. D’expérience, les demandes réellement critiques ne sont pas inexistantes, mais sont très rares.

Vous souvenez-vous du futur ? (le 07/09/2014)

Petit préambule.

Je m’aperçois que j’ai honteusement oublié de fêter les 10 ans de ce site, en tout cas, sous cette forme.

J’ai eu une idée qui j’espère va vous amuser, en tout cas plus que d’inutiles statistiques dont tout le monde se fout.

Imaginons que j’aie le pouvoir de me rencontrer il y a 10 ans. La discussion serait cocasse, et nous rappelerait de quoi on est parti en matière d’intégration. Oui, on disait « intégration » à cette époque, pas « front-end ».

En emphase, il y aura parfois mon avis, mais quelque chose que je ne peux pas dire sans risquer de faille du continuum-espace temps. Hypothèse la plus pessimiste, le phénomène pourrait être localisé à notre seule galaxie.

La discussion

— Salut ! J’arrive du futur, grosso modo 10 ans d’écart sont entre toi et moi (punaise, j’avais encore des cheveux à cette époque, hem).
— Hein ? Tu veux dire que tu viens de 2014 ?
— Effectivement.
— Donc ça veut dire que je serai toujours en vie, c’est déjà ça !
— Effectivement, mais ne compte pas sur moi pour t’en dire plus, il n’est pas bon d’en savoir trop sur son avenir personnel.
— Allez, tu peux bien faire un effort.
— Non, les conséquences pourraient être dramatiques. (le libre-arbitre, ça n’est pas un détail, jeune con)
— Et si on parlait de Web alors ?
— Si tu veux, mais ne me pose pas de questions ouvertes, je préfère te répondre à des points précis. Et si j’estime que je dois rester évasif, tu n’auras pas de détail.

— Arf, si tu veux. Tu es aussi borné que mon boss : pas plus tard que ce matin, j’ai encore dû me justifier pour faire une intégration CSS correcte, rassure-moi, ça ne sera pas encore le cas dans 10 ans ?
— Héhé, pas au sens où tu l’entends ! Mais tu devras encore faire entendre certains arguments, même si ce ne seront plus forcément les mêmes (et t’as pas fini d’en chier, vieux, enfin… jeune).
— Je vais donc enfin arrêter de faire de la guérilla pour faire du bon boulot.
— Cela sera plus insidieux dirons-nous (le côté obscur est la facilité de mal faire, punaise, je parle comme un vieux Jedi).

— Quand je pense qu’il y a un an, je m’engueulais avec mon prof à l’IUT, qui me disait que personne ne me demandera jamais de travailler comme ça.
— Un conseil d’avenir ! Visiblement, il n’a pas imaginé qu’il y aurait un paquet de navigateurs… (et sans compter les périphériques)
— Quoi ? Ça veut dire qu’on arrêtera de penser uniquement IE6 ?
— Oui :)

— J’avoue que je n’y croyais plus. Dire qu’on me prend pour un illuminé quand je parle de Firefox 1.0. Et pourtant, je crois que ce navigateur va changer beaucoup de choses.
(Firefox 1, punaise, c’est vrai) Ton intuition est juste, il fera beaucoup de bien au Web. Directement ou indirectement d’ailleurs.
— Quand je vois ces pop-ups, je n’arrive plus à y supporter.
(comment ne pas lui dire que ça sera autant le bordel 10 ans après avec des lightboxes à la con) Il n’y aura pas que ça.
— Ça veut dire que ces satanés bugs CSS sous IE seront tous résolus ?
— Ne t’emballe pas trop vite. Ça mettra du temps. Et c’est loin d’être fini (ça le sera jamais).

— Mais à priori ça avancera. Donc les standards tiendront toutes leurs promesses ?
— Ils en tiendront beaucoup.
— Donc cela veut dire que tout le monde fonctionnera avec ?
— Heuuuuuu… tu connais les bonnes résolutions ? (qu’on prend mais qu’on ne tient pas)
— Pourquoi tu me parles de ça ?
— Tu comprendras plus tard ! (comment lui dire qu’à peine sorti de la monoculture IE, plein de gens referont la même bêtise)

— Tous les sites seront validés XHTML et servis en XML ? Un code sans erreur me paraît être obligatoire !
— Heuuuuu… je sais que tu penses que XHTML est une voie d’avenir, et effectivement ça fera beaucoup de bien à une époque, mais tu auras quelques grosses surprises.
— Sérieux, HTML4, c’était rigolo, mais on va aller vers du XHTML à minima.
— Ah ah. Tu verras. (dire que tu seras considéré comme un fou, une relique, un psychopathe ou les trois à la fois pour servir ce site ainsi).
— Ok, tu ne veux rien me dire. Au moins le métier va se stabiliser ?
— Joker. (comment lui dire que ça va devenir 100 fois plus simple et compliqué en même temps)
— Ok, j’imagine que tu ne veux pas en dire plus. J’en apprendrai sûrement sur ce petit forum sympathique qui vient d’ouvrir.

— Lequel ?
— Alsacréations.
— Effectivement, le « petit » forum d’Alsacréations. :)
— Quoi, j’ai dit une bêtise ?
— Non non, c’est juste le mot petit qui m’a fait sourire. Tu comprendras dans quelques années. (juste une référence mais bon)
— Et Openweb, j’adore ce qu’ils font.
— Héhé, sans aucun doute. :)

— En tout cas, j’aime bien ce nouveau référentiel qui vient de sortir !
— Lequel ?
— Opquast. Est-ce qu’ils vont aller loin ?
— Ils feront beaucoup de choses très bien pour le Web. Et tu apprendras beaucoup avec (comment te dire qu’ils vont symboliser ce que tu aimes le plus dans le Web).
— Je le savais. J’avais bien aimé l’idée de bonnes pratiques. La version imprimable, etc.

— Oui, la CSS print. Tu en écriras sur le sujet… ne te décourage pas, quoi qu’il arrive.
— Mais de quoi tu parles ? Je n’ai rien écrit sur le sujet !
(et mer…) Ça viendra, pense à l’intranet que tu es en train de coder.
— Ah oui ! Tiens d’ailleurs j’ai eu une discussion enflammée avec un gusse au boulot, j’ai juste eu l’impression qu’il n’a pas compris ce que je lui ai dit.
— Héhé, je ne m’en souvenais plus. Effectivement.

— En tout cas, tout cela m’a l’air réjouissant. Le boulot de l’intégrateur sera-t-il un jour enfin reconnu à sa juste valeur ?
— Comment dire ? Hem… disons que certaines évolutions vont le rendre incontournable pour certains points.
— C’est quand même qu’on s’occupe de tout ce qui s’affiche chez l’utilisateur, ce n’est pas rien ! J’arrive pas à comprendre qu’on soit le dernier maillon de la chaîne.
(bénie soit l’intelligence du débutant, c’était pourtant tellement évident) Effectivement ce n’est pas rien.

— Quand même, quand je vois que je passe après le graphiste, c’est débile.
— T’inquiète, maintenant, c’est moi qui gueule et qui suis au centre de l’attention.
— Sérieux ???
— J’en ai trop dit, et m… C’est de ma faute.
— De la mienne donc.
— Si tu veux !

— En tout cas, je te dis merci, tu m’as montré que certaines de mes intuitions étaient vraies, tu m’as montré certains buts à atteindre. Quelque part, j’ai l’impression d’avoir triché.
— Aucune triche, je t’ai donné quelques indications, mais c’est à toi de parcourir le chemin. Cela mettra du temps.
— Tu m’as dit aussi que je serai très motivé pour certains projets, que ça étonnera même des gens que j’y passe autant de temps.
— Effectivement.
— Je leur dirai quoi quand ils me demanderont d’où vient cette motivation ? Je ne peux pas dire que ça viendra de toi !
— Certes non. Mais comme je suis toi avec 10 ans de plus, tu n’auras qu’à leur dire que ça vient de toi. Au revoir !

Note du Nico de 2014 : Et ne t’inquiète pas, j’ignore si c’est de ma faute ou non, mais tu mettras beaucoup de temps, ce n’est pas au début que tu seras le plus éveillé, le plus actif. 10 ans de blog, ça ne sera pas rien. Je ne t’en veux pas, peut-être ce temps a été nécessaire, aurait-il pu être mieux utilisé ou plus mal, je ne le saurai jamais. Le temps est sans importance, seule la vie est importante.

— Nico de 2024, tape sur l’épaule : hé, 20 ans, je te raconte pas !
— Nico de 2014 : Nom d’un cul de canard dans ma baignoire !!!!!!!! Je ne veux rien savoir. Rendez-vous dans dix ans.

Attribut SVG viewbox, bon pour le responsive (le 07/09/2014)

L’autre jour, je travaillais sur un projet nécessitant l’utilisation de D3.js (pour Data-Driven Documents). Grosso modo, cette bibliothèque JavaScript permet de générer des graphiques SVG sur vos pages web. Le SVG généré est dit inline, autrement dit il est embarqué directement dans la page via la balise svg.

Ceci dit, ce n’est pas de cet outil dont je veux parler, mais bien de SVG et responsive (qui font très bon ménage avec des sites optimisés Retina™©).

J’avais fait mon template, et j’ai ajouté un graphique généré par D3.js. Je teste le résultat, le graphique s’affiche bien. Comme le site est responsive, je redimensionne la fenêtre, et là… patatrac, le code SVG embarqué ne se redimensionne pas.

J’étudie le code de RÖCSSTI, ah, effectivement, je n’avais pas prévu le cas dans la CSS (corrigé depuis). Je corrige de suite :

svg {
height: auto;
max-width: 100%;
}

Là, je me dis que l’affaire est entendue… et non pas du tout ! Cela ne marche toujours pas.

En bon français, je commence à râler : j’avais déjà utilisé du SVG en ligne sur d’autres sites comme Parenti Design et je n’avais pas constaté le problème. Mais diantre, de quoi cela a bien pu venir ?

Après quelques recherches, j’étudie le code de l’exemple que j’ai utilisé, à savoir un donut chart avec D3.js.

Il manque quelques attributs par rapport à « ce-que-j’ai-qui-marche™ », je les ajoute (en gras ci-dessous) :

var svg = d3.select(".arc").append("svg")
.attr("width", width)
.attr("height", height)
.attr("role", "img") // un peu d’a11y
.attr("viewBox", "0 0 "+ width + " " + height) // l’attribut viewbox
.append("g")
.attr("transform", "translate(" + width / 2 + "," + height / 2 + ")");

Et là, ça marche. Après quelques recherches, j’apprends que l’attribut viewbox sert à préserver le ratio entre autres.

Je vous ai fait rapidement un exemple à la Rache™ : affichage d’un SVG inline en responsive.

J’ai volontairement mis le logo SVG de RÖCSSTI dans un conteneur trop petit. Dans le premier cas, l’attribut viewbox est absent et ça foire, dans le second, il est présent. Si le max-width: 100%; n’est pas présent dans la CSS, cela ne marche pas non plus.

Bref, vérifiez bien les SVG que vous générez ou que l’on vous fournit si vous ne voulez pas avoir quelques soucis en responsive. Et au fait, le SVG, c’est génial.

Produire une version print CSS à peu de frais (le 02/09/2014)

Je suis toujours surpris que bon nombre de développeurs front ne soient pas capables ou ne pensent même pas à mettre à disposition une version imprimable de leur site. Pourtant, avec quelques connaissances et quelques bons réflexes, ce n’est vraiment pas difficile.

Que ce soit clair : je ne parle pas de produire une impression absolument parfaite à partir d’un site (bonjour la sur-qualité inutile), je parle juste d’une version print raisonnablement correcte en y passant vraiment très peu de temps. Quand arrive le moment de la checklist avant mise en ligne (surtout si c’est sur un projet auquel je n’ai pas participé), un de mes jeux préférés au boulot est de chercher à produire une version imprimable correcte en le moins de temps et le moins de lignes de code possible.

Oui, le développeur front-end est un grand enfant.

Quelques points de repères

En général, on peut partir du postulat que l’utilisateur n’a pas coché l’option « Imprimer le fond de page (couleurs et images) ». Exemple sur Firefox.

Options Print de Firefox

Ce qui implique donc que les couleurs de fond, les images de fond (en CSS) ne seront pas prises en compte. Si vous voulez qu’une image soit imprimée, elle doit être dans le contenu (dans le HTML). L’exemple type est le logo du site, en général, c’est important qu’il soit sur la version imprimable.

Et de toutes manières, il est même préférable de faire comme s’il avait coché cette option, cela peut se comprendre aisément : imaginez qu’il essaie d’imprimer une page et que ça lui vide ses cartouches d’encre parce que le concepteur a été trop bêta pour y penser, cela va le mettre dans une colère noire. Et il n’aura pas foncièrement tort.

Grosso modo, l’approche pour produire du CSS print à peu de frais est en trois étapes :

  • « reseter les contenus » (virer les images de fond, mettre le texte en noir sur blanc, remettre le flux normal, etc.) ;
  • cacher les éléments inutiles (les zones de navigation principalement) ;
  • faire de petites adaptations (facultatif dans de nombreux cas).

Un point de détail : dans la grande majorité des cas, c’est plus long à expliquer qu’à faire. Je n’y passe quasiment jamais plus de 20 minutes, parfois cette question se règle en moins de 5 minutes (je rappelle que c’est une version print à peu de frais que l’on cherche). Les seuls cas où cela peut devenir plus long sont les sites très graphiques (avec beaucoup d’effets ou de mise en forme).

Un exemple

Pas de long discours, prenons un exemple sur une de mes dernières intégrations, le site Genix. Dans ce cas précis, j’utilise mon micro-framework CSS Röcssti qui a une partie print.

Deux cas de figure :

  • soit le développeur front talentueux a déjà placé des classes .noprint sur les éléments ne devant pas être imprimés ;
  • soit dans le feu de l’action, le développeur front n’a pas mis ces classes.

Dans le premier cas, il est déjà possible que l’essentiel du travail soit déjà fait. Dans le second, il faudra donc ajouter quelques classes dans la CSS, à factoriser avec la classe .noprint.

Là dans ce cas précis, le graphiste m’avait fourni un logo spécial pour le print. Il est donc caché dans la source via la classe .hidden et s’affichera uniquement pour le print via la classe .onprint. Parfois le logo du site peut être réutilisé tel quel.

En l’occurence, sur ce projet, j’avais pensé à mettre des classes .noprint sur la navigation, les éléments inutiles (le lien dans le pied de page, le changement de langue, etc.). La baseline tire parti du reset print qui la remet simplement dans le flux, en-dessous du logo. L’image de fond est virée également via la classe .reset4print, et les contenus sont remis à zéro, toujours grâce à cette classe.

Si une page nécessite plus d’attention, une méthode très simple permet d’accélérer la manœuvre : je me mets sur la page en question, et je remplace @media print par @media screen. Cela permet d’élaguer très rapidement (cacher, reseter) sans devoir faire des « aperçus avant impression » en rafale.

Si vous doutez de l’efficacité de la méthode, comparez la version print de base de RÖCSSTI, et comparez avec la CSS du site Genix. Certaines pages comme ont une version print vraiment satisfaisante, et avec peu d’efforts.

Des choses à savoir

Pour les propriétés supportées ou non, allez faire un tour sur mon article sur Openweb : maîtriser l’impression CSS. Même s’il est assez ancien, il explique beaucoup de choses.

Si vous intégrez comme moi en em média-queries comprises, vous pouvez avoir quelques surprises avec Chrome, qui va appliquer certaines média-queries pour plus petites tailles d’écran avant de le passer à la moulinette print (ce n’est pas illogique en soi, certains résultats sont juste surprenants). J’avais eu ce souci sur le site de Genix security group. Une solution très simple : ajouter @media screen à vos média-queries non print.

Pour ce qui est du contenu, il y a toujours un débat sur les liens (doit-on afficher les URL, etc.). Même si des choses très sympathiques sont possibles comme a:after { content: " (" attr(href) ") "; }, en général je désactive ce genre d’options (toujours un cas particulier qui ne marche pas, etc.).

En 10 ans de métier, je n’ai jamais eu une personne qui s’en est plaint. :)

Côté ressources, je ne saurais que vous conseiller le livre de Corinne Schillinger « Intégration Web, les bonnes pratiques », qui donne d’excellent conseils sur le sujet. Sinon Alsacréations propose un chouette beau tutoriel sur le sujet : Une feuille de styles de base pour le media print.

Pensez-y, c’est vraiment facile à faire, ça ne coûte pas beaucoup de temps et « c’est bien ».

Le meilleur spam du monde (le 21/08/2014)

Ce n’est pas dans mes habitudes, mais là je suis obligé de le faire. J’ai reçu un spam vraiment très très drôle ce matin !

Je le publie tel quel (sauf e-mail anonymisé, des fois que ça soit un vrai).

A VOTRE AIMABLE ATTENTION
Monsieur Mark Zuckerberg, Président Directeur Général du plus grand Réseau Social Facebook a le plaisir de vous annoncer qu'il a organisé une Spéciale Tombola Internet et vous informe des résultats du programme de la Loterie du Grand Réseau Facebook 2013 tenue la semaine dernière en Afrique au Bénin, et cette loterie est approuvée par les autorités compétentes de la salle des jeux du Bénin à la présence des partenaires venant de divers continents. Le Bénin faisant parti du continent Africain a été choisi cette année pour abriter le tirage au sort. Le Continent Européen se préparera pour accueillir la sélection prochaine, et cette Tombola consiste à recenser les adresses électroniques (E-mails) ou site web(profil) sur Facebook, Un jury composé d'éminentes personnalités a tiré au sort 10 E-mails dans 9.525000 E mails recensés. Le Réseau Facebook a en ce jour le plaisir de vous annoncer que votre e-mail(ou profil) a été tiré au sort et figure donc sur la liste des 10 e-mails sélectionnés, vous êtes déclaré gagnant du troisième prix et votre gain est de 250.000$. Ce tirage a été favorisé et supervisé par Me DEVEZ ROLAND dont voici ci-dessous votre numéro de références, votre code gagnant, votre rang et votre prix gagné.


Réf: GAF/DAP/0245
Code gagnant: CZQ 009-0587-baf/2014-02
Rang: 3eme
Prix Gagné : 250.000$


Alors pour être en possession de votre Gain, nous vous demandons de bien vouloir envoyer de toute urgence à l'adresse du Maitre DEVEZ ROLAND qui est : xxxx.xxxxxx@yahoo.com
un message de confirmation comportant les coordonnées de votre gain indiqué ci-dessus, ainsi que votre: NOM: PRÉNOMS: ADRESSE : NATIONALITÉ
: PROFESSION: NUMÉRO DE TÉLÉPHONE: PAYS DE RÉSIDENCE : VILLE DE RÉSIDENCE: DATE DE NAISSANCE : CODE POSTAL : AGE: SEXE :


Envoyé simplement cette cage de renseignement suivie des références qui permettra au Me DEVEZ ROLAND de vous identifier, et de vous donner la
procédure de retrait de votre gain: xxxx.xxxxxx@yahoo.com

Su-blime.

Le Petit univers du Web ! (le 16/08/2014)

Une fois n’est pas coutume, je laisse la place à quelqu’un d’autre.

Je suis née à l’heure du minitel, du téléphone qui a des fils et surtout des consoles à cassette, des disquettes grandes et souples, du VHS !
Quand j’ai rencontré mon futur mari, le choc fut grand !

Le choc

Jeux PC, l’ordinateur, le web, surfer, Linux, Firefox, Internet Explorer, Control C, Control V… du chinois.

J’ai découvert la game boy et son jeu Tetris ! Petit jeu addictif certes, mais plus de deux boutons à gérer et je suis perdue.

Un écran bleu tout en anglais, la seule chose que je comprenne, « you lost data » ! Oups, j’ai juste voulu démarrer une session Linux comme on me l’a montré pour jouer, surfer, bref, utiliser un ordinateur !
« Allo, chéri j’ai un petit problème ». Tu t’expliques et la question qui tue : « tu as fait quoi ? Comment tu as fait pour planter un Linux, c’est implantable ! » Réponse : « ben rien de plus que ce que tu m’as montré ! ».

Pourquoi un ordinateur doit-il rester allumé plusieurs jours, voir un mois, pour un calcul image par image, pour ensuite passer plusieurs jours au montage et synchronisation de la musique sur une animation ?
Et tiens pourquoi pas écrire un tutoriel ? C’est quoi cette bête, de quelle race elle est ?
Et voilà mon saut dans la quatrième dimension est fait… Je suis condamnée à parler une langue qui est d’un autre monde.

Un geek

Un geek c’est quoi, je ne le sais toujours pas vraiment !

Mais je porte des t-shirts qui portent des inscriptions que personne ne comprend sauf quand je rencontre les collègues de mon mari ! (vos id ont de la class, Cascadov Stylski, etc.)

Je suis capable de juger un site sur son accessibilité pour les gens ignares comme moi ! Je déteste quand ça rame ou quand la page web ne s’ouvre pas correctement.
Je tente de comprendre la différence entre le JavaScript, le web design, le front, le HTML, le responsive !!!!
Je m’égare là… Sortez moi de là !!!
Voilà ce que 14 ans de vie commune avec un passionné du web fait de vous.

La vie trépidante

Je suis infirmière, le web est pour moi une île cauchemardesque.

Je me retrouve à écouter les répétitions de conférences auxquelles je ne comprends rien, écouter comment on programme un site en CSS, ou comment un graphiste fout le bordel dans l’intégration, ou comment faire un site quand le contenu n’est pas connu du programmeur…

Parlez moi opération, organes vitaux, pansement, détersion et cicatrisation de plaie, bref d’humain là je vous comprends…
Pour le reste c’est du javanais !

Tu te lèves, c’est bonjour tablette, après le repas, j’ai un article auquel je pense, j’ai des modif’s à faire sur mon site, t’inquiète pas des notifications qui apparaissent en haut de l’écran, c’est Twitter !

Il me trompe…

La maîtresse de mon mari, je la connais : c’est rectangulaire, plutôt plat, un écran lumineux et des petites touches.

Quand il n’est pas avec moi, il est avec elle ! Au moins je sais où le trouver quand j’ai besoin de quelque chose.

Le pire dans tout ça, c’est que même si tu n’y comprends rien, tu finis par devenir toi aussi une accro. C’est quand même bien pratique.

J’aime mes jeux stupides sur mon réseau social, que mon mari déteste pour d’autres raisons obscures pour moi ! J’aime mes jeux stupides sur tablette… d’ailleurs, à la maison c’est la guerre pour savoir qui pourra avoir la tablette !

Le matin, c’est le Joueur du Grenier, je connais même pas les jeux qu’il critique.

Je suis béta-testeuse pour site grand public, je suis auditoire de conférences web, en plus je dois donner mon avis sans rien comprendre au contenu !

Ok, c’est comme ça, et bien je veux comprendre…
C’est quoi le web design ? C’est l’aspect d’un site qui rend son approche plus explicite par des codes universels.
Le CSS, le JavaScript, le HTML : des langages qui permettent la programmation des sites internet.
Le responsive : un site qui peux s’adapter à tout support.
L’accessibilité : que tout à chacun puisse avoir accès à un site quel que soit son handicap.

Première dans un concours de circonstances

Suivre une conversation où plusieurs professionnels du web parlent entre eux est juste impossible.

Tu es assis à côté d’un charmant monsieur avec qui tu discutes de la pluie et du beau temps, quand ton mari t’explique que c’est le président de Mozilla Europe… Cela te fait une belle jambe mais lui, ça fait 10 ans qu’il voulait être à ta place pour le rencontrer. D’ailleurs, il n’a même pas osé lui parler. Bon il se rattrapera le lendemain.

Si tu ne veux pas que ton conjoint devienne un étranger, il faut tenter une percée dans son monde.
L’écouter parler de son travail, poser des questions si tu ne comprends pas…

Comprendre en quoi OpenWeb est important, et que communiquer avec d’autres professionnels est important.
Comprendre que pour rester bon dans son job, la formation, les conférences, les rencontres inter-professionnelles sont capitales.

Au début, ce fut non !!!! Non !!! Non !!!

Téléphone à 21h pour discuter, faire des articles, d’aller écouter des conférences, tu deviens orateur, non mais ça va pas !!!
Et bien, j’y vais avec lui !

Immersion à un after d’une conférence (Kiwi party, quelle idée d’appeler ça ainsi ?????)… Petit jeu autour du net, tout le monde rigole et toi… tu ne comprends rien ! T-shirt avec des sigles bizarres, moi j’ai un singe noir sur un t-shirt gris, eux voyent la mascotte de MailChimp.

Repas des orateurs, tu fréquentes des références du web et toi… tu vois juste Pierre, Paul, Jacques !
En revanche je découvre des endroits formidables et surtout, je partage un peu de l’univers de mon geek !
La joie quand il appris un nouveau truc, quand il rencontre des gens qui sont d’accord avec sa vision du web et du travail de développeur. Me faire présenter à des gens que je ne connais que de nom ! Et bien sûr ne pas m’en souvenir 3 mois plus tard.

Être la femme d’un passionné du web, c’est accepter de faire une place belle à l’ordinateur à la maison et de voir arriver des objets à écran tactile, de laisser mon fils de 3 ans utiliser tous ces écrans alors que mon approche médicale me dit de limiter ce genre de choses.

C’est aussi sacrifier du temps en commun pour que les articles sortent en temps et en heure, écouter pendant plusieurs jours la même conférence avec des slides auxquels tu ne comprends rien. Voir plusieurs fois par an son mari partir dans divers endroits faire des conférences ou en écouter.

Tous ces efforts permettent un équilibre de famille et de vie professionnelle. Car cette émulation entre professionnels est importante.

Et si on s’épanouit professionnellement et personnellement… le bonheur n’est pas loin.

Refonte du site de Parenti Design, SVG et CSS avancés (le 13/07/2014)

J’ai pu participer à la refonte du site de l’agence Parenti Design il y a peu.

Parenti Design

Comme ce site m’a permis d’expérimenter pas mal de choses, un bon gros billet technique s’impose !

Idées autour du projet

Le projet est parti d’une suggestion d’un site responsive qui comprenait moult animations. Seule ombre – haha – au tableau, le site présenté était une usine à gaz… à la limite du bon sens. 7,3 Mo pour une page standard ! Oui vous avez bien lu. Autant le dire de suite, j’ai essayé de l’afficher sur un mobile connecté en wifi – j’allais pas essayer en 3G ! – pour voir si c’était possible, le mobile en question n’a pas été d’accord et s’est mis en grève. Je ne pouvais pas lui en vouloir ceci dit.

Le graphisme a finalement été arrêté et fourni par l’agence, et mon travail a pu commencer. Au final, une page standard hors grosses photos et/ou vidéos était plutôt de l’ordre de 250 ko. Si quelqu’un croit encore que le développeur front-end éclairé est un luxe, envoyez-le moi !

Gérer l’imprévisibilité en atomique

Le projet étant quelque peu mouvant (des tonnes de petits changements en permanence si vous préférez), je reconnais que les classes atomiques m’ont bien facilité la vie. Particulièrement pour gérer le petit cas particulier qui devient la règle avant de redevenir le petit cas particulier.

L’évolution récente du site confirme cet état : définitivement, penser trop gros objets sur ce genre de projets, c’est casse-gueule. Autant fonctionner en petits objets.

En tout cas, j’étais déjà fan des em, et… je le suis de plus en plus, surtout dans les média-queries. :)

SVG, le bonheur du retina et pas seulement

Comme il était clair qu’une optimisation retina (dans les limites du bon sens) serait de la partie, l’utilisation de SVG a été massive : images – certes décoratives – de contenu, icônes, images CSS, animation sur la page d’accueil, etc.

J’ai utilisé cette méthode pour les images de contenus, bien qu’ancienne, elle reste très robuste : du SVG pour vos logos. Elle permet de charger une image en PNG si l’agent utilisateur ne supporte pas le SVG.

Pour l’animation du SVG sur la home page, j’ai suivi ce tutoriel : Animated line drawing in SVG, ce qui m’a permis d’utiliser des propriétés CSS que je n’utilise pas souvent : fill, stroke-dasharray, stroke-dashoffset, stroke-width, stroke, etc. :)

Mon graphiste s’est fait un plaisir de me fournir les SVG, après optimisation avec SVGO, ces derniers se sont souvent avérés plus légers que leurs équivalents en PNG. Comme en plus ces derniers sont future-ready (si un nouveau smartphone a une densité de pixels encore plus élevée, aucun souci), je me demande pourquoi SVG n’est pas plus massivement utilisé…

Amélioration progressive

Comme je ne voulais pas déclencher des animations inutiles, j’ai utilisé modernizr avec un tout petit build. J’avais besoin de savoir si le visiteur supportait SVG, les transitions, les animations CSS, flexbox, etc.

Chaque fois que j’utilisais un de ces éléments, un simple préfixage par les classes de modernizr a permis de ne servir les propriétés qu’aux navigateurs les supportant (y a un exemple juste après avec flexbox).

Le header fixé – entre autres – m’a forcé à ruser quelque peu, notamment avec des liens vers des ancres internes. Partant de l’idée qu’un lien vers une ancre est la meilleure solution si JavaScript est désactivé, l’idée fut simple : chopper la hauteur du header, et gérer le décalage à prendre en compte à cause du header fixé.

Autre point, j’ai dû utiliser flexbox pour un positionnement impossible sans (sur la page d’accueil), encore une fois, passage en mode amélioration progressive. J’ai codé le site sans, puis j’ai refait les classes préfixées par .flexbox, comme ici :

/* sans flexbox */
.glider-container {
display: table;
}
/* … */
.flexbox .glider-img-container {
display: flex;
}

C’est peut-être moins parfait sans flexbox, mais au moins cela ne cassera pas. D’ailleurs, si je ne vous l’avais pas dit, vous ne vous en seriez jamais aperçu ! :)

Des animations en CSS, lancées par du jQuery

Le principe était le même : quand on scrolle sur les pages, certaines parties devaient apparaître. Très simplement, l’idée a été de détecter quand le bas de l’écran arrive sur la zone en question, et de déclencher l’animation.

Afin de le faire proprement, j’avais une classe pour dire « tel bloc va être animé », et une classe pour faire l’animation inverse quand on arrive dessus. Par exemple :

.csstransitions .transition-opacity1 {
opacity: 0;
-webkit-transition:opacity 2s ease;
-moz-transition:opacity 2s ease;
-o-transition:opacity 2s ease;
transition:opacity 2s ease;
}
.csstransitions .transition-opacity1--active {
opacity: 1;
}

Là, l’élément sur lequel j’applique la classe transition-opacity1, si l’agent utilisateur supporte les transitions CSS, va devenir complètement transparent. Quand on lui ajoutera la classe transition-opacity1--active, la transition le fera réapparaitre. Pas plus compliqué que cela !

Seul regret, j’avais créé plusieurs types d’animations :

  • effet d’apparition en zoom (transform: scale)
  • effet de fondu (opacity)
  • arrivée du contenu par la droite (left), la gauche (right) ou le bas (bottom)
  • etc.

Et au final, seules quelques unes ont été utilisées. En même temps, il me semblait avoir indiqué en début de projet que trop d’animation tuait l’animation, dommage qu’il ait fallu que je les mette toutes sur une page pour qu’on m’écoute ! :)

J’ai utilisé cet outil pour générer la courbe de Béziers : CSS Easing Animation Tool. Ainsi, ça m’a permis de générer ce genre de courbe.

Courbe de Bézier

Les animations et transitions CSS sont un vrai régal à utiliser, plus je faisais des essais, plus je me disais que je pouvais faire potentiellement n’importe quoi. Le gros caillou dans la chaussure, c’est quand on doit animer une propriété non stabilisée. La gestion des préfixes devient très pénible, par exemple : -webkit-transition: -webkit-transform. Si vous voulez animer une propriété dont la standardisation ne suit pas celle des transitions, attention à la profusion de préfixes.

BEM et ses petits problèmes

J’ai utilisé une notation de type BEM pour les classes CSS. Je l’utilise depuis quelques projets, et je dois reconnaître que cette notation est assez agréable et pratique : c’est clair et informatif.

Ne me demandez pas pourquoi je suis parti en inversant l’utilisation du -- (normalement les modifieurs) et celle des __ (normalement celles des éléments enfants), j’avais codé la moitié du template quand je m’en suis rendu compte. Ceci dit, ce n’était pas gênant, un simple commentaire au début de la CSS fixe l’information, et… indiquer le style de notation au début de chaque CSS est devenu un standard dans mes intégrations, justement pour éviter à celui qui reprendra de devenir dingue si je recommettais cette petite inversion.

Mais ! Car il y a un « mais », bien sur. Utilisant massivement du SVG pour des images de contenu, j’ai utilisé la méthode citée plus haut pour permettre aux vieux Internet Explorer d’avoir une roue de secours en PNG. Et malheureusement, il m’est arrivé d’avoir à adjoindre des classes sur ces éléments.

Autrement dit, des classes module--enfant se sont retrouvées prises dans des commentaires conditionnels ou plus simplement dans des commentaires HTML tout simples. Patatrac, le validateur ne supporte pas que la chaîne -- soit dans un commentaire ! Verbotten, warning, niet, nada, que dalle. J’ai même proposé un bug à la spécification HTML5 (car c’est également gênant pour utiliser les futures variables CSS), mais on m’a aimablement répondu de passer mon chemin. :)

J’avoue que si je dois réutiliser BEM avec beaucoup de SVG, cela va me poser quelques gros soucis. Une première piste serait d’utiliser les tirets cadratin ou demi-cadratin (ce que j'ai fait pour certaines classes), mais ce n’est pas excessivement pratique. Affaire à suivre !

En conclusion

Ce projet a été l’occasion pour moi d’utiliser des choses que je ne fais pas souvent, et de maintenir un projet pas toujours simple. Animations/transitions CSS, SVG, etc. C’est un vrai régal à utiliser. Quand les vieux navigateurs qui ne supportent pas SVG auront dégagé, on va vraiment se régaler comme des cochons ! :)

De plus en plus, j’apprécie de coder moi-même les demandes en jQuery, même si je ne suis pas encore une brute dans ce domaine, loin de là ! :)

Ce qui est par contre terrible, c’est que je doive encore autant hurler pour défendre un site fait main au lieu d’une usine à gaz de 7 Mo. Sérieusement, les jolis effets, etc., c’est sympathique, mais il serait temps que les chefs de projet, les techniciens, etc. refusent de vendre leurs âmes à des clients qui demandent des trucs à côté de la plaque. Je suis peut-être un peu dur, mais des usines de 7 Mo, c’est un non-sens absolu, cela ne devrait pas exister, et cela ne devrait pas arriver qu’un client puisse nous demander ça parce qu’il l’a vu !

Côté mauvais points, j’ai également maudit Webkit à plusieurs reprises, notamment via sa gestion catastrophique des valeurs avec des décimales (j’ai dû revenir aux pixels dans certains cas, fort heureusement pour des images seulement).

Si vous êtes curieux, la feuille de style est joignable en ligne directement : CSS de Parenti Design. Définitivement, produire des feuilles de styles maintenables n’est plus un luxe, mais un pré-requis pour éviter de sombrer dans une dépression nerveuse quand il faut y revenirֺ… à bon entendeur ! :)

Pour en finir avec les bénéfices induits de l'accessibilité (le 11/07/2014)

Ce sujet déchaine trolls et passions de temps à autres dans la « web-accessibilitosphère », certains disent que ce sont de bons arguments, d’autres qu’ils sont faux et dangereux, etc.

La CRAW n’y a pas échappé, et les experts – mais pas qu’eux – se bouffent le nez régulièrement sur le sujet, surtout quand on parle de vendre de l’accessibilité.

Je vous propose un point sur ce sujet, et mon avis personnel.

C’est quoi au juste, les bénéfices induits de l’accessibilité ?

Grosso modo, l’idée est de dire que travailler l’accessibilité d’un site amène d’autres bénéfices induits :

  • des progrès en SEO
  • des améliorations sensibles en performances (code plus léger)
  • des progrès en ergonomie
  • des améliorations en Green IT
  • etc.

Vrai ou faux ?

C’est un point qui divise, certains disent que ces bénéfices sont faux, d’autres qu’ils sont vrais. En toute honnêteté… ça dépend !

En fait, cela dépend d’où vous partez. Prenons un exemple donné : imaginons un site partant de très très loin en accessibilité. Si vous travaillez l’accessibilité de ce site, vous allez devoir mettre par exemple une structure de titres (h1, h2, etc.), ce qui sera bon pour le référencement (c’est une optimisation SEO dite on-site, c’est ce que vous faites sur le site pour qu’il soit mieux indexé).

Imaginons que vous amélioriez vos formulaires : lier les champs à leurs étiquettes va permettre par exemple de pouvoir cliquer sur l’étiquette pour cocher une checkbox : c’est pratique pour l’ergonomie (une case à cocher est pénible à viser sur mobile avec mes gros doigts, ou avec une souris sur ordinateur).

Côté performances et Green IT, je ne vais pas détailler, Olivier Nourry l’a déjà fait mieux que moi dans un superbe article sur OpenWeb : l’accessibilité c’est bon pour la planète. De sa grande expérience d’expert accessibilité, il a constaté des effets collatéraux à l’accessibilité. Il n’est pas le seul à l’avoir constaté : Denis Boudreau avait constaté aussi cela dans une conférence à Paris Web.

Ce ne sont que quelques exemples, je peux en trouver pleins d’autres : une transcription textuelle d’une vidéo permettra de mettre ces contenus à disposition des moteurs de recherche, etc.

Globalement, ces bénéfices induits existent bien… dans certaines limites.

Jusqu’où vont ces bénéfices induits ?

C’est là qu’il faut être honnête : travailler l’accessibilité offre effectivement des bénéfices induits dans d’autres domaines, mais l’accessibilité n’a jamais été, n’est pas et ne sera jamais une condition suffisante pour avoir un 20/20 dans ces autres domaines.

En même temps, c’est complètement logique. Pourquoi aurait-on des experts SEO, performance, ergonomie, etc. s’ils suffisait de mettre en accessibilité un site pour que tout soit parfait ? Vous pensez bien que ces experts se seraient reconvertis en experts accessibilité si avec l’accessibilité ça réglait tous les problèmes !

Donc celui qui vous vend de l’accessibilité en disant que cela va vous régler tous vos problèmes est soit très optimiste, soit malhonnête intellectuellement parlant ! D’ailleurs, on parle toujours des bénéfices induits dans ce sens, mais il suffit de tourner le problème dans l’autre sens pour s’en convaincre.

Quand je travaille les performances d’un site, ça peut servir l’accessibilité : l’utilisateur d’une synthèse vocale attendra moins longtemps si la page est servie deux fois plus vite parce que j’ai activé la compression GZIP. Mais bien évidemment, vous pensez bien que servir une page deux fois plus vite ne suffira pas à la rendre accessible !

C’est comme si je prenais un expert plomberie pour régler un problème de performance énergétique de ma maison : certes une plomberie en bon état et bien conçue améliorera la performance énergétique de ma maison, mais ça ne suffira pas à tout régler !

Cela a l’air bateau mais je le redis : travailler l’accessibilité offre des bénéfices induits, mais ces bénéfices ne seront pas suffisants au point d’oublier de travailler les autres domaines qualitatifs d’un site Web.

Vendre l’accessibilité sur les bénéfices induits ?

C’est un des points sur lesquels le débat fait souvent fureur. Certains disent qu’il faut utiliser les bénéfices induits pour vendre l’accessibilité, d’autres que ça ne marche pas pour vendre l’accessibilité, etc.

Pour ma part, j’ai envie de dire « et pourquoi pas ? », sous certaines conditions.

Je vais encore énoncer un lieu commun : on parle de bénéfices induits. Donc ce sont des bénéfices… induits ! Ils viennent avec la mise en accessibilité d’un site. À la base, on fait une mise en accessibilité pour être accessible, et tant mieux si on a des avantages en prime. Tant qu’on vend des bénéfices induits comme tels. Celui qui vous dit : « je vais faire un site super-accessible comme ça vous serez premier sur Google » est soit un idiot, soit très malhonnête. Comme je l’ai dit précédemment, si je veux améliorer mon référencement, je vais embaucher un expert en référencement.

Selon moi, vendre l’accessibilité uniquement sur les bénéfices induits est malhonnête et c’est voué à perte. Par contre, utiliser honnêtement les bénéfices induits pour aider à vendre l’accessibilité… où est le problème ?

Regardez le domaine de la performance : souvent, quand on veut vendre de la performance, on utilise l’argument massue qu’une baisse des performances d’un site fait baisser les conversions. Jusqu’à preuve du contraire, c’est un bénéfice induit, et absolument personne ne se gêne pour l’énoncer quand on veut vendre de la performance ! (et moi le premier)

Alors pourquoi se gênerait-on pour utiliser honnêtement ces arguments selon les cas ?

Considérations plus globales

Quand on se pose des questions, il faut revenir aux bases. Reprenons la définition du « Web pour tous » de Sir Tim Berners-Lee :

Mettre le web et ses services à la disposition de tous les individus, quels que soient leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales.

Bigre, vaste mission ! L’accessibilité, c’est du sérieux dans cette mission. :)

Sérieusement, vous croyez qu’une telle mission se résout en argumentant sans fin sur des détails ? Vous croyez que la personne qui est en situation de handicap en a cure de savoir si c’est bien de consacrer votre énergie sur des querelles de trolleurs ? Je sais que le diable se cache dans les détails, mais là on n’est pas au niveau des détails, que diable !

Combien de personnes vous auriez pu sensibiliser pendant ce temps ? Je ne parle pas de ligoter quelqu’un que cela n’intéresse pas et de le forcer à écouter, mais de produire de l’information pour ceux qui en veulent. Il y a une armée de gens qui ont besoin d’informations, d’exemples, de démonstrations, de sensibilisation. Il y a besoin d’experts, d’intermédiaires, de communicants, de rigolos, de débutants, etc. Vous me dites que ça a été déjà fait ? Mais voyons, je ne pouvais pas être là à l’apéro accessibilité de la semaine dernière. Et d’ailleurs, il a eu lieu ? Et au fait, je ne connais pas tous les sites par coeur, donc ne m’en voulez pas si je n’ai jamais lu le vôtre qui parle du point sur lequel je pose une question que vous avez peut-être entendue 666 fois.

Vous êtes un héros fatigué ? C’est humain, et c’est votre droit. Formez votre succession alors, entrainez des héros. Si si, il y a plein de gens que ça intéresse.

Revenons aux arguments pour vendre l’accessibilité. J’affirme haut et fort que pour que l’accessibilité progresse, on n’a pas besoin d’un argument parfait, le monde n’est pas composé de 0 et de 1. Il nous en faut plein. Nous sommes bien d’accord, il y en a de plus forts que d’autres, il y en a de plus vrais que d’autres, certains sont plus longs que d’autres. Tout a été fait ? Ah non, je peux vous donner au moins 10 idées que je n’ai pas encore vues.

Mais la cause est trop importante pour s’handicaper de considérations trollesques, cette cause ne souffre pas de divisions, même si on n’a pas tous le même point de vue. Pas convaincu ? Mais qu’est-ce qui est le plus important, la gloire de l’accessibilité et de l’Universalité du Web… ou la vôtre ?

Et un jour, vous aurez une personne qui vous contactera sur votre site, vous discuterez par email, peut-être vous la rencontrerez. Et suite à cela, vous vous rendrez compte que… vous ne vous étiez pas rendu compte que cette personne était aveugle (par exemple). Vous ne vous seriez jamais croisés dans aucune des 4 dimensions. Et là, vous aurez compris que l’Universalité du Web, c’est vraiment quelque chose. Qui ne s’apprend pas dans un article.

Compte-rendu de la CRAW 2014 (le 02/07/2014)

C’était la troisième édition de la Conférence Romande sur l’Accessibilité du Web, aussi appelée CRAW 2014. Comme l’année précédente, elle a eu lieu à Lausanne. Entre nouveautés, très bonnes surprises, semi-déceptions relatives, c’est une édition différente mais toujours intéressante à laquelle j’ai pu assister.

Petit compte-rendu non personnel non-exhaustif, une des nouveautés de cette édition étant des conférences en parallèle durant l’après-midi, donc… je n’ai pas pu tout suivre.

Conférence Romande sur l’Accessibilité du Web

Introduction : le web universel

Carine Rivière nous a rappelé le principe fondateur du Web, à savoir son universalité. Suivi de nombreux exemples de situations de handicap, etc. Toujours bon de le rappeler !

L’accessibilité du web et les seniors

Gros sujet que celui-là ! Présenté tambour battant par Ophélie Durand, elle nous a éclairé sur :

  • la silver economy, l’économie en rapport avec les seniors ;
  • les stéréotypes sur le rapport aux nouvelles technologies qu’ont les personnes âgées ;
  • les principes de conception universelle (on fait un site pour tous, pas un site pour chaque population/handicap/etc.) ;
  • etc.

Curiosité : alors que nous étions en Suisse, l’Europe s’est invitée dans le sujet, notamment via les initiatives sur l’accessibilité via la commission européenne ! Toujours bien en ces périodes d’euro-scepticisme de voir des initiatives de ce genre, surtout que… je n’en savais rien. :)

Sécuriser l’accès à l’information : un prérequis à toute démarche qualité web

Ce sujet, enfin son traitement, m’a beaucoup gêné.

  • Non pas qu’Armony Altinier ne soit pas compétente en matière d’accessibilité – c’est une des personnes que j’admire le plus dans ce domaine, notamment via son livre sur l’accessibilité mais pas seulement – ;
  • non pas que le fond du propos était mauvais – il était bon.

Mais certaines maladresses ou exagérations dans la forme m’ont empêché de rentrer dans la présentation.

Typiquement, dire que les bénéfices induits ne marchent pas quand on veut « vendre » de l’accessibilité, c’est un peu exagéré (pour ma part, ce sont des arguments qui marchent et qui sont entendus par mes clients, si tant est qu’ils soient vendus pour ce qu’ils sont : des bénéfices induits).

Autre point qui m’a dérangé : la démonstration pour prouver que l’accessibilité n’apporte pas le référencement en bénéfice induit était inexacte. Prendre n’importe quelle requête (là « hôtel » en l’occurrence), prendre le premier résultat, constater que le site n’est pas accessible et en déduire que l’accessibilité n’amène pas le référencement… non !

Cette démonstration prouve juste que l’accessibilité ne garantit pas un référencement en tête : était-ce bien utile de le démontrer ? (sinon les experts SEO seraient tous des experts accessibilité, ou du moins ils se seraient reconvertis)

Sur ce sujet des bénéfices induits de l’accessibilité, j’écrirai dès que possible un billet afin de préciser ma pensée.

Ajoutons à cela que dire « on code moderne pour l’accessibilité » est dangereux selon moi (surtout en prenant comme exemple la conférence de Sébastien Delorme, qui montrait comment il avait dû hacker des référentiels pour être accessible). À mon humble avis, on fait de l’accessibilité pour des gens, pas pour des référentiels ni pour des standards (si on doit enfreindre un référentiel accessibilité pour être accessible dans un cas donné, il faut le faire selon moi).

Dommage, car d’excellents points trop souvent oubliés ont été mentionnés :

  • l’accessibilité n’est pas là pour choisir quels contenus sont pertinents, mais pour permettre à tous d’accéder aux mêmes contenus ;
  • l’accessibilité n’est pas là pour faire des choix ergonomiques, juger du beau, du plaisant ou des goûts ;
  • l’accessibilité est de la responsabilité de toute la chaîne de production du site (chacun a son rôle à jouer et doit le jouer).

Bref, selon moi – et c’est mon avis uniquement –, un sujet en demi-teinte, qui mériterait plus de temps et beaucoup plus de nuances.

L’accessibilité des informations dans les transports publics

Sujet intéressant surtout – selon moi – pour la mise en perspective : Werner Hofstetter nous a donné un panorama de l’accessibilité dans les transports. On a tendance à l’oublier, mais l’accessibilité n’était tout bonnement pas prise en compte il y a une trentaine d’années. Comme il l’a bien expliqué, ce sont des chantiers permanents, en progrès constant mais qui sont toujours insuffisants.

Les fausses-bonnes idées (notamment via les automates) ont la vie dure, mais en même temps comment ne pas apprendre sans faire d’erreurs ? Au final, il nous a expliqué les idées futures pour permettre une meilleure accessibilité, ce qui est prometteur mais qui pose de nombreuses questions.

À noter, il a présenté son sujet sans slides, pour que nous soyons dans la même situation que les non-voyants. Initiative originale :)

Accessibilité et handicap cognitif

Sujet présenté par Monique Brunel, alias @webatou sur Twitter, experte accessibilité de son état, éminente membre d’OpenWeb, et grande dame du Web francophone à mes yeux (mais pas seulement).

Que dire de plus ? La présentation est un spectacle vivant – vu la patate de l’oratrice – en plus d’être super-intéressante. Elle y a rappelé de nombreux principes que nous oublions parfois et qui pourtant peuvent tant servir nos sites, nos utilisateurs, l’accessibilité, etc.

J’ai particulièrement apprécié cette réplique :

Je perds parfois tant d’énergie à lire le texte que je n’en ai plus pour comprendre ce que je lis.

C’est quelque chose que j’oublie souvent honteusement : les difficultés de lecture consomment beaucoup l’énergie des lecteurs. J’y trouve un écho avec l’Accessiday ou Sophie m’expliquait que suivre une conférence non-vélotypée lui demandait également énormément d’attention, d’énergie et donc cela la fatiguait beaucoup.

Rien que pour m’avoir permis de mieux (re-)comprendre ça : merci à vous deux mesdames ! :)

Responsive web design, périphériques mobiles et accessibilité

Ce sujet présenté par l’inénarrable Victor Brito, live-tweeteur fou qui retransmet de nombreux événements web pour le plaisir des absents – et surtout expert accessibilité de son état. D’ailleurs, j’ai essayé de live-tweeter sa présentation, sûrement pas aussi vite qu’il l’aurait fait, et en juste retour des live-tweets qu’il a pu faire. Grand bien m’en a pris : cette présentation était excellente.

Ne vous déplaise – en dansant la javanaise, clin d’œil à sa dualité Gainsbourg/Gainsbarre –, ce joyeux luron a parfaitement posé et maitrisé son sujet. Partant de points d’accessibilité donnés, il a parfaitement montré que le responsive (dans les usages et les possibilités) apporte des solutions pour l’accessibilité.

Un exemple parmi d’autres : la gestion du zoom texte. Moi le premier, je m’étais toujours dit que c’était proprement impossible de gérer un zoom texte à 200% sans que le graphisme pète à un moment ou que ce soit innavigable. Or, le responsive et les média-queries, le tout allié à une construction en em permet de trouver une solution élégante et au final assez simple à un problème d’accessibilité qui a été longtemps épineux (en tout cas pour moi).

À noter aussi : afin de ne pas mettre les personnes non-voyantes en situation de handicap lors de ses démonstrations en live (caméra braquée sur son mobile), il a improvisé une audio-description. Pertinent pour faire comprendre aux utilisateurs qui n’étaient pas en situation de handicap ce que cela fait d’y être !

Atelier : ARIA et HTML5

Atelier présenté par Jean-Pierre Villain et Armony Altinier, l’idée était de montrer comment ARIA permet de rendre plus accessible une application ou un site, à travers des exemples concrets, et live-codés tant qu’à faire.

Semi-déception pour ma part : non pas que la présentation n’était pas bonne – elle était excellente et très drole – mais j’aurais voulu en voir beaucoup plus, le duo fonctionnait très bien ! (ceux qui ont déjà vu une présentation de Jean-Pierre Villain comprendront, c’est un spectacle unique en son genre)
Le live-coding est un exercice difficile, j’ai beaucoup de respect pour ceux qui osent tenter ça, mais il faut une option « débordement de temps » ou un atelier plus long. :)

Je reste persuadé que la démo est un point clé pour démocratiser l’accessibilité web : c’est con à dire, mais quand on me montre en pratique, je comprends mieux et j’y intègre mieux. Ajoutons à cela que l’utilisation d’une aide technique – par exemple une synthèse vocale – est souvent de la science-fiction pour 99% des personnes.

Consolation : l’atelier est disponible en ligne.

Autour de l’événement

Que dire, de très bons intervenants, une organisation tip-top, le tout dans une ville très agréable (j’aime bien me balader dans Lausanne), c’est un bon cru.

À titre personnel, ma wishlist pour l’édition suivante :

  • toujours des exemples pratiques, il faut montrer des choses en pratique pour faire comprendre ;
  • de l’ARIA à toutes les sauces ;
  • rabâcher les bases qu’on oublie trop souvent ;
  • et pour cet accroc de sujet sur la qualité, qu’on ait d’autres paroles d’autres personnes sur le sujet.

N.B : je n’aurais pu y assister sans la complicité de Telono (les organisateurs de l’événement). Qu’ils en soient infiniment remerciés, cette journée a été un bol d’air frais dans une période très difficile.

Amélioration progressive et obsolescence programmée (le 04/06/2014)

L’autre jour, mon iPad étant temporairement occupé par un adorable bambin squatteur, je me suis dit « tiens, je vais ressortir mon iPod Touch et me faire une partie de 2048 ».

Ce vénérable iPod touch est dit de troisième génération, je me le suis offert courant 2009, c’est même lui qui m’a mis sur les rails des sites pour mobiles, mais c’est une autre histoire. Il a donc 5 ans. Je m’en sers encore comme réveil et pour de petits jeux, des sites, etc.

Je vais sur l’Appstore, j’essaie de télécharger un 2048 (il y en avait au moins 5 ou 6 versions), à chaque fois, je me prends le même message « Incompatible avec votre version de iOS ». Je tempête contre ça : « un jeu aussi simple, merde, ça devrait marcher dessus sans souci, faut pas déconner », et plein de mots vulgaires.

Fuck you vieil iOS

Je décide d’utiliser la version web… elle marche. Non seulement elle marche bien, mais elle prend en compte mes frénétiques mouvements de doigts pour obtenir le sésame, donc une tuile 2048.

Je décide de lancer l’application Twitter, plantages sur plantages. Je vais sur la version Web, certes ce n’est pas extraordinairement rapide, mais je peux l’utiliser sans souci. J’avais entendu que Twitter utilisait l’amélioration progressive sur la version Web, et le moins qu’on puisse dire, c’est que j’en ai été content, je pouvais faire ce dont j’avais envie.

Bref, c’était le jour où Twitter et 2048 m’ont tout fait comprendre sur l’obsolescence programmée, et sur l’importance critique du concept d’amélioration progressive pour des sites/applications Web. Je savais que ces sujets étaient importants, mais je n’y avais jamais été confronté de manière aussi directe en moins de 5 minutes.

On ne devrait jamais négliger ce principe de permettre aux vieux matériels/navigateurs d’utiliser un site.

Et si l’amélioration progressive pouvait sauver le monde de l’obsolescence programmée ? Et si vous, vous pouviez sauver le monde en pensant ainsi ?

Première édition d’Accessiday, compte-rendu (le 02/06/2014)

Grâce à la grande aide logistique de mon régulateur de vitesse qui m’a permis d’économiser ma fatigue durant le trajet, j’ai eu le plaisir de participer à la première édition de l’Accessiday, une journée entièrement dédiée à l’accessibilité des sites Web, organisée à Caen. L’événement a été organisé par Willy Leloutre, avec le soutien du conseil régional de Basse-Normandie, d’Atalan, de Temesis, le Pole Tes et le groupe de communication Normand XCOM.

Accessiday

Cette première édition a été réussie : des conférences toutes plus intéressantes les unes que les autres ont émaillé la journée. Petit résumé rapide de celles que j’ai pu suivre, je n’ai malheureusement pas eu le don d’ubiquité pour suivre celles qui se passaient au forum numérique.

L’accessibilité numérique, mais au fait, de quoi on parle ?

Delphine a rappelé quelques grands principes sur l’accessibilité : on ne parle pas de personnes handicapées mais bien de personnes en situation de handicap, c’est dans une situation que l’on peut être ou se retrouver en handicap. Et quoi qu’on en dise, cela peut arriver à tout le monde, qui n’a jamais eu de souris qui tombe en panne par exemple ?

L’accessibilité a d’immenses bénéfices collatéraux : SEO, ergonomie, image de marque, etc. C’est un processus qui vise l’utilisateur avant tout.

Puis elle a montré des ressources pour pouvoir s’y mettre. Ses slides sont une mine d’informations et un excellent résumé du sujet, à lire de toute urgence.

L’accessibilité des objets connectés

Sophie nous a présenté le très vaste sujet des objets connectés. Montres, smartphones, tablettes, objets divers et variés, etc. ont toutes sortes d’utilisations et leur présence est en constante augmentation.

Leur accessibilité est un enjeu énorme : ils permettent pour les personnes en situation de handicap de s’équiper pour beaucoup moins cher qu’avec des outils dédiés pour leurs besoins, avec des possibilités en plus. C’est pour cela que je dirais que ce sujet était aussi l’accessibilité par les objets connectés. :)

Elles nous a sensibilisés à ce sujet avec brio en expliquant des mises en situation personnelles, je reconnais que j’étais ignare sur le sujet, je n’avais pas mesuré l’importance de ces objets souvent vus comme des gadgets dispensables, alors qu’ils peuvent être source d’inclusion pour des personnes.

Un sujet original et très instructif, les slides sont en ligne : L’accessibilité des objets connectés.

L’accessibilité des applications web mobiles

Sébastien présentait ici un retour d’expérience sur un grand projet d’application web mobile accessible. En faisant participer le public, il nous fit proposer des bouts de code accessibles, ou du moins supposés l’être. Ensuite, il nous propose des retours d’expérience où ces bouts de code se révèlent être une catastrophe pour les utilisateurs, que ce soit à cause des synthèses vocales ou de problèmes d’implémentation ou autres.

Cette conférence était une très bonne surprise pour ma part : ni plus ni moins qu’un retour rapide sur « la théorie » versus « la réalité », où il a dû sciemment enfreindre des recommandations pour servir l’utilisateur final.

Les slides sont dispo : L’accessibilité des applications web mobiles.

Les contrastes des textes

Là, je serai incapable de dire si le sujet était intéressant, vu que c’était le mien. J’ai essayé de le faire aussi accessible que possible, quitte à simplifier la théorie, comme me le fera remarquer Aurélien dans les remarques.

Là, il faudra demander à quelqu’un d’autre pour avoir un avis. Je n’ai pas été super-content de ma prestation, même si des retours positifs m’ont été faits.

Mes slides sont disponibles : Les contrastes des textes.

Les techniques d’intégration d’icônes-liens

Johan Ramon nous offre encore un super sujet, très bien maitrisé et bien illustré. J’avoue que je n’avais jusqu’à cette conférence pas compris les implications du mode de contraste élevé sur les background CSS. Là, c’était lumineux, ce mode remplace les couleurs de fond, plus qu’à supposer que cette couleur se marie mal avec l’image en question, et patatrac.

Il étudiera plusieurs solutions (sprites, etc.), chacune ayant leurs points forts et leurs inconvénients. Au final, une bonne leçon d’humilité pour l’intégrateur que je suis !

Ses slides sont disponibles : Les techniques d’intégration d’icônes-liens.

Vous êtes tendance, vous êtes digital, vous connaissez ARIA ?

Aurélien n’en est pas à son premier coup d’essai sur ARIA, il a déjà – entre autres – écrit sur le train de 13H37 sur le sujet : ARIA, il serait temps de s’y mettre !

Que dire de plus : excellent sujet maitrisé, des exemples parlants et pratiques, une présentation aux petits oignons. Il envoie du lourd comme on dit en langage familier.

Il ne fut pas le seul à le dire : on a besoin de « hacker la spec ». Autrement dit, d’essayer des choses, voir si cela fonctionne en testant en situation réelle. Il n’y a pas de vérité absolue, que des cas concrets à travailler.

JavaScript et accessibilité font-ils bon ménage ?

Stéphane Deschamps et Matthias Dugué ont fait le show, au sens propre comme au sens figuré.

Rivalisant d’humour l’un et l’autre, ils ont fait une excellente présentation, mêlant un brin d’histoire de l’accessibilité, de légendes urbaines, d’actualités, de retours d’expériences, de mises en perspective. Bref, JavaScript et accessibilité font très bon ménage, encore une fois, avec de l’ARIA dedans. D’ailleurs, ils m’ont donné plein de bonnes idées, se baser sur ARIA pour des classes d’état en CSS notamment (faut que je mette en application dès que possible).

Rafraichissant et délicieusement sérieux sans se prendre au sérieux. Mais jusqu’où iront-ils ?

Bonus, un petit mot de Karl Groves

Nous avons eu droit à un petit mot de Karl Groves, un des plus grands experts mondiaux de l’accessibilité Web. Que dire de plus, si ce n’est un petit caviar sur une journée déjà délicieuse ?

En bref

  • Les retours d’expériences des experts montrent bien que l’audit lourd en fin de projet sans suivi n’est plus une option, l’accessibilité doit se faire au fur et à mesure.
  • C’est vraiment un sujet d’experts, et on a vraiment besoin d’experts accessibles comme on en a eu lors de cette journée.
  • ARIA est incontournable, même si ça n’est pas obligatoire pour concevoir accessible.
  • La spéc ne doit jamais prendre le pas sur les utilisateurs réels.
  • Testez, testez, testez. Et faites des essais, parlez-en, confrontez. L’accessibilité, ça a besoin de gens qui mettent les doigts dans le cambouis pour huiler les sites. Même de manière imparfaite.

À titre personnel

Le co-directeur d’OpenWeb qui sommeille (peu) en moi a été ravi de voir que les idées et les approches que défend ce collectif depuis bien des années ont été « pertinentées » à de nombreuses reprises, et les propos que j’ai entendus ont fait honneur à de nombreux articles qui y ont été publiés.

Les conférences sur l’accessibilité font beaucoup de bien, car elles me font comprendre beaucoup de choses sur la différence, sur des handicaps, bref, sur la variété du monde, et « c’ai bien ».

J’ai eu plein de bonnes idées qu’il me tarde de mettre en application !

Ajoutons à cela que j’ai pu retrouver une bonne partie de personnes que je suis sur Twitter, du coup une très joyeuse équipée a été là depuis la veille jusqu’à l’after. Sortant de quelques semaines très dures au travail, ça m’a fait vraiment du bien, à un point que vous ne pouvez pas imaginer… Mention à Pascale que je n’avais pas pu serrer dans mes bras depuis 3 bonnes années, une de mes héroïnes du Web parmi plein d’autres sur place.

Bref, l’Accessiday, c’était vraiment top, ça a poutré des coincoins, bravo à tous et surtout aux organisateurs, et « à Caen la prochaine fois ? ».

Des limites et des choix (le 08/05/2014)

Que ce soit clair : je ne veux rien démontrer dans ce billet, ce sont justes des pensées livrées en vrac.

L’autre jour, je me posais la question de savoir de où me venait cette manie de toujours chercher les conditions limites d’une approche ou d’une façon de penser. J’en ai parlé souvent ici, notamment dans le manque de recul.

En fait, j’ai trouvé cette réponse en postant un tweet suite à un coup de gueule. Partant de l’idée que je suis simplement « dépendant » des choix que je fais – « dépendant » dans le sens « la conséquence logique de ces choix » – en fait, c’est assez simple.

J’ai besoin de voir les limites ou les conditions limites d’un choix pour savoir dans quel cadre je vais évoluer, où seront posées mes limites. En fait, un choix ne me satisfait que si je n’en arrive pas trop vite à ses limites (ou bien sûr si je m’en accommode bien).

En matière d’intégration CSS, je crois que trop de choix par besoin de se rassurer ont été faits, avec la conséquence de trop de cloisonnement. D’ailleurs je constate que bon nombre de personnes reviennent de ces choix trop cloisonnants, juste pour se sentir plus libres de ces cadres. Non pas que les choix soient mauvais, il faut en faire et les pousser dans leurs retranchements, c’est aussi comme ça qu’on progresse.

Un simple vent de liberté ? Une maturité à venir dans ce domaine ? Je ne sais pas.

Curieusement, le choix que nous n’avions pas fait il y a des années (rigueur et organisation) pour être libres nous a cloisonné dans des CSS peu maintenables. Par réflexe ou contre-réaction, nous sommes allés vers l’exact opposé, des outils très rigoureux, très cadrants mais très « délégants » (comme les pré-processeurs), si vous me permettez cette expression.

Et finalement, peut-être redécouvre-t-on en CSS une maxime qui ne date pas d’hier, à savoir « Be strict to be cool ».

D’ailleurs, cochon de sort, je recherche cette maxime pour savoir d’où elle me venait, et je tombe à deux reprises sur des membres du collectif OpenWeb (le premier lien est de Karl Dubost, le second parle d’Élie Sloim, Laurent Denis et d’autres).

Amusante coïncidence que de retomber sur les bases en cherchant autre chose…

Les unités en CSS (le 09/04/2014)

Je viens de voir passer une traduction sur Pompage à propos des unités en CSS, et j’avoue être surpris de certains choix.

Je vous propose mes habitudes personnelles en la matière (pas une vérité absolue, ça dépend comme on dit).

Les pixels (px)

Ils sont toujours utiles, en tout cas pour discuter avec un graphiste, s’accorder sur une idée générale, etc.

Mais en CSS, je reconnais que je les utilise maintenant très peu. Hormis une taille fixée arbitrairement (ça peut arriver), pour les bordures, les ombres portées, faire un hr, des fois pour fixer quelques éléments de formulaires, des coins arrondis… et encore !

Je les ai par contre totalement bannis de la typographie et de tout ce qui peut l’impacter, notamment sur le reset sur html ou body.

Les pourcentages (%)

Je les utilise beaucoup pour des grilles et tout ce qui doit/peut être fluide. C’est toujours utile pour qu’un site pas prévu pour être redimensionné le soit in fine. Une valeur sûre !

Les em

Clairement, depuis 2 à 3 ans, c’est l’unité que j’utilise le plus. En fait, elle sert à tout ce qui doit/peut être proportionnel à la typographie. Et comme énormément de choses peuvent être fonction de la typo en matière de web (margin, padding, width ou max-width pour éviter des lignes trop longues, etc.), je les utilise énormément.

Utiliser cette unité me permet beaucoup de choses, le tout en permettant de respecter les préférences de l’utilisateur, et en permettant un zoom.

Sur les sites en responsive, les media-queries en em ont des avantages indéniables, par exemple, zoomer fortement sur le site de Prezenz vous fera afficher la « version » mobile en très gros caractères sur votre ordinateur (même en zoom texte), cela permet d’avoir à tout instant une version dont les contenus sont agréables à consulter.

Certaines classes atomiques de RÖCSSTI me permettent même d’avoir un niveau d’abstraction, je ne fonctionne par exemple plus en pixels pour ajouter une marge, mais en em, c’est tellement plus pratique, et cela permet de respecter par exemple plus facilement les calculs pour le rythme vertical du texte.

Certes ils peuvent être compliqués à gérer dans certains cas précis (genre beaucoup d’intervenants ne se rencontrant dans aucun dimension sur des projets très compliqués, et encore), mais la quasi-totalité de mes cas ne tombe pas dedans, pas d’excuse.

Les nombres bruts

Dans pas mal de cas, autant éviter les unités inutiles. Pour line-height, pas besoin d’unité, pour une valeur nulle (ex : border: 0;) non plus, autant utiliser une valeur auto dans d’autres cas, etc.

Autres

Hormis un cas d’utilisation bien précis dans RÖCSSTI (pour fixer un interlignage disgracieux en cas d’utilisation des balises sub et sup), je ne me sers jamais des ex. Idem pour les en, dont j’ignore même le support réel. Pareil pour les ch, je ne m’en sers jamais.

Idem pour les vh et vw (et autres vmin et vmax), leur support relatif et leur jeunesse font que je ne les utilise jamais (pas eu de cas pour le moment, mais cela va venir).

Hormis quelques cas bien particuliers pour le media print, je ne me sers jamais des mm et autres cm, idem pour les pt (points), les in inches) et les pc (pica).

Les rem sont très intéressants, mais comme je ne puis abandonner IE8 pour le moment, je ne m’en sers que très peu, cela me fatigue clairement de devoir gérer une solution de secours en em alors que je peux clairement tout faire en em les 99% de mes cas.

Il existe d’autres unités, mais elles sont tellement anecdotiques pour mon utilisation pratique…

J’essaie des trucs (le 08/04/2014)

Il y a quelque chose qui me dérange quand une nouvelle approche de CSS arrive, c’est que souvent la démonstration commence par poser le postulat que l’approche est géniale, ensuite elle démontre pourquoi elle est géniale, et enfin elle conclut qu’elle… est géniale – entre nous soit dit, beaucoup de « démonstrations » fonctionnent ainsi (et c’est accentué par les posts hautement argumentés que l’on peut faire sur Twitter… en 140 caractères donc).

Évidemment, sur mon esprit cartésien, ce genre de « démonstration » n’a que très peu d’effet.

Même si l’approche peut effectivement avoir de grands avantages, je préfère quand la démonstration part des problèmes donnés, se construit, montre ses conditions limites (important ce point, malheureusement trop souvent oublié), conclut sur ses avantages et enfin laisse aux lecteurs le plaisir d’en déduire si elle est géniale.

Souvent, quand je tombe sur ces nouveautés, je m’amuse à les tester, mais pas de manière brutale, de manière beaucoup plus progressive. Ainsi, je peux refaire le chemin de la réflexion, la pondérer, l’apprécier, l’infirmer ou la confirmer.

Un exemple : il y a quelques années, cela faisait un moment que bon nombre de tweets et billets martelaient qu’il ne fallait jamais utiliser d’id pour cibler un élément en CSS. Je passe sur les arguments qui disaient « c’est mal » sans aller plus loin et sur les arguments absolument débiles genre « c’est pas beau », les seuls arguments me semblant corrects étaient les suivants :

  • il n’est pas réutilisable ;
  • le poids est trop élevé par rapport aux classes.

Le premier argument n’était pas nouveau, c’est la définition même de l’id : il est unique. Le second méritait de s’y pencher.

Avec mon esprit de contradiction, je me suis dit : pourquoi poser comme postulat que le poids fort de l’id en CSS soit un inconvénient, alors qu’on pourrait tout simplement en tirer avantage ? Ma première idée était d’utiliser les classes pour styler, et le poids de l’id par exemple pour surcharger à coup sûr les propriétés dans une media-query pour mobile. Et figurez-vous… que ça marchait super bien ! Cela permettait de surcharger efficacement à peu près n’importe quoi avec un sélecteur court.

Sauf qu’en fait, cela marchait bien si on n’avait à effectuer que très peu de surcharges, une ou deux maximum, et surtout si l’on avait besoin de surcharger des sélecteurs avec un nombre de classes à rallonge (ce qui n’est pas bien, les performances déconseillent des sélecteurs trop longs). Sur des sites simples, ça fonctionnait bien (je me souviens l’avoir fait sur un ou deux sites), mais dès que cela se compliquait un peu, je me retrouvait à me trimballer soit des id à surcharger, soit à le faire sur les classes. Plus gênant, les id m’empêchaient même d’utiliser certaines classes utilitaires de RÖCSSTI.

Or, l’ordre dans RÖCSSTI a toute son importance : d’abord les propriétés générales, ensuite le layout global, ensuite le spécifique. Et idem dans les media-queries (ce qui facilite grandement la surcharge). Or là, l’utilisation un peu hasardeuse des id dans la CSS vient au mieux permettre ce qu’une classe bien utilisée permettait déjà, au pire gêner un des principes les plus importants de CSS : du plus général au plus spécifique.

Bref, en quelques essais, je m’aperçus que dans certains cas mon idée fonctionnait, qu’elle n’était pas fondamentalement mauvaise (elle n’a pas empêché certains sites de fonctionner), mais qu’elle dérangeait dans beaucoup d’autres. Par contre, je constatais en même temps que fonctionner avec des classes ne gênait pas : en fait tout le monde a le même poids, et c’est l’ordre de déclaration qui dicte le résultat final. Au final, un principe de base de CSS se retrouve mis en avant, et ça c’est plutôt un bon indicateur.

Bref, tout cela pour vous rappeler un principe : ayez vraiment l’esprit critique face à des articles de plus en plus percutants et des effets de mode : testez, évaluez, appropriez-vous, pondérez, etc. Non pas qu’il faille partir de l’idée que tout changement est à éviter, mais qu’il faut surtout en tirer la substantifique moelle comme disait Rabelais.

Je me permets de re-citer (oui, je le fais souvent) Mehdi Kabab dans un commentaire sur 24 jours de Web :

Intégrateurs, votre cœur de métier ne se limite pas à pisser du CSS au kilomètre. Vos compétences et le savoir que vous avez acquis à la sueur de vos erreurs (vive l’apprentissage par l’échec, la meilleure école de l’intégrateur/développeur Web) ont de la valeur. Alors, s’il vous plaît, ne les rejetez pas sous prétexte qu’un personnage influent clame tout haut une opinion personnelle, mais qui se répand comme une traînée de poudre de part son statut de « gourou ».

Et avant que cela ne trolle violemment dans les commentaires : avoir l’esprit critique n’empêche pas de tester comme un dingue et d’évoluer à vitesse grand V : je ne fais pas un site sans qu’il y ait un truc de nouveau, mieux, amélioré. Non pas que le site sera forcément mieux que le précédent, mais comme principe de base, il faut que j'améliore au moins un point dans chaque réalisation par rapport à la précédente !

Responsive webdesign et images de contenus en CSS (le 30/03/2014)

Sur un des sites que je viens d’intégrer, Vision Clinique pour ne pas le citer, j’ai eu le plaisir d’essayer quelques techniques pour améliorer l’utilisation des images sur un site en responsive, grâce à une discussion partie de rien avec mon graphiste. On appelle cela Art Direction for images en anglais.

Au début sur la page d’accueil, j’avais intégré l’image en width: 100%, l’image étant de taille assez conséquente (1600 pixels de large), elle s’adaptait tranquillement à la largeur de la fenêtre, en respectant les proportions de l’image, et point barre.

Mon graphiste me fait la remarque que sur son énorme écran de graphiste, quand il redimensionne, la zone de contenu est toute entassée en haut de l’affichage. Je remarque que le « problème » est également le même sur l’iPad en portrait. Autant son écran énorme en vision colonne me parait être un cas peu probable (ces graphistes… :) ), autant sur l’iPad… là je suis plus gêné. Il me fait remarquer au passage que le cadrage sur l’oeil n’est pas fameux, comme vous pouvez le voir sur cette capture d’écran. Gênant vu le sujet du site !

Vision Clinique en iPad en portrait avant retouche

On commence à chercher une solution pour améliorer cela. Je refuse d’entrée de jeu de commencer à rentrer dans le jeu « on fait une image dans tel cas, etc. » : on a une image de contenu, elle est suffisamment grande, hors de question de pourrir un code nickel avec des chargements en JavaScript. La solution sera en HTML/CSS sinon rien. Comme je l’ai dit plus haut, c’est une image de contenu, et je souhaite qu’elle le reste, ne serait-ce que pour la version imprimable (impossible de se reposer sur une image de fond CSS pour une version imprimable).

Je me dis : puisque c’est la largeur de l’image qui contrôle le tout, autant jouer dessus !

Le premier essai pour contrer le problème sur l’iPad donne ceci :

/* fait avec Sass pour le em(), à transposer en CSS */
@media (max-width: em(1024)) and (orientation:portrait) {
/* home */
.home-img-bg {
min-width: 190%;
margin-left: -50%;
}
}

Autrement dit, j’empêche l’image de se réduire drastiquement, et je la décale juste ce qu’il faut pour que le cadrage soit meilleur. C’est bien mieux !

Vision Clinique en iPad en portrait après retouche, avec code CSS affiché

Seul souci, vu que j’augmente la largeur de cette image, cela fait apparaître un ascenseur (scroll) horizontal. Impossible et hors de question. La solution sera tout aussi simple : ajouter un overflow: hidden sur le conteneur parent de l’image, comme l’indique la capture d’écran suivante.

Vision Clinique en iPad en portrait après retouche, avec code CSS affiché (overflow: hidden))

Bref, je passe les détails de mise au point (j’ai tâtonné pour trouver les bonnes valeurs, il faut juste faire quelques essais, je les ai souvent adaptées selon les résolutions), mais c’est assez simple à comprendre et à mettre en œuvre. Jouer sur le min-width permet de bloquer ou gérer le redimensionnement automatique de l’image quand la fenêtre se réduit, cela vous permet à peu près toutes les fantaisies de cadrage, à moindre coût, autant en CSS qu’en image. Simple et élégant.

J’ai d’ailleurs déjà réutilisé cette technique sur un autre site en cours d’intégration, pour résoudre quelques problèmes de contenus selon la résolution. Dans ce cas, au lieu d’utiliser un min-width en pourcentage, je l’ai mis dans une valeur fixe en pixel, ce qui évite de la réduire en taille.

Du coup, je me dis qu’on peut s’amuser en CSS mais sur des images de contenu, ce qui reste agréable !

Si vous avez d’autres techniques ou idées dans le genre, n’hésitez pas à les partager.

Ajout : apparemment, Internet Explorer 11 fait quelques bizarreries dans certains cas, j’ignore encore pourquoi, mais il semble qu’il ignore le min-width, en doublant d’un width avec la même valeur, le problème se résout tout seul.

Atlas a le blues (le 27/03/2014)

Entre autres grandes figures mythologiques,
Entre de nombreuses légendes anthologiques,
Figure Atlas, le porteur de l’immense voûte,
conscrit de Chronos, que tous redoutent.

Moins sombre que le terrible Hadès,
Moins guerrier que le puissant Arès,
Moins renommé que Zeus l’illustre,
Moins habile qu’Héphaïstos le rustre.

Pourtant, c’est le plus moderne des dieux anciens,
Je porte mon monde comme lui soutient le sien,
L’homme que je suis comprend cette souffrance,
Porter monde sur son dos, ainsi monde tance.

On vous aimera pour votre charisme d’acier,
On vous haïra également pour ce dernier,
Le même qui exactement force l’admiration,
Ou qui provoque l’ire… des sans-convictions.

Quand vous poserez un genou à Terre,
Tel Atlas, usé du poids de son calvaire,
Levant la tête, pour admirer les étoiles,
Porté-je aussi la voûte… et l’aurore boréale ?

Atlas est aussi le frère de Prométhée,
L’illustre qui a offert la Connaissance,
Est-ce si impossible, qu’aurait-il été ?
Portant son monde, et offrant la science.

Alors je me permets de le dire sans gène,
humble Openwebien et non grand Olympien,
Point d’hybris dans ce propos qui est le mien :
Parfois cher Atlas… je comprends ta peine.

Il est tard, je suis épuisé, mes épaules tombent,
Le poids du monde accable, mon dos bombe,
Héra, de ma voûte céleste ne sois point jalouse,
ce soir… Atlas a le blues.

Les héros ne sont pas éternels (le 25/03/2014)

Une certaine agitation a animé le Web, enfin surtout chez les développeurs, un certain gars a annoncé qu’il allait publier une liste de 100 développeurs francophones marquants (la liste s’est fait attendre pendant presque 3 semaines, tout le monde en a parlé sans l’avoir vue… mais elle vient enfin d’être publiée). À côté de cela, un « classement » des 50 développeurs francophones les plus suivis sur Twitter a également fait parler. D’autres listes sont sorties, etc. plein de gens y sont allés de leur bon mot.

Je passe sur le côté buzz de la première et sur le côté marketing de la seconde et la troisième, j’élude même totalement ces débats stériles, car ce n’est vraiment pas de cela dont je veux parler.

En fait, je fais un constat : dans la première, je connais environ 5 personnes, dans la seconde, j’en connais une grosse dizaine et la troisième, j’en connais également très peu.

Alors, je le dis de suite, je suis pas fan de ces listes, mais je ne dis pas que les personnes qui y sont listées sont incompétentes, loin de là ! De ce que j’ai pu voir, ce sont toutes des personnes très compétentes et sûrement très intéressantes. Le fait est que je n’ai pas le plaisir de tous les connaitre.

L’autre jour, je discutais au travail avec un débutant en intégration, et il me demandait des sites et des personnes de référence dans le domaine. Pris d’un accès de grandiloquence, je commence à vanter mes héros et héroïnes du Web (ce qu’ils/elles m’ont appris, ce qu’ils/elles représentent pour moi, etc.) et les sites que je trouve très bons, etc.

Sa réaction : j’en connais pas le quart.

Inutile de vous dire que j’étais un poil désappointé : je me suis dit « merde, il n’a jamais entendu parler de cela ou untel(le), et pourtant, c’est/il/elle est une référence ». Et pourtant, il n’est fondamentalement pas en tort, moi non plus du reste.

En fait, tout cela, c’est très relatif. Entre :

  • les courants (de développement) ;
  • les tendances ;
  • les rencontres, lors de conférences ou autres ;
  • les générations, et elles sont assez courtes en temps Web (j’en ai déjà vu 3 à 4), etc.

Après, je me dis que le statut de légende vivante du Web, c’est peut-être pour ceux qui justement sont (re)connus dans plusieurs de ces générations et qui durent. :)

En tout cas, une certitude : même si ces gens sont des diamants, les héros ne sont pas éternels (en tout cas dans le Web).

Autre chose, j’entends souvent des choses comme : « on n’a pas de développeur comme untel qui a une quantité monstrueuse de followers » ou des sorties du genre. Parfois c’est même à leur propre propos que certaines personnes s’exaspèrent de ne pas être assez (re)connues. Pipolarisation, égo, mal nécessaire ?

Je trouve ces propos absolument débiles. Avant de vouloir être aimé de la Terre entière, aimez déjà vos héros et vos héroïnes à vous, dites leur merci quand ils vous apprennent des choses, sans flatterie, juste votre reconnaissance. Et quand vous aurez suffisamment aimé vos héros et vos héroïnes, donnez autant qu’ils vous auront donné, et tout le reste n’aura plus d’importance

P.S : j’insiste bien sur le mot « héroïne », car en matière de Web, elles sont nombreuses mes héroïnes du Web, et elles n’ont rien à envier à mes autres héros.

Je partage mon ignorance (le 22/03/2014)

« Tu partages tes connaissances » entends-je souvent quand je parle d’articles ou d’astuces sur le Web. Effectivement, c’est vrai, je partage une connaissance, mais ce n’est vraiment pas comme cela qu’il faut le comprendre.

Il y a un an environ, j’ai du intégrer un paiement en ligne de type Atos-SIPS sur un hébergement donné. Ce n’était pas le premier paiement en ligne que j’intégrais, dans ce domaine, il y a des choses plutôt faciles et bien pensées… et le total contraire.

Manque de chance, la documentation fournie par la banque est quasi-inexistante, et le peu que je reçois est aride comme la Vallée de la Mort en période de sécheresse. En clair : je n’y comprends que dalle, même en épluchant la documentation en long, en large et en travers. Bien évidemment, devis serré, et j’ai déjà perdu à peu près un tiers du temps pour le faire.

En dépit, je commence à chercher une bouée sur le net, et je tombe sur ce tutoriel d’installation d'un paiement Atos-SIPS. Limpide, lumineux, juste parfaitement ce dont j’avais besoin pour sortir la tête de l’eau et comprendre.

À chaque fois que j’écris un article ou un billet, je me dis systématiquement que vu que j’ignorais ce que j’ai appris… il faut que je le raconte pour que si un jour quelqu’un se retrouve dans la même situation, il puisse trouver quelque chose (même un bout d’expérience). Au passage, le poser sur le papier numérique me permet de savoir que si j’ai un trou de mémoire, la connaissance sera à tel endroit. Röcssti, le fichier htaccess, diverses astuces, etc. ont été posés juste pour ne plus chercher dans mes ignorances.

Je me dis que si c’était un truc que j’ignorais ou avec lequel j’avais du mal, y aura peut-être quelqu’un qui est dans mon cas.

En fait, je ne partage pas ma connaissance, mais mon ignorance du sujet. Si vous lisez ce blog depuis longtemps, vous pouvez donc comprendre par quelles ignorances je suis passé, et vous verrez sûrement les prochaines ! :)

Non, tu n’as pas besoin d’être plus vieux (le 15/03/2014)

Derrière ce titre un poil énigmatique, je réagis à un propos lancé par Gaël Poupard dans un commentaire sur le blog de Monique Brunel.

J’aurais vraiment aimé être « plus vieux » : j’aurais pu vivre ces événements, suivre ces découvertes et participer à certaines avancées… En tentant de progresser, je tombe souvent sur des ressources de dix ans voire plus et je me demande : pourquoi suis-je confronté à un problème que quelqu’un a déjà résolu il y a si longtemps ? Pourquoi cette solution n’est-elle pas entrée dans les mœurs et les pratiques ?

Deux choses, déjà tu me permettras de te tutoyer, même si le tutoiement s’adressera à n’importe qui. :)

Ensuite, permets-moi de te dire, de mon statut de futur vieux con du métier, que tu n’as pas besoin d’être « plus vieux ».

Oui, tu peux te sentir débutant par rapport à certaines personnes, mais tout comme je me sens débutant par rapport à d’autres, sans même forcément aller chercher « plus vieux » que soi, par exemple, il y a des domaines où je ne suis pas à l’aise (voire à la ramasse)… même avec plus de 10 ans de métier, même après avoir écrit des dizaines d’articles sur plein de sujets divers et (a)variés.

Il y a bien quelques différences, je te l’accorde : effectivement, tu peux voir que plein de questions que tu te poses, d’autres se les sont déjà posées. Je reconnais que quand je me suis intéressé à CSS, les ressources de qualité étaient vraiment très maigres, ce qui est beaucoup moins le cas maintenant. Si tu en doutes, regarde le code du bandeau de ce site : tu noteras que j’ai mis des classes sur des éléments uniques, ce qui, à l’époque, n’était pas très logique, car on mettait surtout des id sur les éléments uniques. Actuellement, il y a plein de discussions sur le sujet.

Vois-tu, quand j’ai commencé à intégrer ce site, j’ai repris un bandeau que j’avais trouvé sur un forum, car je ne comprenais même pas complètement le sens d’utiliser des id ou des class, ni tout le reste (sémantique, etc.). Ce que j’ai fait à l’arrache sans tout comprendre, maintenant, tu as des tutoriels qui l’expliquent, donc finalement, ce n’est pas plus mal.

La mise en perspective

La seule différence, c’est qu’on a peut-être plus de recul. Et encore, tu es quelqu’un d’intelligent, je pense que tu es tout à fait capable de prendre du recul par rapport aux modes, aux tendances, etc.

Rien qu’en intégration, regarde : avant, on faisait des tableaux, ensuite, on a eu l’intégration XHTML/CSS où les ayatollahs des standards te faisaient ch… pour le moindre id ou class de travers, en exécrant la divite et la classite, à grand coups de sacro-sainte sémantique. On avait besoin de cela à ce moment.

Puis, après qu’on ait martelé ces arguments et pendu les hérétiques, on s’est posé des questions, car d’autres problèmes étaient apparus, que tu peux voir dans CSS, l’âge de raison. Après, on nous a dit, « il faut penser réutilisable et modulable », penser nos CSS comme des objets, il y a les pré-processeurs, etc.

On est passé ensuite aux frameworks CSS, toujours pour penser réutilisable, à grands coups de classes atomiques. Et pourtant, maintenant, certains reviennent des pré-processeurs, et on nous dit de nouveau que les classes sémantiques, c’est bien…

En fait, je vais te livrer un secret, il n’y a pas de mauvaise approche, il y a des approches, leurs limites et leurs avantages, dans des cas donnés. Les querelles de chapelles, ça fait peut-être vendre du papier (numérique), mais ça n’a jamais fait avancer le monde.

Je m’amuse à tester des trucs, même si je n’ai pas encore blogué sur le sujet, tu verras que j’explore encore des détails, et mon avis évolue sur pleins de sujets. C'est ce que j'ai essayé de faire passer dans « réinventer le chemin… pas la roue ».

Les sujets (in)explorés

Ne crois pas qu’il ne reste plus rien à explorer, car c’est faux. Ces domaines évoluent tellement vite, tout évolue, et les concepts même sur lesquels se basent nos connaissances évoluent, avec la pratique et les contraintes. Regarde, j’adore la typographie, et il y a quelques années, je ne pouvais pas utiliser l’espace fine insécable &#8239;, trop mal supporté, j’avais fait une croix dessus. Et depuis quelques billets, je l’ai remis. C’est neuf, et pourtant, ce n’est pas nouveau !

Regarde l’intégration, on est dans une phase de complexification (nécessaire), et dans quelques années, on cherchera peut-être à y rendre plus simple…

La performance est une des contraintes qui a façonné notre métier, mais qui nous dit que le web sémantique ne sera pas par exemple LA contrainte de demain avec des choses comme les micro-datas ou même quelque chose qui n’existe pas encore, pour des questions de référencement ?

Et plus que les sujets inexplorés, les sujets explorés ont encore beaucoup à dire, même et surtout si ça a déjà été dit. Regarde la conférence de Nicolas Hoizey sur l’unité em à Paris-Web. Cette conférence explique des choses qui ne sont pas nouvelles en soi, l’unité em existe depuis des années, et pourtant, plein de gens en sont encore effrayés.

Et l’accessibilité ? S’il y a autant de discussions sur le sujet, c’est bien qu’il y a encore beaucoup de travail à faire.

Tu crois qu’on révolutionne la planète en pensant qualité pour le Web ? Les industriels se sont déjà penchés sur le sujet depuis des centaines d’années. On ne fait que réfléchir à la même chose avec un nouveau contexte. C’est neuf, et pourtant, ce n’est pas nouveau ! (oui, je me répète, mais tu sais, je suis un vieux con de 33 ans)

Donc non, tu n’as pas besoin d’être plus vieux.

Quelques certitudes

Marie Guillaumet disait « Je ne suis sûre de rien ». En soi… elle a bien raison ! Toutefois, je n’ai peut-être pas beaucoup de certitudes, mais j’ai des convictions : on ne pourra pas faire sans performance, sans accessibilité, sans qualité.

On ne pourra pas faire sans des gens qui partagent dans des articles, dans des conférences, dans des discussions. Et qu’est-ce qui t’empêche d’aller même écrire pour Alsacréations, Opquast, OpenWeb, Pompage, le Train de 13H37, 24 Jours de Web, W3Qualité, ou je ne sais quel site ? Cela par contre, j’en ai la certitude, en écrivant pour des collectifs, tu te valoriseras, tu rencontreras des gens biens, tu progresseras.

Et si la prochaine révolution était dans tes mains, à partir de ce qui existe déjà ? Je te fais rire en disant ça ? Regarde ce que ton billet a généré. Des réactions sur des blogs, sur Twitter, des articles, des pensées, etc.

Donc, si jamais tu te penches sur un sujet, n’hésite pas à partager ton expérience, même si des articles existent déjà. Regarde, mes héros du Web ne sont pas les tiens. Tu tiens peut-être des personnes en admiration, et si ça se trouve, je ne les connais pas, et c’est bien dommage.

Comme je te le dis, tu es peut-être le débutant de quelqu’un, mais quelqu’un est ton débutant. Et ce quelqu’un, ça sera peut-être moi, donc hop hop hop, allez, au boulot !

Des pensées sur la qualité Web (le 11/03/2014)

Vu qu’on parle beaucoup de qualité Web ces temps-ci sur Twitter (c’est parti d’un billet sur le blog Temesis «Ailleurs : non, Jeff, t’es pas tout seul», qui lui-même est parti d’autres échanges), j’en profite pour déterrer des réflexions que je m’étais faites dans des billets précédents :

Tout cela en attendant deux articles qui vont sortir sur OpenWeb et qui vont parler à pas mal de gens…

Le manque de recul (le 09/03/2014)

S’il y a une chose qui me surprend toujours dans le domaine du web, c’est le constant manque de recul de bon nombre de personnes y travaillant. Pour éviter de me disperser, je m’en tiendrai aux développeurs et autres intégrateurs.

J’ignore si cela est dû à la jeunesse du support ou à un syndrome amnésique, mais je suis parfois stupéfait de cette capacité à réécrire l’histoire ou à l’oublier, que ce soit dans les approches, les pratiques et même les fondements.

Les approches

À mon sens, le propre du développeur est de rapidement voir les conditions limites d’une approche. Plus son savoir et son expérience sont étendus, plus il doit pouvoir jauger rapidement les limites d’un cadre donné : une méthodologie, un framework, une approche, un outil, etc.

Je suis effaré de voir déjà l’incapacité de voir les limites d’un cadre, et souvent assommées à grand renfort de certitudes. J’aime bien les super-slogans genre : « avec Wordpress, on fait un blog, avec Drupal on fait Wordpress ». Super, cela tombe bien, j’avais besoin de re-développer Wordpress. Et si je n’ai déjà pas besoin d’un Wordpress ?
Ou le classique « les vrais développeurs utilisent <mettez ici ce que vous voulez> ». Sous-entendu : vous êtes une sous-merde si vous n’utilisez pas ça.

Pire, voir ou mentionner ces limites ne doit pas servir à démolir une approche, mais juste à mieux apprécier le cadre posé, libre à vous de faire le choix ou non d’apprécier ce cadre. Mais nier que ce cadre existe… non !

Les pratiques

Un point m’amuse, ce sont les effets de modes : « tiens y a tel outil qui est révolutionnaire », les premiers affamés se jettent dessus, des articles sont pondus pour vanter les mérites, ça buzze à fond sur Twitter… et deux semaines après, y a un article qui vient dire « oui, mais attention, dans tel cas… » ou alors « des problèmes d’accessibilité sont apparus », « on devient dangereusement dépendant de cet outil » etc.

Je parle d’outil, mais les approches ont les mêmes problèmes quand elles sont lues un peu vite, combien de fois ai-je entendu : « mais on ne met plus d’id dans la source, vu qu’on utilise que les classes pour styler ».

Je me permets de citer Mehdi Kabab dans un commentaire sur 24 jours de Web :

Intégrateurs, votre cœur de métier ne se limite pas à pisser du CSS au kilomètre. Vos compétences et le savoir que vous avez acquis à la sueur de vos erreurs (vive l’apprentissage par l’échec, la meilleure école de l’intégrateur/développeur Web) ont de la valeur. Alors, s’il vous plaît, ne les rejetez pas sous prétexte qu’un personnage influent clame tout haut une opinion personnelle, mais qui se répand comme une traînée de poudre de part son statut de « gourou ».

Qu’on s’entende bien : c’est bien de tester des nouveaux trucs, de voir de nouvelles techniques, etc. je ne vais pas dire le contraire, c’est même indispensable.

Seulement, il y a les belles nouveautés et ce qui peut passer en production ou en standard dans un développement. Comme l’a très bien dit Mehdi Kabab ci-dessus, qu’une pratique soit intéressante n’empêche pas pour autant de l’utiliser sans jeter le bébé avec l’eau du bain.

Les fondements

Partons d’un bon exemple : j’adore cette animosité de nombreux développeurs front-end envers les préfixes CSS. Ok, je leur accorde que c’est parfois un peu pénible à gérer. De « je m’en fous » à « je ne mets que -webkit », « je m’en moque j’ai un pré-processeur », jusqu’à dernièrement le « on va le post-processer ». D’élément ignoré, ensuite central, après pré-processé pour finir post-processé. Genre on s’en fout, on s’en occupe, on pré-délaie et on post-délaie.

Mais hé oh ! Je vais vous rafraîchir la mémoire : à la base, c’est un système expérimental pour tester des implémentations. Si un certain Daniel Glazman a secoué le cocotier pour nous faire tomber des noix sur le crâne, c’est que nous avons été trop fainéants pour respecter la base du Web : son universalité (et accessoirement sa pérennité). Si les médecins qui ont prescrit trop d’antibiotiques doivent assumer les bactéries multi-résistantes, hé bien les préfixes, ce sont nos enfants, c’est à nous de les assumer.

D’aucuns vont me traiter de chiant, je leur répondrai qu’il faut assumer la part du contrat : le Web est un système pensé pour être universel et pérenne, alors on doit accepter de gérer cette universalité. Point barre. Je ne dis pas de le faire parfaitement, moi-même, j’en suis bien loin, je dois faire des choix.

Moi qui pensais que les avantages des standards avaient suffisamment été compris, je vois que ce travail n’est pas terminé…

Évidemment, les préfixes ne sont qu’un symptôme. Quand je vois qu’on trouve révolutionnaire de penser d’abord HTML, ensuite CSS par dessus et enfin JavaScript, il y a de quoi faire un bond, ce sont les fondements du Web !

Leurs secrets sont morts avec eux (le 22/02/2014)

En ce début de week-end, laissez-moi vous raconter une histoire. Vous avez peut-être remarqué que j’ai une section nommée Terragen et même une section vidéo où j’ai réalisé des animations avec Terragen.

Une communauté francophone très sympathique s’était constituée autour de ce logiciel. Sa relative simplicité, la passion et une très bonne ambiance ont permis de constituer un groupe plutôt actif. Plein de techniques, d’échanges, de projets ont eu lieu, c’était formidable. Je crois avoir encore un livre francophone sur le sujet. J’avais écrit des tutoriels sur les animations, c’est même d’ailleurs Terragen qui m’a amené à créer un site internet.

Quelques talents de très haut niveau ont émergé. Vous pourriez me taxer de subjectivité franchouillarde, mais il n’en est rien, j’en veux pour preuve que sur le site officiel de Terragen 0.9 présentait à l'époque la galerie de Luc Bianco, excellent parmi les meilleurs.

Curieusement, c’est au sommet de leur art que certains des plus forts se sont agacés : d’être copiés, d’être plagiés. Ajoutons à cela que d’autres webrings de l’époque se souciaient moins de la qualité que de récolter les « likes » de l’époque. Au final, ils ont rechigné à partager leurs techniques. Égo mal placé, peurs, protection de leurs œuvres ? Je ne jugerai pas leurs motivations, ce n’est même pas le propos qui m’intéresse ici.

En fait, ce que je trouve dommage, c’est que ces magnifiques œuvres… ont disparu. Elles n’existent plus que dans certaines mémoires (dont la mienne qui vous raconte cette histoire) et au hasard du net pour ceux qui connaissent encore. Le logiciel Terragen lui n’est pas mort, loin de là, il s’est professionnalisé, il sert pour des images de synthèse dans des films entre autres. Je pratique encore de temps en temps, mais beaucoup moins.

Ma spécialité était d’animer certaines de ces réalisations. Mes plus belles animations ont été des réalisations en équipe : sur Mars avec Yves Maquinay et Arnaud et Florent Creux, sur un iceberg avec Marcello Deschino, dans une caverne avec Franck Doassans, des projets avec Karsten Keppel, etc. Je n’ai jamais cessé de m’émerveiller de la beauté de leurs réalisations. Et les voir vivre et se balader dedans, c’est encore mieux.

Ce que je trouve regrettable, c’est que certains de ces artistes n’aient pas ouvert leurs secrets, et la disparition de ces artistes aura emmené leurs secrets avec eux, métaphoriquement bien sûr. C’est amusant quand on y pense, l’objectif de ne pas être plagié aura été atteint, mais pas celui d’être renommé, vu que certains ont totalement disparu. Quel gâchis de beauté.

À croire que la connaissance d’un appareil photo remplace le coup d’œil du photographe.
À croire que le secret assure la survie.
À croire qu’un tutoriel va priver son auteur de son savoir.

Quand on pense plus à récolter des « likes », des +1 ou des « followers » et à garder ses secrets pour soi, on finit au final par être dans un donjon. Un donjon, c’est haut, imprenable… mais on s’y ennuie et on finit par y mourir.

Je ne peux m’empêcher de penser aux connaissances du Web, qui se répandent parce que une personne aura eu l’idée de la partager, de la vulgariser, d’en expliquer un bout.

Voilà un des sens de ma motivation à écrire des billets, des articles, des tutoriels : pour que ces connaissances ne meurent et ne dorment pas bêtement. Même si c’est pour une unique autre personne, c’est toujours mieux que rien.

Heureusement qu’ils existent (le 12/02/2014)

Je l’ai déjà dit, mais je crois que je n’ai pas assez insisté.

C’est un problème de trop fréquenter/écouter :

  • des conférences comme Paris Web, Kiwi Party, etc. ;
  • des collectifs comme OpenWeb ;
  • des sites comme Alsacréations, Pompage, etc. ;
  • des personnes branchées qualité Web ;
  • des personnes branchées accessibilité Web ;
  • des personnes branchées sémantique Web ;
  • des personnes branchées performances Web ;
  • des personnes branchées typographie Web ;
  • des personnes branchées CSS ;
  • de suivre des gens passionnés et intéressants sur Twitter ;
  • d’avoir des libertés pour bien faire le Web, sur son blog, sur des articles, etc. ;
  • etc.

Vous allez me dire « En quoi c’est un problème, c’est bien ! ». Oui certes, mais ça pose un problème de taille : c’est que l’on finit par croire que tout le monde fonctionne comme cela.

J’avais déjà évoqué ce danger dans un billet il y a environ 4 ans, le danger de croire que les standards du web sont acquis.

Hé oui, heureusement, des posts viennent nous rappeler la (parfois dure) réalité. En l’occurence, le monsieur est à côté de la plaque, dire que responsive, HTML5, CSS3 rendent impossible la sémantique, c’est complètement à côté de la plaque.

Ce n’est qu’un exemple, mais j’entends régulièrement des âneries de ce genre, genre :

  • « mais c’est impossible de valider son code, et puis on s’en fout » 
  • « mais on peut pas mettre en page ainsi, t’as qu’à utiliser un table » ;
  • « les liens, ça doit s’ouvrir dans une nouvelle fenêtre, pour pas qu’on quitte le site » ;
  • « mais on fait des sites accessibles, on a mis des alt aux images »
  • « mais on fait de la qualité, notre site, y s’affiche bien sur iPhone »
  • etc.

Ces trucs qui vous feraient démarrer une personne comme moi au quart de tour avec des :

  • « mais putain, c’est pas impossible, c’est juste indispensable de valider ton code » 
  • « mais ta gueule, les tableaux de présentation, c’est niet » ;
  • « mais non, pourquoi on impose ce choix, et ça n’empêchera pas qu’on quitte le site et qu’on y revienne » ;
  • « et tu penses sérieusement que ça suffit ? »
  • « et tu crois que la qualité Web, ça se résume à faire une intégration correcte ! »
  • etc.

Quelque part, ont un bénéfice, juste nous rappeler la réalité du terrain peut être très loin de nos propres standards. Je dis cela sans aucun mépris, ce n’est pas honteux de ne pas savoir, je suis le premier à ignorer tellement de choses.

Un autre mérite : il a fallu, il faut et il faudra continuer de rabâcher les bases, et pour longtemps (et les partager). Si nous voulons que nos futurs collègues ou nos futurs remplaçants ne refassent pas les mêmes bêtises, ou pire, en fassent des encore plus grossières. Qu’on se le dise !

Je faisais du front-end-first (le 08/02/2014)

Quand j’ai commencé en tant que professionnel, un des principaux arguments massue sur lequel j’essayais de vendre mes connaissances/prestas était la possibilité de mettre à jour son site tout seul.

Rappelons qu’en 2003, les back-ends et autres CMS, même s’ils existaient déjà, étaient bien moins rentrés dans la culture des prestations Web qu’ils ne le sont devenus aujourd’hui.

Pour ma part, je faisais mes back-ends à la main, ils étaient simples mais ils suffisaient aux besoins des clients, étant faits sur mesure. Mon précédent boss était le premier à vendre cette approche, en étant le premier bénéficiaire à travers l’intranet de la boîte et divers projets, qui selon sa formule « se pilotaient tout seuls ».

Curieusement, le front-end n’avait pas l’importance qu’il a aujourd’hui. La seule demande que j’avais, c’était « faut que ça s’affiche bien », comprenez sous IE6, et si vraiment on avait un client connaisseur, sous Firefox/Opera.

Le soin que j’apportais à mes intégrations et au front-end dépassait souvent largement ce qu’on attendait de ma part. On me demandait souvent de plus discuter mises à jour des sites plutôt que de leur capacité à bien s’afficher.

Curiosité : c’est quand même extraordinaire que ce qui ait longtemps été mis en avant sur les sites… c’était l’arrière-boutique.

J’ai toujours été convaincu que c’était important d’avoir des intégrations propres et bien bichonnées, mais j’ai longtemps cru que le soin que j’y mettais était de la surqualité d’intégrateur pointilleux, en tout cas vu comme tel. Parallèlement à cela, mes back-ends étant volontairement simples, me permettaient d’en faire sortir les données très facilement, de manière à ce que les contraintes du back-end ne viennent jamais dicter comment devaient être mes intégrations (et même les soutenir si besoin était).

Dix ans après, le front-end a (re-)pris la place que l’on sait : performances, web mobile, responsive, et même web adaptatif. Les conférences et les articles confirment cet intérêt.

Si on me demande toujours des back-ends sur mesure, le front-end est vraiment devenu l’objet de toutes les attentions : il faut que ça soit rapide, bien rendu, scalable comme on dit en anglais, souple, adaptable selon les supports via le côté responsive, etc.

La curiosité d’il y a dix ans est enfin ré-équilibrée si j’ose dire : enfin on se soucie de l’avant-boutique. Ajoutons à cela que l’avant-boutique est juste ce qui est montré à la Terre entière (je ne parle même pas de design), je ne sais pas pour vous, mais moi je trouve ça extra-ordinaire : enfin on se soucie de ce qui est montré au visiteur !

Oui, s’intéresser au front-end, c’est ça : c’est se soucier de ce qui est montré à la face du monde en matière de sites web. Autrement dit, quand vous intégrez un site, pensez que vous avez la responsabilité de ce qui va être montré au monde entier. Si jamais quelqu’un minimise votre responsabilité, envoyez ce que je viens de mettre en gras à la tronche de ce quelqu’un.

Et à titre personnel, comme aurait pu dire monsieur Jourdain : depuis des années, je faisais du front-end first sans le savoir.

Un site et une CSS en right to left (le 03/02/2014)

Dans la série des « trucs que j’ai pas eu l’occasion d’intégrer », le site en langue arabe avait une bonne place : j’avais pu faire de la maintenance très légère sur un site de ce genre, mais je n’en avais pas conçu de A à Z. La particularité de ces sites est d’être écrits de droite à gauche, aussi appelé RTL en langue de Shakespeare.

C’est désormais chose faite, j’ai récemment mis en ligne un site bilingue, à savoir en anglais et en arabe.

Geneva Centre for Human Rights Advancement and Global Dialogue

C’est la première réalisation que je faisais avec RÖCSSTI qui avait cette contrainte. Ajoutons à cela que ce site est propulsé par un CMS.

La base pour préparer le site à passer en RTL

J’avais eu le plaisir de suivre l’atelier d’Aurélien Masfrand à Paris Web 2012, il a d’ailleurs écrit un article sur le site du Train de 13H37 sur le sujet : Introduction à la localisation, RTL et LTR.

Le premier pas a été d’indiquer dir="rtl" sur l’élément html, en plus de l’attribut lang="ar" bien sûr.

Avec le CMS, j’ai ajouté une classe .ar sur l’élément body, ce qui m’a permis d’avoir un point de repère pour styler les éléments qui ont dû être adaptés pour la langue arabe, une sorte de classe conditionnelle. J’aurais pu cibler via [dir="rtl"], c’est équivalent dans ce cas. À choisir, c’est même mieux, plus généraliste : c’est la solution que j’ai retenue pour RÖCSSTI, qui supporte maintenant la possibilité d’un site en RTL (je reviendrai sur ce sujet dans un prochain billet).

Le but du jeu a été d’inverser l’interface : comme le sens de lecture est inversé, ce qui est à gauche en anglais est à droite en arabe.

La technique d’Aurélien Masfrand consistait à :

  • dupliquer la CSS ;
  • enlever tout ce qui n’est pas impacté par le changement de sens de lecture ;
  • et inverser les valeurs et propriétés restantes dans une CSS spéciale contenu RTL.

La méthode est toujours bonne, néanmoins, vu la relative simplicité du design, j’ai tout laissé dans la même CSS, ainsi une unique CSS gère les deux versions du site. Idem pour les templates, le CMS était assez souple pour permettre de tout gérer directement dans ces derniers.

D’autres détails pour faciliter le RTL

Comme vous avez pu le voir, ce n’est pas excessivement difficile en soi, c’est plus un jeu amusant et un peu déroutant.

Grosso modo, l’adaptation s’est faite ainsi :

  • les flottants ont été inversés (float: left; devient float: right;) ;
  • les positionnements absolus sont inversés (genre un left: 2em; se transforme en left: auto; right: 2em;) ;
  • les alignements aussi (text-align: left devient text-align: right) ;
  • les padding et autre margin itou (padding: 0 1.5625em 1.5em 0; devient padding: 0 0 1.5em 1.5625em;) ;
  • les contrôles des sliders ont été repositionnés aussi (les boutons « suivant » et « précédent » devant être inversés aussi !).

Là où je me suis posé des questions avec le graphiste, c’est sur les logos : doit-on également les mettre en mode miroir ? La réponse nous a été plus ou moins donnée par le client, s’il y avait du texte, on adaptait, sinon on laissait tel quel.

Je note qu’utiliser le display: table; pour positionner les éléments ne nécessite aucun changement, du coup, cela facilite l’adaptation, vu… qu’il n’y avait rien à faire. Un bon point de plus pour le display: table; !

Là où cela devient plus casse-pied, c’est quand les textes en alphabet latin se mélangent aux textes en arabe. Par exemple, sur la page de contact du GCHRAGD, il a fallu ruser quelque peu.

Dans ce cas, j’ai simplement mis les infos à la ligne (par exemple les numéro de téléphone), afin d’éviter que les contenus soient écrit à l’envers ou de manière anarchique. La meilleure façon de faire est encore de laisser l’algorithme bi-directionnel faire le boulot, et éviter de trop mélanger ces contenus (méthode empirique dictée par l’approche KISS). Quelques flottants et quelques alignements vite posés avec RÖCSSTI, et cette légère difficulté a été vite vaincue.

L’adaptation du site à la langue arabique s'est faite en une matinée. Je suppose qu’une structure très propre, une CSS carrée et un CMS suffisamment souple ont grandement facilité cette grande première pour moi.

Ma'a salâma !

La méthode FUCSS (le 20/01/2014)

Comme c’est la grande mode de sortir des noms pour les méthodes CSS (SMACSS, OOCSS, BEM, etc.)… hé bien, j’ai décidé de déposer un nom pour une méthode CSS.

Cette méthode est la plus répandue en matière de CSS (même si heureusement elle perd du terrain), et personne n’avait pensé à lui donner un petit nom. Historiquement, elle est rétro-compatible avec toutes les nouvelles méthodes, y compris avec les pré-processeurs.

C’est une sous-implémentation de la norme ISO-1664, aussi appelée méthode de la Rache.

FUCSS

Le nom de cette méthode est FUCSS, pour Fully-Unordered CSS, prononcez « f*cks ». Elle est également compatible avec l’approche FESS.

Comme son nom l’indique (enfin si vous parlez anglais), c’est quand votre CSS est un joyeux tas d’immondices impossible à maintenir, et, très important, en bordel le plus incompréhensible et le plus inmaintenable. Il est donc conseillé :

  • d’ajouter des propriétés dans tous les sens, on s’en fout tant que ça marche ;
  • d’utiliser !important autant que possible ;
  • de ne surtout pas indenter le code ;
  • au pire, si vous êtes forcé d’indenter, autant le faire de manière anarchique ;
  • côté gestion des préfixes, encore une fois, l’ordre importe peu ;
  • etc.

Afin de faciliter la communication sur cette approche, voici une image pour estampiller la marque :

FUCSS approved
(images créées par Fabien Sauter)

À apposer sur les pires CSS que vous trouverez, ou sur les horreurs qu’un projet mal ficelé vous aura fait faire. Là, vous aurez le droit, quand on vous refile ce genre de projet, de vous écrier « what the FUCSS ! ».

Et vous, avez-vous pratiqué ou dû reprendre une CSS faite en approche FUCSS ?

Les bonnes résolutions de l’intégrateur (le 04/01/2014)

Rions un peu en ce début d’année où il est souvent question de bonnes résolutions : j’ai imaginé ce que seraient les bonnes résolutions… des intégrateurs, enfin de certains intégrateurs.

L’origine de ce billet vient de celui Je vous présente Madame Print, où j’avais promis à une certaine Christelle que je(j’auto-) parodierai avec plaisir mon propre métier lors des bonnes résolutions. Chose promise, chose due !

  • Oui, j’ai compris que les proportions pour les contenus ont été pensées sur les maquettes, donc je les respecterai !
  • Non, les graphistes ne sont pas uniquement des singes qui ne comprennent rien au web !
  • Corolaire : non les développeurs back-end ne sont pas uniquement des rustres massacreurs de belles intégrations !
  • Non, les espacements entre les contenus ne sont pas mis au hasard, mais bien pour permettre aux contenus de respirer et d’être lus agréablement !
  • Corolaire : l’espace vide autour des différents contenus n’est pas là parce qu’on ne savait pas quoi en faire.
  • Second corolaire : je peux même aérer volontairement le contenu, en général, aucun risque de me faire gronder !
  • Non, les grilles ne sont pas faites pour les chiens. J’ai compris que ça rendait le design agréable aux yeux, entre autres.
  • Non, les em ne sont pas là juste pour complexifier ma CSS par rapport aux pixels, mais bien pour rendre des services !
  • Je ne changerai plus les couleurs en douce sans prévenir le graphiste ! Même si c’est avec les meilleures intentions. Surtout si c’est avec les meilleures intentions.
  • Corolaire : oui, j’ai compris que la typo choisie par le graphiste est importante, donc si j’ai une impossibilité, je lui demanderai avant de la changer arbitrairement.
  • Oui, je sais désormais que les apostrophes se font ainsi « ’ » et pas ainsi « ' ». Idem pour les chevrons et plein d’autres détails typographiques.
  • Oui, j’ai compris que le développeur back-end ne comprenait rien à ma discipline, donc je prévoirai des classes et une structure qu’il va comprendre et pouvoir réutiliser !
  • Ajout : et surtout une structure qui colle bien avec l’affichage via une boucle for ou while des divers éléments !
  • Le JavaScript, c’est bien, mais cela peut fortement ralentir un site, surtout s’il y en a beaucoup.
  • Oui, je demanderai systématiquement à mon graphiste le logo du site en SVG !
  • Oui, j’ai compris que certaines balises doivent être utilisées intelligemment pour leur sens, et pas uniquement pour leur rendu.
  • Corolaire : un attribut, même vide comme alt="", ce n’est rien pour moi, mais cela peut faire toute la différence pour un utilisateur.
  • Oui, j’ai le droit de me moquer gentiment des agences print, des graphistes, etc. Seulement si je prends le temps de leur expliquer pourquoi je me moque.

Note : c’est de l’humour, ils (les autres) ne sont pas parfaits non plus.

Dans le même genre :

Maître Intégrateur, sur un arbre perché (le 29/12/2013)

Maître Intégrateur, sur un arbre DOM perché,
Codait une propriété non recommandée.
Maître WebKit, par l'odeur alléché,
Lui tint à peu près ce phrasé :
« Hé ! Bonjour, Monsieur de l'Inté, oooh !
Que votre code est joli ! Que votre site est beau !
Sans mentir, si votre codage
Se rapporte à votre jeune âge,
Vous êtes flamboyant dev Front-end cette fois. »
À ces mots l'intégrateur ne se sent pas de joie ;
Et pour montrer ses beaux choix,
Il ouvre un autre navigateur, et constate avec effroi.
WebKit s'en saisit, et dit : « Mon bon Sieur,
Apprenez que tout codeur
Vit aux dépens des sites que consulte la Vox :
Cette leçon vaut bien un test… sous Firefox. »
L'intégrateur, honteux et confus,
Jura, mais un peu tard, qu'on ne l'y prendrait plus.

Note de lecture : Sass et Compass avancé (le 29/12/2013)

Les retards répétés d’un aller-retour en avion pour l’Opquast Day m’ont donné le temps de lire à tête reposée le livre « Sass et Compass avancé, optimiser ses feuilles de styles CSS », écrit par Mehdi Kabab (toujours avoir un livre avec soi, ça permet de transformer le temps inutile en moment utile quand on voyage).

Sass et Compass avancé, par Mehdi Kabab

Je fais partie de ceux qui ont découvert Sass un peu par hasard (j’ai vu de la lumière, je suis entré). À la base, j’ai appris CSS et rien d’autre… tout au plus à utiliser PHP en pré-processeur CSS si vraiment le besoin s’en faisait sentir.

Néanmoins, Sass et son comparse Compass (répétez-le 3 fois) sont rapidement devenus très séduisants. Pour ma part, j’ai été séduit à la base par les @extend et les variables. Non pas que les autres possibilités ne soient pas intéressantes, mais ce sont ces deux possibilités qui ont été le déclencheur chez moi.

Même si j’avais lu beaucoup d’exemples sur ce pré-processeur, il me manquait en fait quelques bases pour apprendre réellement les fondements de cet outil. C’est chose faite avec ce livre : il pose de bonnes bases avec de bons exemples pratiques pour utiliser Sass et Compass correctement.

Pour ma part, j’ai réalisé plusieurs sites avec Sass/Compass, notamment via mon micro-framework RÖCSSTI dans sa version Sass (dont une mobile-first), BrieF´R Formations et Prezenz étant les deux plus emblématiques. Dans les deux cas, Sass apporte quelques facilités pour créer et maintenir des CSS.

Si vous vous intéressez à Sass, ce livre est une excellente ressource pour l’apprendre et partir sur du solide si j’ose dire. Variables, mixins, extend, placeholders, fonctions, etc. Toutes les bases sont abordées, le livre se termine sur un chapitre conséquent sur les sprites CSS et sur les source maps.

Chose qui m’a beaucoup plu et qui fait tout l’intérêt du livre, l’auteur ne s’éloigne jamais de la logique CSS, ce qui est dangereusement facile avec de tels outils. Combien d’exemples complètement justes au niveau programmatique mais aberrants au point de vue CSS ai-je vu ! Fort heureusement, vous n’aurez plus d’excuses maintenant, Mehdi Kabab a bien travaillé pour vous éviter ces écueils.

P.S : j’ignore toujours qui je dois remercier entre Eyrolles et l’auteur, vu que je l’ai reçu dès sa sortie à ma grande surprise avant même de l’avoir commandé. Donc dans le doute, je remercie chaleureusement les deux !

Petit bonus : CSS de Prezenz version Sass (le 29/12/2013)

Honte à moi, j’avais oublié ceci : si vous voulez étudier la CSS que j’ai réalisé dans le retour d’expérience du billet précédent, voici le lien vers la version Sass : CSS du site Prezenz en version Sass.

Si vous avez une erreur de codage, allez dans « Affichage, encodage des caractères ». Je peux vous assurer que le fichier est bien défini en UTF-8 ainsi que dans le htaccess du site, mais je ne sais pas pourquoi, l’affichage déconne.

Retour d’expérience de la refonte du site de l’agence Prezenz (CSS responsive en mobile-first) (le 27/12/2013)

Enfin ! Depuis le temps que je souhaitais refondre le site légèrement désuet qu’était le site de mon agence, cette fois, l’occasion est arrivée. Le nouveau site de Prezenz a été mis en ligne il y a quelques semaines, et le moins qu’on puisse dire, c’est que côté intégration j’ai eu quelques défis bien sympas à relever sur ce site !

Cette refonte ayant touché beaucoup de domaines, pour ce billet, je m’en tiendrai « juste » à l’intégration, car il y a déjà beaucoup à dire.

Prezenz

Les objectifs

Les objectifs ont été clairs : pour le site de l’agence, on va mettre le paquet. Site en responsive, mobiles, micro-datas, optimisation SEO, etc. D’entrée de jeu, j’ai imposé une intégration en mobile-first, et tant qu’à faire les besoins en JavaScript seront faits autant que possible à la main !

Les navigateurs cibles seront en premier les modernes, les vieux ne seront pas oubliés pour autant, mais ils passeront clairement après les modernes.

De nombreux contenus ont été rédigés, un gestionnaire de site sur mesure a été créé, Google Analytics a aussi eu de quoi faire, de nombreux trackers ont été mis en place afin de voir clairement si les choix qui ont été faits sont compris et utilisés.

Construction d’une CSS mobile-first, responsive avec Sass/Compass et RÖCSSTI

Mon micro-framework était construit en desktop-first, et du coup, avec ce site, une version Sass de RÖCSSTI construite en mobile-first a été mise au point. Le début a consisté à changer l’ordre de la CSS : on part du plus petit dénominateur commun pour aller vers les résolutions plus élevées, en ne changeant que ce qui est nécessaire à chaque étape.

Je dis bien « au départ » car quelques légères modifications ont dû suivre, j’y reviendrai.

L’intégration mobile-first est un exercice de style intéressant, même si j’en avais déjà fait une pour mon site personnel, là c’était un poil plus compliqué, et donc plus intéressant.

Autant le dire de suite, j’avais des wireframes et des guides de styles très précis, et je ne vois pas comment intégrer un site correctement (comprenez sans perdre de temps et en respectant autant que possible l’intention du design). Si parfois sur un site desktop, on peut se permettre d’improviser les points imprécis, sur une intégration construite en mobile-first, j’aurais tendance à le déconseiller vivement !

Alors certes, avec les vrais contenus, certaines adaptations en cours de route ont dû être faites, mais l’idée générale m’a bien guidé.

Structure du projet avec Sass

À l’inverse de bon nombre d’intégrateurs, je ne suis pas un fan de tout morceler mes CSS en plein de fichiers. C’est sûrement utile avec des CSS immenses, mais je ne suis pas allé aussi loin.

Par contre, quand j’ai eu le guide de styles en mains, j’ai fait un sous-fichier avec tous les paramètres : notamment toutes les couleurs données en référence ont été mises dans des variables et nommées telles quelles, comme par exemple $prz-grey: #363636;. Et je me suis interdit d’utiliser autre chose que ces variables !
Ainsi, toute référence venant des graphistes et qui serait en-dehors des clous posés par… eux-mêmes (!) aura vite été remise dans le droit chemin. Seule exception, je n’ai pas créé de variable pour le blanc pur.

Les autres sous-fichiers (qui a dit includes ?) étaient principalement pour la gestion des sprites, afin de ne pas surcharger le fichier principal, qui, avec les commentaires, est resté très facilement maintenable et lisible.

Les em, j’aime !

Je reste légèrement surpris que la conférence de Nicolas Hoizey à Paris-Web sur l’unité em ait presque un goût de grande nouveauté pour beaucoup, car c’est vraiment un régal à utiliser dès qu’on en a pris l’habitude. Pour ma part, je les utilise depuis de nombreux projets, et je me surprends parfois à ne plus raisonner en pixels pour des padding et autre margin, mais directement en em.

Cette intégration, à l’exception des images, est intégralement construite en em, media-queries comprises ! Et le moins que je puisse dire, c’est que cela a des effets de bords… plutôt sympathiques !

Le premier est de permettre un zoom global ou un zoom texte sans aucun souci. Le site va très bien s’adapter si par exemple je zoome fortement sur mon navigateur desktop. Autrement dit, c’est un pur régal si on a des contraintes d’accessibilité où l’on doit permettre un zoom texte conséquent. Autre avantage non négligeable : le site s’accommode parfaitement de toutes les tailles de fonte définies ou différentes par défaut.

Ci-dessous un exemple de site en version zoomée à 200% :

Une page du site Prezenz en zoom à 200%

Même si effectivement, les em sont un peu plus simples à gérer avec un pré-processeur comme Sass, il ne faut pas hésiter, même sans Sass, cela se gère bien et ils apportent de nombreux avantages. Les em, c’est sensass’, même sans Sass.

Optimisation retina

Histoire de faire les choses comme il faut, vu que le site cible clairement les mobiles, il eut été dommage de ne pas penser à l’optimisation aux écrans à haute densité de pixels, que j’appellerai retina par simple fainéantise ! :)

Comme le site utilise autant que possible du texte avec une webfont, de ce côté-là, pas de souci. Pour le logo du site, pas de souci, SVG a été choisi et est « fallbacké » avec un PNG.

Pour les icônes – le site en utilise énormément –, le choix d’un doublement de résolution a été préféré à SVG, cela a été plus simple à gérer pour tout le monde, y compris moi-même pour une histoire de sprites CSS, j’aborde ce point plus loin.

De ce que j’avais pu lire sur le sujet, le principe utilisé est souvent de charger d’abord les images normales, et seulement ensuite de charger les images de meilleure qualité. Comme l’objectif était clairement les mobiles, les navigateurs modernes et les écrans retina, j’ai pris le parti inverse : d’abord charger uniquement les images en « haute qualité », afin d’éviter des requêtes supplémentaires pour les mobiles retina. Les navigateurs modernes gérant parfaitement background-size, le léger surpoids était très limité pour ces derniers, en tout cas, rien de comparable avec des requêtes HTTP supplémentaires.

Seuls les vieux navigateurs auront eu des images en taille normale en plus, autrement dit, IE7 et 8.

Considérations sur Flexbox et CSS3 multicolumn

Histoire de me faire plaisir, j’ai pu expérimenter l’utilisation de Flexbox pour quelques parties, disons-le tout net, ce positionnement de boîtes flexibles est un pur bonheur : surpuissant, très simple, ne nécessitant que peu de code… c’est gé-nial.

Sauuuuuf… quand on doit regarder chez les navigateurs qui ne le supportent pas, là ça devient la misère (les fallbacks ne sont franchement pas terribles, pour ne pas dire inexistants). C’est cela qui m’a conduit à en limiter l’usage là où je pouvais me raccrocher aux branches avec du table-layout avec des largeurs en pourcentages.

Certains éléments demandés m’ont été impossibles à styler sans CSS3 multi-column. Typiquement, la navigation secondaire (découvrir, attirer, etc.) sur la page portrait de Prezenz qui passe d’une colonne à deux, puis trois colonnes… impossible de faire cela autrement !

Comme Flexbox, le problème était la compatibilité sur les vieux navigateurs, qui a dit IE ? Heureusement, ces derniers n’ayant que faire des versions responsive et la version desktop s’affichant sur une colonne, au final, ce problème délicat s’est réglé en partie tout seul !

Pour la liste des services associés à une rubrique, par exemple le développement web, le problème de non-support était moins gênant : les navigateurs ne le supportant pas afficheront la liste sur une unique colonne.

Ce type de positionnement est vraiment à réserver pour des menus de navigation ou des listes, je l’imagine plutôt désagréable pour lire un texte ainsi morcelé.

Autre point faible, débrouillez-vous que pour le nombres de colonnes et d’éléments soient des multiples, sinon le résultat est catastrophique ! Je n’ai pas eu le problème avec les catégories de services (6 se divise bien par/en 2 et 3), mais pour la navigation secondaire de la partie portrait (5 éléments), tintin ! Du coup, j’ai rajouté un élément vide qui n’apparaît que quand il y a deux ou trois colonnes (autrement dit à partir des smartphones en paysage et sur les tablettes), afin de pallier ce petit problème.

Une navigation secondaire du site Prezenz, utilisant CSS3 Multicolumn

Bref, des possibilités sympas, mais à utiliser avec grand discernement.

Une CSS réutilisable

Je continue de progresser en matière de CSS modulaires et réutilisables, et le moins que je puisse dire, c’est que cela rend beaucoup, mais alors vraiment beaucoup de services !

Typiquement, les demandes du genre « tu peux transformer ce bloc en lien » qui forcent parfois à replonger dans la CSS, se règlent instantanément. La CSS ne reposant pas sur une structure HTML donnée, elle reste très flexible.

Typiquement, pour les icônes passant de petite taille à grande taille dans certains menus, je me serais mal vu faire des classes spécifiques qui gèrent la même icône selon la résolution… multipliez ça par la gestion du retina et le nombre monstrueux d’icônes (une soixantaine), et c’eût été la Bérézina. Au final, j’ai opté pour un objet icône dans chaque taille (dépourvu d’infos de positionnement), que j’affiche ou non selon la résolution. D’une, cet objet a été réutilisable (ça m’a bien servi), et de deux c’était beaucoup plus simple à gérer.

Côté notation, chaque module avait ses objets, tous préfixés par le nom du module. Un changement de tag ? Rien à cirer, les styles sont appliqués sur les classes, pas sur le code. Un nouveau comportement JavaScript ? On s’en fout, les règles d’état sont là, et le JavaScript manipule des classes et non des styles en ligne.

Ajoutons à cela que les premières mises à jour pas prévues sont vite arrivées, et là, devoir replonger dans la CSS a été une étape dont je n’ai pas été mécontent… de me passer : pouvoir intégrer les nouvelles demandes uniquement grâce aux briques de RÖCSSTI, ce fut un gain de temps et de prises de tête.

Je crois avoir utilisé 4 !important dans la CSS (dont un temporaire pour les fêtes de fin d’année), à bon escient bien sûr. :)

Des performances et des sprites

Vu le nombre monstrueux d’icônes, l’option sprites CSS a vite déboulé sur le projet. Tout le monde m’avait vanté les mérites des fonctions magiques de Sass pour les sprites… j’en ai été pour mes frais ! Non pas que ces fonctions ne soient pas bien (générer une image de sprite à partir de plein d’autres, c’est vraiment pratique), mais… elles ne convenaient pas du tout à mes besoins. Cela m’a même fait perdre du temps d’essayer d’utiliser à tout prix ces fonctions. J’ai une icône pour l’état de lien, une pour l’état survolé, et une pour une troisième utilisation à part.

Du coup, j’ai bricolé une fonction Sass à la main, histoire de permettre de générer le code CSS des sprites facilement, peu importe la taille de la grille des sprites. J’avais expliqué quelques aspects de cette fonction dans un précédent billet, donc je ne m’étendrai pas plus sur le sujet. Bref, DIY : Do It Yourself (faites-le vous-même).

Un regret néanmoins, la CSS aurait pu bénéficier d’une classe factorisant le tout comme :

[class*=icon-48] {

}

J’ai pris connaissance de cette technique après avoir codé l’intégralité de la CSS… tant pis, je ferai encore mieux la prochaine fois pour les sprites, ou si je trouve le temps, je reviendrai dessus.

Côté performances, la règle d’or était : des sélecteurs courts ! Cela a d’ailleurs re-servi pour faciliter la surcharge CSS, donc pour la maintenabilité.

Des micro-datas

Afin d’avoir un contenu sémantisé, les microdatas ont été utilisées massivement. J’ai eu l’approche suivante : l’élément racine est l’agence web, comme les informations de cette dernière sont toujours juste avant le footer, pas de souci. L’élément de référence sera donc sur le body (body itemscope itemtype="http://schema.org/Corporation"), et les autres éléments viendront se greffer sur cet élément.

Ensuite, chaque item qui dépendait de l’agence était indiqué dans le contenu par la relation MakesOffer, comme les services sur une catégorie. C’est d’ailleurs cette relation qui indique que l’élément service est « enfant » de l’agence.

D’autres pages indiquent les personnes comme la page contact.

Curiosité, je pensais utiliser les metas du site pour stocker d’autres informations, malheureusement, il est impossible de balancer des id sur une balise meta, sinon le validateur ronchonne. Il ne faut d’ailleurs pas mettre d’attribut name à tort et à travers à la balise meta, sinon le validateur ronchonne un « meta name is not registered ». Par contre, il est possible de stocker des meta dans le body, sans que cela ne choque le validateur. Bizarre mais ça marche ! Comme illustré dans cette image.

Affichage des micro-datas dans le code du site Prezenz

Qu’il me soit encore permis de remercier Twikito qui les a beaucoup utilisées sur la page d’Opquast, cela m’a beaucoup aidé à comprendre comment faire.

Des petites astuces et considérations sur CSS par ci par là

Un box carré ?

Une demande particulièrement bête m’a donné du fil à retordre : certains blocs devaient être carrés, comme sur la page des services Web de Prezenz. Or, ces mêmes blocs étaient dimensionnés en pourcentages ou via Flexbox. Impossible donc de leur attribuer une hauteur.

J’ai bien glané quelques astuces sur le sujet, mais la plus simple m’a été inspirée par Nicolas Hoizey (entre Nicolas H. on se comprend) sur Twitter : utiliser une simple image carrée ! Du coup, j’ai créé une image carrée de 1 pixel de côté, et je lui ai donné une largeur de 100% de son conteneur. Ainsi mon bloc sera carré du fait de cette image. Les contenus seront positionnés en absolu dans ce bloc, qui lui sera donc en relatif.

Histoire de ne pas perdre bêtement une requête HTTP avec ce genre d’image rikikie, je les ai mises en Data-URI. Bref, KISS : Keep It Simple and Smart (restez simple et élégant).

Classes atomiques

Autre point, le recours aux classes atomiques est légèrement moins systématique lors d’une approche mobile-first par rapport à une intégration desktop-first (je n’ai pas eu envie de rentrer dans le .w60desktop et .w40mobile, j’ai préféré rester simple). Mon micro-framework en version mobile-first a appris pas mal de choses : répéter certaines classes selon la media-query utilisée, répéter certains layout, etc.

Qu’on soit clair : je ne dis pas que le concept est à jeter en mobile-first, je dis juste que j’y ai eu un peu moins recours dans ce cas. À voir si cela se confirme sur mes prochaines intégrations en mobile-first.

Approches utilisées

J’avais beaucoup apprécié la lecture de SMACSS, dont j’ai réutilisé certains de ses principes comme les règles d’état, excellent pour éviter de manipuler des styles en ligne en JavaScript (autant manipuler des règles d’état). Côté OOCSS, j’ai repris parfois quelques un de ses principes à mon compte. Idem pour l’approche BEM, et l’approche atomes/molécules.

Même si je ne les ai pas appliquées stricto sensus (BEM était trop verbeux pour mes besoins par exemple), j’en ai repris à ma sauce certains éléments pratiques :

  • les règles d’état .is-<état>, pratique et clair pour le JavaScript ;
  • les modules ;
  • quelques classes atomiques ;
  • etc.

Complexité de la CSS

Ne le cachons pas, ce genre de CSS est très efficace pour les performances, etc., mais elle est parfois complexe, autant à créer qu’à maintenir.

Ne lésinez vraiment pas sur les commentaires ni sur le sectionnage de vos CSS. Pour donner un ordre d’idée, la version Sass pèse à peu près 65 ko, la version CSS non minifiée pèse 115 ko, et la version minifiée de la CSS pèse 65 ko, 14 ko après GZIP.

Quoi qu’on en dise, ça doit être rangé là-dedans, nom d’un gadget !

Autres

Un point central : le table-layout m’a énormément servi. Si vous n’utilisez pas ce positionnement, vous devriez sérieusement reconsidérer votre avis, il est vraiment magique pour de nombreux cas, et évite un paquet de flottants et de délires d’intégrations.

D’ailleurs, selon moi, intégrer un design non trivial en mobile-first nécessité de pouvoir utiliser des positionnements relativement modernes en CSS (bref, sortir des flottants), sinon c’est la crise de nerfs assurée.

En conclusion

Non seulement cette intégration a été un bon défi, mais en plus travailler pour son agence, c’est encore plus motivant. Ne laisser que peu de concessions et mettre tout ce que je connaissais dans cette réalisation, cela m’a permis de progresser.

Un autre billet parlera des « à coté » : Google Analytics, le côté back-end et l’apport qu’il a donné au front-end, et tous les développements qui sont arrivés en plus, car lancés à plein gaz, on ne s’est pas arrêté en si bon chemin !

Ajout : petit bonus

Si vous êtes curieux, vous pouvez étudier la CSS de Prezenz version Sass.

La bonne note (le 24/12/2013)

Partant d'un tweet du compte Alsacréations parlant de Dareboost (un service qui teste la qualité et les performances des sites), une rapide discussion m'inspire une réflexion sur les services qui « notent ».

Évidemment, je ne vais pas me renier, je relayais moi-même sur OpenWeb un article de Nicolas Hoizey qui invitait à se méfier des chiffres bruts donnés tels quels : Gare aux chiffres !

Néanmoins, je ne peux m'empêcher de me dire : « et alors ? ». Même si toute mesure hors de toute interprétation est potentiellement (très) trompeuse, il y a un point sur lequel je serai beaucoup plus souple : la gratification d'un travail bien fait.

J'insiste bien sur l'expression « bien fait » et pas « parfait ».

Je constate quelque chose – même parfois chez moi – qui me déplait : cette propension qu'on a nous, travailleurs du Web, à surtout voir la brindille de travers qui cache la forêt. Si vous préférez, ce côté absolument agaçant de trouver la petite erreur sans regarder l'immense qualité du reste, ou sans regarder le contexte.

Je l'avais déjà évoqué dans mon billet retour sur le premier Opquast Day :

Faites une expérience : montrez une de vos réalisations, et vous pouvez être sûr qu’il y aura toujours quelqu’un pour pointer une « faiblesse » ou dire qu’il n’aurait pas fait ainsi. Vous aurez beau avoir fait un travail de dingue, on va vous titiller sur le point qui fâche.

Franchement, si je n'ai qu'un conseil : quand un outil vous indique que vous avez de bons points, certes ne vous y arrêtez pas… mais savourez. De la satisfaction, cela n'a jamais tué personne. Pour ma part, disons-le clairement, je n'en tire aucun sur-dimensionnement de mon égo, mais qu'est-ce que cela me fait plaisir ! En toute humilité, car cela ne m'empêche pas de chercher à faire mieux.

Quand vous parlez de vos réalisations, faites-vous plaisir, parlez aussi de vos réussites ! Même si une note échouera toujours à rendre la quantité, la motivation et la qualité d'un travail fourni (les professeurs qui liront ceci apprécieront :) ), si on vous donne une bonne note, acceptez-la et soyez-en contents, aussi imparfait ce système puisse être.

Retour sur le premier Opquast Day (le 16/12/2013)

J’ai eu le plaisir d’assister au premier Opquast Day qui a eu lieu à Paris le Vendredi 13 Décembre, dans les locaux de Mozilla. En tout cas, ni les problèmes logistiques (mon avion a eu beaucoup de retard, autant à l’aller qu’au retour), ni le manque de sommeil (concert la veille), ni le feu ni les sauterelles qui m’auront empêché d’apprécier cette journée à sa juste valeur !

Opquast : Open QUAlity STandards

Une journée sur la qualité Web, cela ressemble à quoi ?

Celle-ci a démarré par un simple tour de table des Opquast Partners, qui ont expliqué leur retour d’expérience de la mise en place de la qualité Web. Les profils sont divers et variés, certaines expériences se retrouvent. Même si je n’ai pas encore le plaisir d’en faire partie – pas encore –, à travers les expériences relatées, les problèmes, les réussites, je retrouve ce que je vis en essayant de mettre en place là où je travaille :

  • la réussite de la mise en place de divers points ;
  • les questions et les points délicats ;
  • la mise en marche de la démarche si j’ose dire !

Je constate que la fine équipe de Temesis travaille énormément en sous-marin pour aider ces équipes, du coup, le choix du mot « Partners » prend toute sa dimension. Je suis presque déçu que tout ce travail en sous-marin n’aie pas plus été mis en avant. Donc, je le dis bien haut : montrez le travail que vous avez fait, communiquez dessus ! :)

De nombreux moments sont réservés aux discussions : non sans sourire, je vois que je ne suis pas le seul à haïr Addthis et son code « abomifreux », qu’on se pose souvent le même genre de questions, et que la démarche est motivante.

Entre quelques discussions, je vois tout le credo qui anime mon travail : j’en avais déjà parlé dans la qualité un tramway nommé désir, et que ne fut ma surprise quand une participante me parle d’un retour d’expérience qui reprend mot pour mot mon article :

Ajoutons à cela que le fait de résoudre l’automatisation d’un point est souvent plus amusante que la résolution du point proprement dite : les informaticiens sont de grands joueurs toujours prompts à relever un défi ! Il m’arrive parfois de prendre trois heures pour programmer une routine qui pourrait être faite manuellement en une demi-heure. Néanmoins, si ces trois heures me permettent de gagner un quart d’heure à chaque fois, ce n’est pas une perte de temps, mais juste du temps investi.

Je retrouve également les avantages de cette démarche : quand on mise sur la qualité Web et sa mise en place, cela implique de miser sur les personnes. Pour ma part, j’ai énormément progressé depuis que j’essaie de systématiser cette démarche.

L’univers Opquast

L’autre partie de la journée nous a montré tout l’univers Opquast, ce qui a été fait et ce qui arrive :

  • la checklist Opquast mobile ;
  • les Opquast schools (excellente initiative, les écoles ont beaucoup à gagner à préparer leurs étudiants à la réalité du Web professionnel) ;
  • le retour sur investissement de la qualité Web ;
  • les ponts entre l’accessibilité et la qualité Web ;
  • Opquast websites ;
  • etc.

Pleins de choses sont en marche, et il faudrait être fou pour ne pas s’y intéresser. Cette journée a débloqué pas mal de choses dans ma petite tête, je comprends de mieux en mieux cette démarche, et je pense de plus en plus que c’est la meilleure façon d’aborder les choses en matière de Web.

Je me permets de tirer un coup de chapeau aux Opquast Partners : s’engager publiquement sur la qualité n’est pas facile (particulièrement pour les débutants). Si vous en doutez, faites une expérience : montrez une de vos réalisations, et vous pouvez être sûr qu’il y aura toujours quelqu’un pour pointer une « faiblesse » ou dire qu’il n’aurait pas fait ainsi. Vous aurez beau avoir fait un travail de dingue, on va vous titiller sur le point qui fâche. Et je ne suis pas le seul à déplorer cette attitude : Mike Monteiro dénonçait aussi cette attitude dans son livre « Métier, Web Designer ».

En tout cas, ce premier Opquast Day est assurément une réussite, en tout cas, j’ai été ravi d’y être, et j’en ressors avec la motivation. En prime, j’ai pu croiser plusieurs de mes super-héro(ïne)s du Web, ce n’est que du bonheur. :)

Une citation pour conclure : la sensation que j’ai quand je travaille sur la qualité Web, c’est que je ne fais plus des sites… je fais du Web.

Merci Temesis ! :)

Les classes atomiques en CSS, les avantages (le 06/12/2013)

Maintenant que dans le billet précédent Les classes atomiques en CSS, j’ai démonté quelques idées reçues, voyons les avantages des classes atomiques.

Design dans le navigateur

J’entends régulièrement le concept de design dans le navigateur, eh bien avec les classes atomiques, Firebug et les briques que j’ai dans RÖCSSTI, cela me permet souvent de le faire très aisément, et même – surtout – sur des sites en responsive.

Exemple : il m’arrive de devoir mettre à jour le site SEIC très rapidement (urgence, etc.). Avec les briques que j’ai dans RÖCSSTI, je construis en général très facilement ce dont j’ai besoin. Le table-layout allié aux quelques classes d’alignements font des miracles, sans pour autant détruire la structure d’un document HTML.

Plus agréable encore, cela diminue les modifications que je dois apporter à la CSS.

La CSS grossit moins, et moins vite

Je ne parle pas de l’argument légèrement fallacieux de la compression GZIP qui est améliorée (est-ce vraiment l’avantage que l’on cherche en premier ???), mais de la CSS elle-même. Voici un graphique rapidement fait qui explique bien le propos.

Le poids de la CSS grandit moins vite avec les classes atomiques

Je constate depuis plusieurs projets qu’une base bien réutilisable (donc à coups de classes atomiques)… hé bien, ça simplifie quand même bien la vie, et surtout les projets évoluent bien mieux.

Pourquoi un tel phénomène ? C’est assez simple. Dans un cas, on construit avec des mini-briques prévues pour, et dans l’autre, on a des maxi-briques, moins facilement réutilisables. Évidemment, je ne dis pas que c’est impossible de réutiliser sans les classes atomiques. C’est juste moins prévu pour. Encore une fois, les pré-processeurs aident à limiter cet aspect, mais ils le font encore mieux avec les classes atomiques.

J’avais évoqué CSS Stats, cet outil confirme bien la sensation que l’on peut avoir en tant qu’intégrateur, entre une CSS bien maintenable, et un ogre difficile à manœuvrer. Encore une fois, ce n’est qu’un outil qui donne des tendances, pas une vérité absolue. Néanmoins, il serait dommage d’ignorer ces conseils.

Des approches comme SMACSS et OOCSS se marient bien avec ce concept. Dites-vous bien que produire des CSS maintenables apporte des bénéfices à court terme, mais c’est à moyen et long termes que vous verrez une très nette différence (j’en reparlerai).

La compréhension est immédiate, même hors contexte

Sauf votre respect, le sens d’une classe, c’est très arbitraire, ou alors c’est sur un tout petit projet avec peu d’intervenants. Sur un site énorme ayant subi beaucoup de modifications, peut-être que votre bloc .bloc-news se retrouve dans les FAQ. Qui va être aussi réutilisé ailleurs. Là-dessus, le dernier développeur arrive, et ne comprend rien à la logique, qui de toute manière a disparu.

À la rigueur, il va creuser un peu, pour peu que l’intégrateur précédent ait pensé à sortir ses noms de classes des contextes, il s’en sortira un peu. Mais multipliez les intervenants, saupoudrez avec les demandes parfois contradictoires d’un client, et je peux vous assurer que la CSS qui pique les yeux, ça devient vite une réalité.

Tandis que des classes .w20 ou .aligncenter, ça cause tout de suite à un intervenant. Même s’il est nouveau, surtout s’il est nouveau.

Conclusion

C’est un véritable outil qui a de réels avantages. Et c’est un puriste élevé au grain de la classe sémantique qui tient ce discours, c’est dire. Si vous vous penchez sur des CSS maintenables, c’est un sujet incontournable.

Les sites que je maintiens et qui ont bénéficié de ces choix se portent plutôt bien. Leur CSS ne bouge quasiment plus et pourtant les mises en page évoluent. Après, comme toute approche, elle a des limites, et elle a besoin du bon sens de celui qui la manie. L’ignorer par dogmatisme serait par contre une erreur bien regrettable.

Sur le même sujet

Les classes atomiques en CSS (le 06/12/2013)

Si l’on reprend la définition du mot atome, on obtient le mot grec atomos : « qui ne peut être divisé ». Appliqué aux CSS, cela revient à dire que la classe ne contient que le minimum, autrement dit une seule propriété.

Si j’ai eu l’envie d’écrire deux autres billets là-dessus, c’est tout simplement pour démonter les propos que j’entends habituellement sur ce sujet, et qui sont souvent… à côté de la plaque.

Un atome ?

Ce concept, bien qu’utilisé largement avant, a été bien débattu sur cet article Challenging CSS Best Practices et en dehors sur d’autres sites. Le sujet est régulièrement abordé, et l’atelier que j’ai co-présenté à Paris-Web cette année n’y a pas échappé.

Petite revue non exhaustive de ce que j’entends à ce sujet.

J’ai l’impression de faire des styles en ligne

Ok, on peut avoir l’impression, et j’insiste sur le mot impression, de faire la même chose que de mettre directement des styles en ligne. Sauf que cela n’est pas du tout le cas. Exemple volontairement exagéré : en supposant que votre CSS soit correctement construite, même si vous mettez 10 classes atomiques sur un élément, cela ne pose aucun problème.

p class="mt1 mb1 pl1 automobile aligncenter left w20 etc"

Regardez l’organisation de RÖCSSTI : d’abord on a les styles globaux, ensuite les styles par page, et après la même logique pour les media-queries. L’idée est toujours d’aller du plus général au plus particulier, ce qui permet de bénéficier un maximum de la cascade CSS.

En supposant qu’il faille juste mettre à jour une valeur sur la media-query smartphone, cela se fera aisément via :

@media screen and max-width: 640px {
.etc {
margin-top: 0;
}
}

Et le problème est réglé. Bien sûr, cela suppose que votre CSS soit parfaitement ordrée et structurée, que vos sélecteurs soient parfaitement pondérés. Une évidence bien sûr ! ;)

C’est moche de mettre plusieurs classes sur un élément

Là, j’ai vraiment envie de dire : et alors ? Cela dérange qui ? Et la définition de la beauté c’est quoi ? Il faudra des arguments un peu plus costauds que ça, car il est tout à fait possible d’avoir plusieurs classes sur le même élément, et cela ne dérange personne.

Cas extrême : même si vous aviez 50 classes attachées à un élément, personne n’en aura rien à cirer (JavaScript ou n’importe quel langage peut quand même manipuler l’élément). Alors effectivement, 50 classes peuvent être compliquées pour celui qui maintient (là on parlerait plus d’arguments de maintenabilité, autant penser en classes uniques et via une approche par modules), mais en soi, l’argument de mocheté est ridicule.

C’est pas sémantique

Si je reprends le propos du point précédent, avec 50 classes, cela ne vous dispensera pas pour autant d’en attacher une 51e qui servira à la sémantique.

J’ajouterai bien que le concept de classe sémantique (à l’exception des microdatas ou de RDFa bien sûr) comme beaucoup de gens le conçoivent (à la main) est un poil subjectif. Une bonne fois pour toutes : la sémantique est bien plus dans les balises employées que dans les classes.

Il y a des classes dont je ne me servirai jamais

Personnellement, sur ma base RÖCSSTI, oui, il peut m’arriver de ne pas utiliser certaines de mes classes. Néanmoins, la perte est proprement minuscule sur une CSS gzippée. Et il y a un système fantastique : les commentaires. Pour cacher ce qui n’est pas utilisé, ce qui disparaitra à la minification.

Au pire, si cela vous dérange, utilisez un pré-processeur et transformez les classes utilitaires en placeholders que vous emploierez avec des extend, ainsi, vous serez sûr de ne pas avoir une classe inutilisée.

L’autre avantage d’avoir ces classes à disposition est tout simplement… de savoir qu’elles sont là. C’est tout simplement pratique de ne pas avoir à tout réinventer lorsque je dois reprendre et mettre à jour.

Conclusion

Comme je l’ai déjà expliqué, les classes atomiques sont un outil. Ni révolutionnairement parfait, ni mauvais. Je ne dis pas que c’est adapté à tout, mais il serait dommage de se priver de ses avantages. Cela n’interdit pas la sémantique, et ce ne sont pas des styles en ligne. Comme toujours, cela dépend du cerveau qui va les utiliser à bon escient. Ou pas.

J’ai comparé plusieurs de mes sites avec CSS Stats, les chiffres sont éloquents entre les derniers sites où je les ai pas mal utilisées comme BrieF’R Formations et d’autres sites plus « anciens » où je ne les utilisais pas : le nombre de sélecteurs, de règles, leur ré-utilisabilité, cela saute aux yeux.

Le second billet va arriver d’ici peu… le voici : les classes atomiques en CSS, les avantages.

Note de lecture : Typo et Web (le 15/11/2013)

Sur la recommandation d'Emmanuel Clément (mon senseï en matière de typographie), je me suis procuré « Typo et Web », écrit par Aurélien Foutoyet.

Typo et Web, par Aurélien Foutoyet

L'auteur pose d'abord les bases de la lisibilité à travers des études historiques, les processus de lecture, les spécificités de la lecture sur écran, etc.

Une fois ces bases posées, il étudie tous les facteurs de lisibilité sur le Web : il explique – dans un style très accessible pour les non-experts en typographie comme moi – tous les paramètres qui peuvent influer selon la configuration de l'internaute (système, navigateur, etc.).

Enfin une bonne partie sur CSS au service de la typographie vient compléter le tout, des annexes venant encore enrichir ce copieux – et délicieux – mets.

Autant le dire tout de suite, j'ai adoré ce livre. Tout est bien expliqué dans un langage accessible. Pour avoir déjà été curieux sur le sujet, expliquer la complexité des rendus d'une typo sur un navigateur (selon le moteur de rendu du système, etc.) est un sujet loin d'être simple, et pourtant, l'auteur le fait avec brio et en toute simplicité.

Rien de plus agréable quand on finit un livre de se dire : j'ai appris et compris plein de trucs ! Le format se veut court et clair, on ne tombe pas dans le pavé de 800 pages.

Si vous vous intéressez au sujet, n'hésitez plus, ce livre est fait pour vous, c'est un régal.

Pénibles (le 08/11/2013)

Franchement des fois, certaines demandes sont totalement débiles. À la rigueur tellement mal formulées ou maladroites qu'elles nous rendent fous. Qu'on se le dise : non je ne généralise pas.

Petit bestiaire non exhaustif.

Le mail que vous m'avez fait/le site/mettez ici ce que vous voulez ne marche pas (et c'est tout).

Écoutez, je sais que l'expression dit parfois que nous sommes « derrière votre site » (sous-entendu derrière la création de votre site), mais il y a quelques points importants qu'il ne faut pas oublier :

  • Nous ne sommes pas derrière votre épaule.
  • Nous sommes encore moins dans votre tête !
  • Même si nous sommes contents de nous occuper de votre site, nous avons d'autres clients. Ce qui veut dire que même si nous faisons tout pour vous montrer que vous êtes important pour nous (sans aucune ironie), vous n'êtes pas tout seul sur Terre. Hé oui. Désolé.

Plus vulgairement : ça t'arracherait d'essayer d'expliquer un poil plus précisément ton problème ? Hein, quand tu vas chez le garagiste, tu lui dis pas « ma voiture marche pas » et tu te barres, tu essaies au moins de lui décrire un peu ton putain de problème de moteur qui fait clic-clic et ta voiture qui a le hoquet quand tu accélères !!!

Hum. Broumbroum.

Comment, vous ne pouvez pas vous occuper de ça tout de suite, c'est un scandale !

Comme indiqué précédemment, nous avons d'autres clients. Même si nous mettons tout en œuvre (et nous nous mettons vraiment en quatre) pour vous faire attendre le moins possible, il peut arriver qu'il y ait une certaine attente. D'autres clients existent, et vous n'aimeriez pas être dans leur cas si vous voyez quelqu'un passer devant tout le monde sans vergogne.

Plus vulgairement : quand tu vas à la boucherie, tu prends bien un ticket et tu attends ? Hein, et quand tu vas chez le coiffeur, en général, tu prends un rendez-vous et tu attends, car son salon de coiffure est plein, tu pètes pas un scandale comme un sale enfant gâté qui n'a pas eu sa putain de friandise de suite, et tu te comportes comme une personne civilisée ayant un peu de patience, bordel !!!

Hum. Broumbroum.

Suite directe : mais comment je vais faire/je suis mort si je ne fais pas ça/mettez ici tout autre chantage affectif

Croyez que nous mesurons l'importance de votre désarroi et nous allons tout faire pour vous aider, néanmoins comprenez que si nous vous avions indiqué avoir besoin de 2 jours pour effectuer cette tâche, c'est bien que nous avions besoin… de 2 jours pour effectuer cette tâche. Comme vous nous avez laissé à peine une demi-journée, nous ne pourrons pas réaliser l'impossible.

Plus vulgairement : Dunaze, arrête de pleurnicher et assume tes conneries, si c'était si important que cela, tu n'attendrais pas la dernière minute pour m'envoyer ce que je te demande depuis 2 semaines ! En plus me dire que ton chien va mourir si ça n'est pas fait, j'en ai rien à cirer.

Hum. Broumbroum.

« Je veux un site sympa »

Certes mais encore ? La définition d'un site sympa, ce n'est quand même pas très précis.
« Sympa quoi. »
Certes… mais encore ?
« Qui donne envie quoi. »
Cf réponse précédente.
« Un beau site. »
Cf réponse précédente.

while (un semblant d'indice == false) repeat ('Certes… mais encore ?')

Hum. Broumbroum.

C'est très bien mais ne faites pas comme ça, et faites ainsi (avec une méthode/demande complètement non-sensique/horrible/mauvaise/déconseillée, genre des balises blink/marquee)

Cher client, rappelons les bases. Vous êtes le client, et nous, votre prestataire. Vous nous avez demandé de nous occuper de votre site car nous avons les compétences pour le faire, c'est notre métier, nous le connaissons, et nous connaissons aussi ce qu'il ne faut pas faire. Si nous vous invitons à ne pas faire quelque chose, c'est parce que c'est mal.

Plus vulgairement : bon écoute-moi bien espèce de pompe à merde. Quand tu vas chez le dentiste, tu lui dis pas comment faut faire, tu lui fais confiance. Et bien là c'est pareil, tu nous fais confiance ! (extrait de 99 francs, pour l'occasion)

Hum. Broumbroum.

J'ai lu un tuto qui dit ce qu'il faut faire

Merci pour cette suggestion. Néanmoins, elle ne prend pas en compte l'intégralité du problème auquel nous sommes confrontés.

Plus vulgairement : hé le petit génie, tu crois que le premier lien que tu as trouvé sur Google va régler le problème par magie, espère de trou noir à connerie ?

Hum. Broumbroum.

Mon ordinateur ne marche pas/toute autre demande connexe qui n'a rien à voir avec votre job, idéalement, dit sur un ton très accusateur et désagréable

Nous aimons vous aider. Vraiment. Sans aucune ironie. Nous aimons aider notre prochain, vous en l'occurrence.

Néanmoins, vous comprenez que développer votre site ne comporte pas la mention « gérer l'intégralité de votre parc informatique », faire le support sur PowerPoint, etc.

Plus vulgairement : hé Dugenou, dans le contrat qu'on a signé, c'est marqué qu'on s'occupe de ton site. Quand tu vas chez le menuisier, tu lui demandes pas de s'occuper de tes problèmes de plomberie ? Alors pourquoi on devrait résoudre tous tes problèmes sans être payé pour, sac à merde !

Hum. Broumbroum.

C'est trop cher, vous devriez faire comme ça (suggestion d'un CMS qui « permettrait » d'aller plus vite, d'un prix ridiculement bas, etc).

Le prix, c'est le temps que nous allons mettre pour effectuer le travail. Il faut payer les personnes qui vont travailler. Certes, vous pouvez nous suggérer des solutions alternatives, mais croyez bien qu'il n'existe aucun miracle. Soit on fait très vite, et ce n'est pas cher mais vite fait (comprenez mal fait). Soit on fait bien ou au moins correctement, mais cela prend du temps.

Plus vulgairement : déjà d'une, tu me dis pas comment faire mon métier. De deux, non, mettre en place un CMS, ta charte graphique, tes contenus pour 100 euros, NON, faut arrêter de croire au père Noël !

Hum. Broumbroum.

3 commentaires.  Commenter « Pénibles »

La discussion à trois par groupes de deux (le 02/11/2013)

J'ignore si cela vous est déjà arrivé, mais cette situation arrive parfois en agence, je suis à peu près sûr que je pourrais en faire un sketch humoristique.

Plantons le décor et imaginons : une agence de communication a un client, et elle vous demande de réaliser techniquement le site pour son client.

Plusieurs schémas sont possibles, toutefois, prenons-en un parmi d'autres : vous êtes en sous-marin, autrement dit, votre seul interlocuteur est l'agence de communication. Tant que tout va bien, cette situation perdure, et en général tout le monde est content.

Mais – car il y a bien sûr un « mais » – pour une raison lambda (même pas forcément grave, une simple absence, une question, un problème…), ce schéma va se rompre à un moment et le grand moment de folie va pouvoir commencer !

J'appelle cela la discussion à trois par groupes de deux. Un exemple :

Client de l'agence, s'adressant à vous : bonjour, je n'arrive pas à joindre l'agence, comment fait-on <insérez ici une demande lambda> ?

Vous répondez à la demande, le client est content.

10 minutes après, l'agence vous appelle :

— Nous ne vous avons pas demandé de modifier telle page, comment ça se fait ?
— C'est votre client qui nous a appelé, il n'arrivait pas à vous joindre.
— Et pourquoi vous avez fait cela ?
— Parce qu'il l'a demandé, nous n'allions quand même pas l'envoyer paître !
— Certes, mais ces points étaient en discussion, etc.

Là encore, ce sont des exemples gentils. Imaginons une scène plus méchante.

Vous à l'agence : il y a du nouveau pour les demandes, le délai va être bientôt impossible à tenir !
— On fait le maximum mais ça traine chez le client.

L'agence au client : il faudrait que nous validions ces points, sinon nous ne pourrons pas tenir le délai.
— Oui, on fait le maximum en interne.

Observation : le client dit à l'agence qu'il est le méchant.

(Quelques jours après)
Le client à l'agence : voila c'est validé.
— Merci, on s'en occupe.
— Et pour le délai ?
— Ne vous inquiétez pas, on fait le maximum.

L'agence à vous : voilà c'est validé.
— Cela va être impossible de tenir le délai, nous avions demandé deux jours, mais ne nous en laissez qu'un.
— Vous connaissez les clients…

Observation : l'agence vous dit que le client est le méchant.

(le lendemain)
Le client à l'agence : c'en est où ?
— On fait le maximum !
— Mais vous avez dit que c'était ok pour le délai.
— Écoutez, on a envoyé ça à la boîte qui s'occupe de la technique, ils ont pas répondu.

Observation : l'agence dit au client que vous êtes le méchant.

L'agence à vous : alors c'en est où ?
— On travaille encore dessus.
— Dépêchez-vous, ça commence à hurler !
— Ce n'est pas mon problème, nous vous avions annoncé le délai.

Observation : vous dites à l'agence que l'agence est le méchant.

Le client à vous : alors, pourquoi vous ne répondez pas ?
— Nous avons répondu à l'agence, il nous fallait deux jours, nous n'en avons qu'un.
— Mais pourquoi ne l'ont-ils pas dit ?

Observation : vous dites au client que l'agence est le méchant.

L'agence à vous : le client nous est tombé dessus, vous n'avez pas à discuter avec eux des délais, c'est notre client !

Observation : l'agence vous dit que vous êtes le méchant.

Le client qui monte les tours, à vous : bon alors, vous en êtes où ?
— Pu… naise, arrêtez de m'appeler en direct, cela me met dans une situation impossible avec l'agence !

Observation : vous dites au client qu'il est le méchant.

— Mais c'est mon site, je suis le client quand même, je parle à qui je veux !

Observation : le client vous dit que l'agence et vous êtes les méchants.

Vous, montant les tours, à l'agence : vous pouvez dire à votre client d'arrêter de m'appeler ? D'une je perds du temps et de deux, j'en ai marre de faire votre boulot !!

Observation : vous dites à l'agence que le client et l'agence sont les méchants.

Etc.

6 mois après, nouveau projet, les trois discutent ensemble, et tout le monde se félicite de la collaboration précédente et de ce projet très réussi.

Observation : les trois disent aux trois autres qu'ils sont les gentils. Et ça redémarre. Fin du sketch.

Évidemment, je caricature un petit peu dans l'observation, mais le schéma est rodé : au lieu de discuter clairement à trois, les trois interlocuteurs se renvoient les responsabilités ou n'assument pas clairement les leurs en écoutant les contraintes des autres. Vous savez le plus drôle ? Je n'ai même pas exagéré, si les situations s'enveniment un peu plus, vous pouvez avoir des situations dignes des pires soaps ou des pires vaudevilles.

Je devrais en écrire un livre des fois…

La solution et le problème (le 30/10/2013)

Dans mes péripéties de jeune papa, il m'arrive d'avoir la situation suivante : la tête enfarinée, je dois préparer un biberon avec peu de lumière (genre mal réveillé, ou pas envie d'être complètement réveillé, etc.).

Les graduations sont en bleu foncé, sur fond transparent avec peu de lumière… ce n'est pas très visible.

Un biberon

Même si vous pourriez croire que je vais vous parler des contrastes de couleurs, ce n'est pas le cas !

En fait, je pourrais essayer de trouver plein de solutions toutes plus tarabiscotées les unes que les autres, mais aucune ne surpasse celle-là : si je commence à verser le lait dans le biberon, la couleur blanche m'offre du coup un excellent contraste pour le bleu foncé des graduations, et je peux du coup voir ce que je suis en train de faire.

Pourquoi je vous parle de cela ?

En fait, je trouvais juste belle l'idée de me dire que la solution s'offre à moi juste parce que je me suis lancé, sans l'avoir.

Chantres de la procrastination ou si vous avez peur de vous lancer, méditez cette phrase. :)

Note de lecture : Adaptive Web Design (le 26/10/2013)

J'ai terminé il y a peu ce livre sobrement intitulé « Adaptive Web Design », écrit par Aaron Gustafson.

Adaptive Web Design, par Aaron Gustafson

Curieusement, le titre pourra induire en erreur, car on ne traite pas de design adaptatif (au sens, un site qui s'adapte totalement aux capacités de l'agent utilisateur), mais beaucoup plus d'amélioration progressive de base. Vous me direz que l'amélioration progressive, cela peut être considéré comme la base du design adaptatif – et vous n'auriez pas tort – mais on parle bien de l'amélioration progressive la plus basique qui soit, c'est-à-dire via HTML, CSS et JavaScript.

Il rappelle de grands principes, et chose très agréable, cela reste léger et pratique. Que ce soient HTML, CSS, JavaScript et même l'accessibilité, tous sont abordés de manière très simple, mais jamais simpliste. D'ailleurs, quand je parle d'amélioration progressive de base, je ne parle pas de choses basiques, mais bien de la réflexion première qui pose les bases, les fondements de nos sites Web. La première pierre si j'ose dire.

Je suis mitigé… non pas que ce livre ne soit pas bon (bien au contraire), mais ce qui m'inquiète, c'est que cette façon de voir les choses puisse être considérée comme une nouveauté, alors qu'elle doit être la base de notre façon de concevoir les sites.

J'ose espérer que les lecteurs (non débutants) ne découvriront pas totalement cette façon de penser. Pour ma part, je ne peux que rejoindre l'auteur dans cette approche et vous inciter d'en faire de même. Structure et contenu d'abord (HTML), mise en forme ensuite (CSS), interaction après (JavaScript ) et le tout saupoudré d'accessibilité.

À lire, relire et appliquer ! :)

Gestion des sprites CSS avec Sass (le 24/10/2013)

Sur le projet sur lequel je travaille actuellement, j'ai dû me coltiner la gestion de sprites CSS optimisés pour des écrans Retina, et surtout en grand nombre et dans plusieurs formats différents (genre 80 icônes avec leur version survolée et encore un troisième état, que nous appellerons « actif »).

Autant le dire, cet aspect du projet est plutôt rébarbatif, et les fonctions « magiques » de Sass de gestion des sprites m'ont vite montré leurs limites (ou les limites de mes connaissances en Sass se sont vite montrées me dira un expert en Sass :) ). En tout cas, cela ne convenait pas à mon cas.

Finalement, pour des icônes toutes semblables de ce genre (j'ai juste ajouté un fond au lieu de la transparence) :

Grilles d'icônes en sprites CSS

Voici l'approche que j'ai prise : d'abord une classe générale qui contient toutes les propriétés communes qui permettra de factoriser et ensuite chaque classe de chaque icône qui décale l'image de fond pour afficher la bonne image. Chaque icône dans ce sprite fait 48 pixels de large, pour un affichage de 24 pixels donc (optimisé Retina). Les icônes sont côte à côte par rangs de 10.

Seulement, gérer cela à la main avec 6 icônes, pas de souci, mais pour plus de 80 icônes, c'est hors de question.

Bref, j'ai bricolé une fonction Sass qui ressemble à cela :

// ici les propriétés générales 
.icon-service-general {
background-image: url('../../layout/images/icon-services-48.png');
background-repeat: no-repeat;
display: inline-block;
width: 24px;
height: 24px;
background-size: 240px 576px;
/* la moitié des dimensions de l'image du sprite : optimisation retina */
}


$x: 0;
$y: 0;
$grid: 24px;


// là je limite la liste pour l'exemple
@each $service in performance, motion, presentations, etc. {
// on factorise avec la classe « général »
.icon-service-#{$service} {
@extend .icon-service-general;
}


// je décale de tant de fois la grille
.icon-service-#{$service} {
background-position: ( -( $x * $grid ) ) ( -( $y * $grid ) );
}
// idem pour le rollover
a:hover .icon-service-#{$service},
a:active .icon-service-#{$service},
a:focus .icon-service-#{$service} {
background-position: ( - ($x * $grid) ) ( -( $y + 1) * $grid );
}


$x: $x+1;


@if $x == 10 {
// la taille de la grille = 10 icônes côte à côte
$x: 0;
$y: $y+3; // de 3 (fois la grille) en 3
}
// etc .
}

Ce qui va générer la CSS suivante :

// ici les propriétés générales 
.icon-service-general, .icon-service-performance, etc. {
// ici les propriétés communes
}


.icon-service-performance {
background-position: 0px 0px;
}
a:hover .icon-service-performance,
a:active .icon-service-performance,
a:focus .icon-service-performance {
background-position: 0px -24px;
}


/* etc. */

Le gros avantage, c'est que c'est facilement adaptable à une grille d'icônes de n'importe quelle largeur, Retina ou non. Et surtout, ça fait le sale boulot tout seul.

Bref, bien travailler pour moins travailler.

Des bisounours à Paris Web (le 19/10/2013)

Chaque année, je vois le même troll revenir après Paris Web : les bisounours.

Précisons pour ceux qui ne connaîtraient pas le sujet : certains orateurs ou participants sont taxés d'être des bisounours, autrement dit, totalement déconnectés du monde réel, sur leur nuage, dans leur pays merveilleux.

Si parfois, je reconnais que trop de bisounours-isme tue le bisounours, en clair, si cela peut m'agacer un temps, voici la réflexion que je me fais.

Je discutais avec Delphine Malassingne l'année dernière, et nous avions abordé cet aspect, voici ce que je lui ai dit :

Excuse-moi de le dire, mais… putain, heureusement qu'il y a encore des gens comme ça ! (des bisounours)

Et je complète : pas totalement aigris de la vie, de leur métier, qui ont des idéaux, des valeurs, de l'humour, de la bienveillance, pour reprendre un terme d'une conférence de cette année.

Même si je suis d'un cynisme à l'épreuve des balles, vous imaginez Paris Web sans une franche dose d'optimisme ? Autant entamer une cure de Prozac. En plus, c'est à Paris, ville d'excités par excellence.

Alors oui, quand on débarque dans cet univers, cela peut être surprenant, je me souviens avoir été surpris de l'ambiance lors de mon premier Paris Web, où j'entendais presqu'à plus soif du « l'accessibilité c'est bien, il faut y penser », où je voyais des sourires, etc.

Mais à votre avis, vaut-il mieux tomber les masques et goûter à cette ambiance si particulière ou se dire « mais non, ils planent complètement » ? Perso, je préfère faire le plein de « good vibrations ». Quand je dis que Paris Web est ma cure de thalasso, je le pense : imaginez-vous entouré de personnes compétentes, super-motivées, et aimables. Des gens qui partagent vos idéaux de partage de la connaissance, de qualité, et d'universalité du Web.

Le « problème », c'est qu'en adoptant ce carburant, potentiellement, le monde vous est offert sur un plateau.

La facilité et l'immédiateté ne sont pas fournies avec, mais ce n'est pas grave.

Et encore, je ne parle même pas de l'humain. Cette année, lors de la conférence sur le « Web qui rouille », j'ai pu parler d'un sujet incroyablement personnel avec une délicieuse personne, sans calcul, sans masque. Vous croyez que quand vous serez à l'article, ce sera le cynisme qui vous restera ? Non, ce seront les personnes.

Si je n'avais pas croisé des personnes qui croyaient dur comme fer au Web comme plateforme Universelle, qui sait où j'en serais ? Je croirais peut-être encore que les aveugles ne lisent pas de mails, que les vidéos ne peuvent pas intéresser les sourds, etc.

Autant regarder le monde avec des yeux d'enfants, ça ne change pas le monde, mais l'idée qu'on s'en fait. Et au final, ça change le monde.

Pour conclure, je paraphraserai Maître Yoda :

  • Que vais-je trouver à Paris Web ?
  • Ce que tu y apporteras.

Paris Web 2013… vu de l'orateur (le 19/10/2013)

Je reprends la plume pour vous relater l'événement, mais vu de l'autre côté de l'estrade, autrement dit de l'orateur. Et un peu de l'OpenWeb-ien.

Cette année, j'ai été particulièrement servi côté orateur, vu que je m'y suis retrouvé… à trois reprises !

Trois exercices différents, trois ressentis totalement différents.

L'intégration, ce monde du ça dépend

15 minutes sur un sujet qui me tient à cœur, à savoir :

  • Expliquer que l'intégration est un savant équilibre de pleins de facteurs, parfois même totalement extérieurs à l'intégration proprement dite ;
  • Et qu'une des meilleures façons de progresser en intégration est justement d'aller voir ailleurs que dans ce domaine.

J'ai du mal à cacher que l'immense salle du Palais Brongniart me met mal à l'aise. Autant le forum IBM peut déjà être impressionnant, mais la configuration de ce nouveau lieu… non, je ne m'y fais pas. Le public est étrangement statique. J'en viens même à me demander si je les captive ou si je les emm… dors !

Hé oui, le mythe de l'orateur en position de force en prend un coup, mais voici mon ressenti. Les retours sont pourtant positifs, mais je ne suis pas très content de ma prestation.

J'ai revu la vidéo, même si ma prestation me semble bien moins mauvaise que l'impression que j'ai eue sur scène (ce qui m'a été confirmé par des retours très positifs pour certains), nan, peut-être mieux faire !

J'ai décidé d'arrêter de sauver le monde

Un lightning talk ! Celui-ci ne sera que mon troisième, le second à Paris Web. Curieusement, même si le format est stressant et si tout est fait pour être mis en confiance – on nous présente comme des condamnés –, je suis plus prompt à larguer les amarres et à foncer en mode « berseker ». Gag : je décide de ne pas porter mes lunettes… et je me rends compte, dans la meilleure antre de l'accessibilité, que le chronomètre est en face de moi, mais bien trop loin pour que je le voie clairement ! Accrochez vos ceintures, c'est parti pour un tour de montagnes russes !

Lancé comme un missile lors d'un raid de Doolittle, je fonce comme un taré. J'ai une immense empathie pour les personnes qui assurent la vélotypie, car mon débit a dû être impossible à suivre. Afin de ne pas avoir à gérer le micro, je décide de rester en statique près du portable pour ne pas perdre une seconde avec les slides. La seule carte secrète que j'abats ici, c'est qu'en fait j'ai répété/retravaillé/fignolé au moins 50 fois ce speech durant mes trajets au boulot, avant même de savoir que le sujet était retenu. Bien m'en a pris, car je n'aurais pas pu le préparer en moins d'une semaine.

Finalement, ce sprint de moins de quatre minutes passa bien, je suis bien plus content de ma prestation. Quelques remarques après me confortent : le message est bien passé et certaines personnes ont même adoré. Je tremble comme une feuille avec la descente d'adrénaline, mais tant mieux !

Si vous vous demandez ce que ça peut faire, je n'ai qu'un conseil : essayez et mettez-y vos tripes, foncez sur un sujet qui vous tient à cœur. Dans mon cas, pas de chichis, tout ce que j'ai raconté est du 100% vécu livré sans enrobage, ça permet, si on s'emmêle les pinceaux alors que cela ne doit pas arriver vu le timing, de raccrocher les wagons alors que la locomotive prend feu.

Et si on enrichissait nos frameworks CSS ?

Jamais deux sans trois, cette fois, c'est un atelier, que j'ai eu le plaisir d'animer avec Raphaël Goetter. Ambiance détendue et salle comble. Nous avions pensé faire de petits groupes sur des sujets bien précis, vu le grand nombre de participants, nous avons improvisé complètement différemment : au final, nous lancerons des pistes autour des frameworks CSS, et nous animerons des discussions, retours d'expériences, autant les nôtres que ceux du public.

La bonne humeur ambiante fera passer très voire trop vite ce bon moment. Je fus plutôt content de ces échanges : peu dogmatiques même si certains vieux trolls ont pointé leur nez (classes sémantiques…), plutôt pratiques et pragmatiques au final. Même si les participants ont des expériences bien différentes, j'ai pu voir que les participants se posent plus ou moins les mêmes questions, ce qui montre que la réflexion de l'état de l'art est loin d'être au point mort, et c'est très bien. J'aurais vraiment aimé approfondir quelques sujets, mais ce n'est pas grave, ce n'est que partie remise.

Une surprise : certaines personnes dans le public nous font la remarque que « nous avons partagé ce que nous avons fait », comme s'il y avait une différence entre nous et les autres.
Je l'ai déjà dit, mais je le répète : la seule différence entre l'orateur et le public, c'est que l'orateur ose juste se lancer, il a autant peur que les autres.

La seule différence est que nous avons proposé en ligne nos réflexions autour de CSS au lieu de les garder pour nous. Comme je l'ai dit, je ne pensais pas que RÖCSSTI intéresserait du monde. Et pourtant, puisqu'on m'a demandé de le faire, c'est bien qu'au moins une personne a été intéressée. Alors, pourquoi personne ne serait intéressé par vos réflexions ? Et vous croyez que les orateurs ne se sont jamais plantés eux ?

Ah, et au fait, « ça dépend ».

Le point de vue de l'OpenWebien qui sommeille en l'orateur

Curieusement, ce renouvellement que je constatais dans le billet précédent se ressent aussi en tant qu'orateur : des questions que nous nous sommes déjà posées resurgissent. Est-ce un mal ou un bien ? Je n'ai pas d'avis tranché sur le sujet.

Un regret, surtout sur l'atelier : j'ai ouï dire – malheureusement à posteriori – que des débutants n'ont pas osé poser certaines questions et espéraient voir des démos des micro-frameworks. Je le redis, n'ayez pas peur de venir nous trouver si vous vous posez des questions. Je connais très peu d'orateurs à Paris Web qui rechignent à discuter… pour tout dire, je n'en connais pas. Et pour en revenir à RÖCSSTI, le t-shirt annonçait le nouveau logo, et un nouveau site complet se prépare, qui j'espère répondra à cette demande.

Chaque année, je fais le même constat : le web francophone a vraiment de quoi dire, et je trouve vraiment dommage qu'il se pose autant de questions avant d'écrire des articles par exemple. Ce qui m'inquiète encore plus est qu'il devienne incapable de faire ses propres expériences et de penser en dehors du Web anglophone : non pas que ce dernier ne soit pas intéressant (bien au contraire), mais se pâmer devant les articles anglais alors que certaines problématiques ont déjà été abordées dans de bons articles francophones… non, j'ai du mal.

Qui plus est, quel que soit l'article et/ou l'auteur, le motto « ça dépend » devrait nous inviter à prendre ce qu'il y a à prendre sans pour autant abandonner notre esprit critique, et sans pour autant relativiser le propos.

Paris Web 2013, ça dépend (le 15/10/2013)

La huitième édition de Paris Web s'est à peine achevée, et je prends la plume digitale – pardon numérique – pour relater l'événement.

Assurément, cette cuvée est celle du renouvellement. Nouveaux lieux, nouvelles têtes, nouveaux sujets. Dans la continuité néanmoins, car nous avons eu droit à un retour en force de l'accessibilité sur le devant de la scène, et les fondamentaux sont toujours là.

Les conférences

Le Palais Brongniart est un lieu somptueux, l'ancien temple de la bourse de Paris m'a ravi les yeux ainsi que fait bien monter le sang aux tempes, mais ça, c'est le privilège des orateurs. Je raconterai cette histoire plus tard.

À n'en pas douter, les sujets de cette année montrent l'évolution du métier : toujours plus d'enjeux, toujours moins de vérités absolues.

Je pourrais citer notamment la conférence sur « l'esthétique du Web qui rouille », qui pose si simplement des questions aux réponses beaucoup moins évidentes :

  • Quid du testament numérique ?
  • Quid de la survie et de la conservation de nos données à plus ou moins long terme ?

Je pourrais citer toutes les conférences que j'ai pu suivre, mais je m'en abstiendrai, car aucune ne m'a déçu.

Back to basics

En tout cas, ce retour aux sources et aux fondamentaux (de Paris Web) se voit également dans certains sujets : hautement pointus quand il s'agit d'expliquer le pourquoi du comment, et incroyablement simples dans leurs conclusions –  simples, et non simplistes.

Je pense notamment à Steve Faulkner et Jean-Pierre Villain, qui, suite à des démonstrations impressionnantes tirées respectivement de leur immense savoir, arrivent à la conclusion qu'utiliser simplement les balises à bon escient permet déjà tant de choses… (enfin j'essaie de simplifier le propos !)

Si ce Back to basics peut déplaire aux avides de sujets toujours plus pointus, je pense qu'il est non seulement souhaitable, mais même nécessaire.

Je suis un éternel débutant

En tout cas, ce qui est toujours bon à Paris Web, c'est qu'une simple discussion me rappelle combien je suis débutant, même avec 10 ans de métier : en me rendant aux conférences, j'ai eu le plaisir de discuter Web Sémantique avec un expert dans le domaine, je constate que d'immenses choses sont en mouvement, et dont je ne connais qu'une mince partie.

Après, de nombreux retours d'expériences (techniques et humains) viennent enrichir et cultiver ce partage, cette générosité ambiante. Ajoutons à cela que le fait de faire les choses sérieusement sans se prendre au sérieux permet de garder cette ambiance généreuse intacte.

Sinon, je reconnais que l'effet « wouahou » se produit moins durant les conférences sur mon domaine de prédilection, à savoir l'intégration, mais dans les sujets connexes que je ne maitrise que peu. Régulièrement, quand j'hésite entre deux conférences, je me décide à aller voir celles dont le sujet m'échappe beaucoup. Je suis rarement déçu.

D'ailleurs, même les conférences sponsors de Paris Web sont de très haute volée : on échappe ici au « bonjour, avec mon sourire de 84 dents, je viens vous vendre ma solution », et c'est très bien. Mention spéciale à Opquast et Microsoft qui ont été particulièrement de haute volée, chacun dans leurs sujets.

Le paradoxe du choix

Curiosité ou simple coïncidence, un sujet légèrement décalé parlait du paradoxe du choix. Avoir trop de choix paralyse et frustre, selon Anne Lacan.

En filigrane, nous n'avons jamais autant été mis face à nos responsabilités. Nos choix impactent durablement et profondément le métier et notre environnement. Personnellement, j'y vois un nouveau pas : on ne traite plus que de la technique en soi, mais de l'approche et de la réflexion qui est derrière. C'est intéressant, car cela permet de confronter des opinions, souvent bien plus pesées que l'on ne croit.

Le choix ne devrait pas nous paralyser, bien au contraire, il devrait être un moteur : avoir le choix, c'est pouvoir.

En conclusion

Je pense que tant que Paris Web arrivera à mêler avec un bon équilibre ces enjeux, ces sujets en filigrane, ces parties obscures, et ces retour d'expériences sans négliger les débutants, la pérennité de l'événement sera assurée. C'est un fragile équilibre qui n'est pas toujours simple à trouver. Le staff a encore assuré, je le remercie encore pour tout ce travail.

Le billet de l'orateur et du co-directeur d'OpenWeb va suivre d'ici peu…

Un lightning talk, c'est un raid de Doolittle (le 29/09/2013)

Je ne sais pas si vous avez déjà vu le film Pearl Harbor ? Durant ce dernier, une fois que les États-Unis se sont pris une sévère déconvenue, ils décident de lancer une contre-attaque afin de bombarder le territoire japonais.

Cet épisode est véridique, il s'appelle le raid de Doolittle.

L'idée était de faire l'impossible : faire décoller des bombardiers B25 depuis un porte-avion, autrement dit faire décoller en 150 mètres un appareil prévu pour le faire en 700 mètres. Pour ce faire, il a été décidé de supprimer la tourelle, remplacer la mitraillette arrière par un manche à balai, etc. Autrement dit supprimer tout ce qui n'était pas absolument indispensable à la réalisation de la mission, soit bombarder Tokyo.

Pourquoi je vous parle de cela ?

Si vous avez des problèmes à être concis, essayez une fois d'être orateur d'un lightning talk, genre à Paris Web ou Sud Web. C'est à peu près le même genre d'approche, quand vous avez votre idée, vous vous dites que c'est proprement impossible à faire tenir en 4 ou 5 minutes : ce n'est pas prévu pour, on ne peut pas supprimer telle partie, etc.

Et au final, vous allez virer tout ce qui n'est pas strictement nécessaire, trouver qu'en 6 mots vous pouvez dire ce que vous disiez en 12, gagner 10 secondes par ci, etc.

C'est un monstre travail de concision, qu'il faut tenir en plus sous une bonne perfusion d'adrénaline. Si j'étais pas très à l'aise à Sud Web, celui de Paris Web m'a vraiment fait accélérer le palpitant. Il a fallu que j'en voie la vidéo pour me rendre compte que des personnes avaient ri durant la présentation, ce dont je ne m'étais même pas aperçu durant ce court mais intense moment.

Mais… qu'est-ce que c'est bon. La meilleure école de concision que je n'ai jamais eue. Un vrai défi en soi, que je ne peux que vous conseiller de relever au moins une fois.

Qu'on se le dise : un lightning talk à Paris Web, c'est un raid de Doolittle.

Refonte de BrieF'R Formation, RÖCSSTI en version Sass (le 28/09/2013)

J'ai eu le plaisir de refondre un site conséquent, à savoir le site de BrieF'R Formations, un institut international de formations en Coaching, PNL, Hypnose ericksonienne, etc. basé à Genève.

J'avais réalisé le précédent site à grands coups de XHTML il y a 4 ans. Le nouveau site a d'ailleurs bénéficié de ce travail : toute l'administration du site a pu être reprise telle quelle. Le grand avantage de gérer une activité au lieu de gérer des pages.

Mais ce n'est bien évidemment pas de cela dont je veux parler : c'est la première réalisation conséquente à bénéficier de RÖCSSTI en version Sass, autrement dit mon micro-framework CSS propulsé par le pré-processeur Sass.

Je pourrais mentionner les variables qui apportent un certain côté pratique, mais ce n'est vraiment pas le point le plus important, même si ce dernier est agréable.

Les extend et les classes utilitaires

Le gros avantage des classes utilitaires de mon micro-framework combiné aux extend de Sass est le suivant : on peut construire ses classes avec ces briques élémentaires, le tout de manière très simple. Exemple :

.maClasse {
@extend .w10;
@extend .redborder;
}

Ce qui donnera :

.w10, .maClasse {
width: 10%;
}
.redborder, .maClasse {
border: 1px solid red;
}

Charger la structure ou la CSS ?

À très grosse échelle, cela peut permettre d'économiser sur les déclarations et de factoriser de manière redoutable. Autre conséquence, l'intégrateur a le choix de reporter la complexité des classes soit sur la CSS soit sur la structure HTML (p class="w10 redborder" peut se voir remplacé par p class="maClasse").

Encore un super-pouvoir de l'intégrateur : en faisant ainsi, il décidera de qui aura le plus les mains libres, la personnne qui gère la structure ou celle qui gère la CSS. Les fans des classes sémantiques y trouveront leur compte également.

La cohérence du projet

Globalement, le projet peut bénéficier d'une meilleure cohérence via les @extend et autres variables. Le graphisme ayant été particulièrement bien pensé par la graphiste (quasiment réalisé sans aucune image, un bonheur en CSS), l'intégration n'en a été que plus aisée.

Par contre, Sass ne fera pas de miracle si votre projet n'a pas de forte cohérence à la base.

La sensation que j'en tire est l'impression de mieux maitriser l'évolution du site. Encore une fois, maîtriser CSS vous fera apprécier d'utiliser les pré-processeurs , mais utiliser les pré-processeurs ne vous fera pas maîtriser CSS.

Retour sur le projet proprement dit

Performances web

Sur cette refonte, je dois reconnaître que Sass allié à RÖCSSTI m'ont apporté une certaine puissance et un côté pratique, c'est le premier projet où j'utilise autant le display:table, qui se dégrade plutôt bien sur le vieil IE7, le concept de dégradation gracieuse prenant réellement tout son sens. Encore une fois, le graphisme ayant été bien pensé, j'arrive à des résultats assez impressionnants : la page d'accueil pèse 146 petits ko (jQuery et utilisation de data-uri compris), et se charge en moins de 2 secondes sur un navigateur comme Firefox. Je ne parle même pas d'une seconde vue qui se fait en moins d'une seconde. La CSS minifiée et compressée (avec des data-uri dedans) ne pèse que 21 ko, ce qui reste très raisonnable.

Autrement dit, question rapidité, même si l'ancienne version était plutôt rapide, la nouvelle version la bat à plates coutures. Ajoutons que le nouveau design est beaucoup plus clair, aéré, et, disons-le clairement, cela fait du bien.

Le diable se cache dans les détails

De petits détails agréables : si vous naviguez dans une sous-navigation, vous aurez noté que le lien n'est pas juste situé sur le texte, mais sur toute la cellule qui l'entoure, comme illustré par la capture d'écran ci-dessous.

Lien survolé sur une cellule complète

Avouez quand même que c'est bien agréable, pas besoin de viser le texte uniquement pour naviguer !

Sinon question « bricoles au passage », le logo en SVG, l'utilisation des micro-datas sur le pied de page, l'amélioration discrète de l'accessibilité de l'ancienne version, etc.

Pas responsive, quoi que…

Dommage, le site n'a pas été demandé en responsive. Ceci dit, si cela devait venir, le site n'aurait pas de contre-indication pour le devenir, étant bâti en largeur relative et étant plutôt léger au chargement. Coquin de sort, même si aucune optimisation particulière n'a été prévue pour tablette, ce dernier fonctionne parfaitement sur iPad par exemple.

Ce tour de magie est possible grâce… à la non-utilisation de la balise viewport. En fait, l'iPad adapte le site en conséquence, et cette adaptation automatique se passe très bien, autant en portrait qu'en paysage.

Un peu d'OpQuast Desktop

Afin de peaufiner même si j'ai eu peu de temps, j'ai fait quelques vérifications avec l'extension Firefox Opquast Desktop. Cela m'a permis de corriger quelques menus oublis qu'il aurait été bien dommage de laisser passer.

Au final, il n'y a que 13 points signalés, et la plupart d'entre eux ne sont pas des erreurs à proprement parler. Vu le nombre de tests, c'est plutôt un bon signe.

En tout cas, c'est toujours un outil à garder dans sa trousse !

En conclusion

J'ai toujours un petit coup de coeur pour ce site, j'avais déjà énormément travaillé dessus il y a 4 ans, et le refondre ainsi en ayant l'oppurtunité de revenir à son travail d'il y a quelques années est une opportunité intéressante :

  • Je mesure le chemin parcouru, immense en 4 ans ;
  • Je suis encore plus convaincu que l'engagement sur la qualité d'un site et le retour sur investissement est sur du long terme ;
  • Et que de bonheur de continuer un chemin commencé avec une femme d'exception, même si le chemin se continue autrement.

C'est particulièrement agréable de voir l'évolution d'un site sur plus de 5 ans, on la voit aussi via les personnes, mais cela, c'est une toute autre histoire…

Faites comme moi, soyez ignorant (le 10/09/2013)

Quand je regarde un site fait il y a quelque temps, je me dis que j'étais bien ignorant.

Quand demain, je regarderai mon boulot d'aujourd'hui, je me dirai que j'étais aussi bien ignorant, et pourtant même si j'apprends toujours plus de choses, et même de plus en plus vite.

Vous connaissez beaucoup de métiers où ce propos est continuellement vrai, même pour des échelles de temps très courtes, genre à quelques mois près, alors que vous avez dix ans d'expérience ?

Bienvenue chez les excités du front-end.

Note de lecture : SMACSS, architecture évolutive et modulable des CSS (le 07/09/2013)

Grâce au travail de traduction d'Estelle Bonhomme et aux relecteurs Geoffrey Crofte et Laurent Sutterlity, j'ai eu le plaisir de lire en français le livre SMACSS, pour « Scalable and Modular Architecture for CSS », écrit par Jonathan Snook. (ajout : l'initiative de la traduction française vient de Jonathan Path)

SMACSS, Scalable and Modular Architecture for CSS

Autant ne pas tourner autour du pot, si produire des CSS réutilisables, évolutives et modulaires vous préoccupe, vous devez lire tout de suite ce livre.

Très rapide à lire et pourtant incroyablement dense, ce livre est une mine de bons conseils sur CSS. Il ne va pas vous dire comment réaliser un dégradé qui marche sur tous les navigateurs, mais bien comment organiser vos feuilles de style aussi efficacement que possible.

Selon cette approche, les règles CSS sont organisées selon 5 catégories :

  • les règles de bases, autrement dit les règles qui s'appliquent partout : la couleur des liens, le reset CSS, etc.
  • les règles d'agencement : la mise en page générale de votre page,
  • les règles de modules, autrement dit les composants de votre page (menu, barres, etc.),
  • les règles d'état, qui par exemple indiquent l'état d'un module : .is-collapsed, .is-error, etc. (utiles par exemple pour manipuler via JavaScript, mais pas seulement),
  • et les règles de thèmes, qui indiquent les thèmes du site ou de l'application, s'il en a.

Ce postulat étant posé, l'auteur explique avec force exemples comment diminuer la dépendance de la CSS à une structure donnée, la performance des sélecteurs, l'utilisation des pré-processeurs, etc. Et ce, toujours dans une optique pratique et réutilisable.

Le gros point fort de ce livre est que c'est abordé d'un point de vue très pratique et très pragmatique. L'auteur ne s'attarde pas une seconde sur les détails insignifiants, ne vous dit jamais « ne faites pas ça c'est mal », mais argumente et conseille. Et le moins qu'on puisse dire, c'est que ses conseils sont très bons.

Je me rends compte qu'il y a pas mal de SMACSS dans mes dernières intégrations avec RÖCSSTI, et cela aide beaucoup à maintenir une CSS à flots.

En conclusion, si vous êtes intéressés par le sujet, commandez-vous rapidement l'e-book en version francophone, vous auriez vraiment tort de passer à côté de cette pépite, malheureusement trop peu connue en France.

Vous ne souffrez pas assez (le 06/09/2013)

Mon année 2008 a été plutôt difficile, j'ai souffert du dos au point de ne plus arriver à marcher. Le côté vicieux de mon problème était qu'il a commencé par une petite douleur qui a progressivement augmenté, augmenté… jusqu'à un point de non-retour.

Atlas, qui porte le monde sur son dos (mythologie)

En fait, mon problème était simple : je ne souffrais pas assez. N'y voyez aucun masochisme de ma part, mais comme on dit « tant que c'est gérable, hein ! ».

J'y vois un parallèle frappant avec plein de domaines, principalement au travail mais même dans la vie. Souvent, ce qui fait qu'on évite de changer est… qu'on ne souffre pas assez. Et plus vicieux encore, on arrange souvent juste ce qu'il faut pour rester dans cette zone de « souffrance acceptable » au lieu d'aller au scalpel pour virer le pus, si j'ose dire.

Regardez, ça marche avec plein de domaines dans le Web :

  • On repousse la mise en place de la qualité Web ? C'est que vous n'en avez pas suffisamment pris dans la tronche à cause de petits oublis aux grandes conséquences.
  • Directement lié, on repousse la fin du travail à « l'arrache » ? Cela ne vous a pas encore suffisamment explosé à la figure.
  • On peut toujours confier ça à un stagiaire ? Vous n'avez pas suffisamment souffert de rattraper des bourdes alors (ce n'est pas sa faute soit dit en passant).
  • Etc. cela marche avec l'accessibilité, l'ergonomie, etc.

Cela vaut aussi pour le côté personnel, la santé, les relations. Quelques exemples :

  • Vos « amis » exagèrent ? Mais puisque vous acceptez.
  • Votre santé va mal ? Visiblement, picoler comme un trou ne vous fait pas assez souffrir pour que vous arrêtiez.
  • Votre petit(e) ami(e) vous rend fou(folle) ? Etc.

Attention, de telles pensées peuvent emmener loin. Je ne suis pas responsable des ruptures qui pourraient avoir lieu :)

D'ailleurs, je ne parle pas de détruire, mais simplement de motiver à changer pour ne plus souffrir. Le changement, cela peut être radical, mais c'est mieux que ce soit durable et étalé sur le temps. Si vous êtes un excité, vous aurez du mal à faire croire que vous êtes devenu bouddhiste le lendemain. J'appelle cela la congruence.

Pour revenir à mon histoire au début, si je n'ai qu'un conseil – métaphorique bien sûr – à vous donner : n'attendez pas de souffrir au point de ne plus pouvoir marcher…

Étrange contraste. L'instant présent. (le 04/09/2013)

L'autre jour, j'emmène mon fiston adoré au parc du village, et je me retrouve à l'accompagner en qualité de pousseur de balançoire, réceptionneur de toboggan, aide-centrifugeur sur le tourniquet, etc.

Alors qu'il m'explique à sa façon à lui les bonheurs de la balançoire, un autre papa est là avec sa fille, croquignolette à souhait. Une belle maman accompagne sa non-moins très jolie petite fille.

L'autre papa est scotché à son téléphone. J'en suis attristé pour la petite, qui nous regarde, toute interloquée. Est-ce qu'elle ne comprend pas pourquoi je ne suis pas au téléphone ? Est-ce qu'elle voudrait que je la pousse aussi sur la balançoire ? Je ne le saurai jamais.

Alors que je trouve une nouveauté – foncer vers mon fils quand il se balance en arrière et l'arrêter – qui fait éclater de rire ce dernier, du bon gros rire de bon cœur, communicatif au point que la belle maman et sa fille de tout à l'heure rient également de bon cœur, je vois cette petite qui ne pipe mot, le papa est toujours au téléphone, racontant apparemment une soirée festive.

Ce papa et sa petite partent. J'ai déjà oublié son visage, pas celui de la petite. Mon bonhomme éclate encore de rire à chaque fois que je fonce sur lui et que j'arrête sa balançoire pour mieux la relancer. Les passants sourient en le voyant.

Il est temps de partir. La belle maman et sa jolie fille nous disent au revoir et nous font signe jusqu'à l'autre bout de la place, visiblement ensoleillées du rire partagé. Je me rappelle encore leurs visages.

Étrange contraste.

L'instant présent.

Les classes sémantiques en CSS (le 27/08/2013)

C'est la rentrée, et comme toute rentrée, nous avons des splendides marronniers qui fleurissent. Précisons qu'un marronnier est un sujet de faible importance meublant une période creuse en journalisme.

En toute honnêteté, j'ignore si c'est un sujet de faible importance, toutefois, je me retrouve à en parler. De quoi ? Des classes sémantiques en HTML bien sûr !

Thou Shalt Not Divitis

Les classes, c'est ment… hic.

Les questions qui se posent sont les suivantes. Je les résume rapidement :

  1. Doit-on aller à fond vers une approche « classes réutilisables intégralement posées sur la structure HTML façon OOCSS » ? En gros <p class="right w20 aligncenter" pour un bloc de 20% de large, flottant à droite et dont le texte est centré.
  2. Doit-on garder uniquement des classes dites « sémantiques » ? Autrement dit <p class="le_nom_de_la_classe_qui_décrit_ce_qu_il_contient", par exemple <p class="auteur".

Ce genre de débat me fait sourire, car il est non-sensique et tourne à la querelle de chapelles. Revenons à la base. Je vous invite à déjà aller lire un excellent billet de Karl Dubost qui explique ce que sont les classes sémantiques à la base dans Un HTML avec class et des id, je cite (la mise en gras est de mon fait).

Le phénomène est simple et révèle le sens des priorités d'affaires. Le codeur de front a très rarement à réaliser un document sémantiquement communiquant.

J'irais même plus loin, LA question à se poser est la suivante : est-ce que l'objet contenu dans ma balise HTML doit être manipulé par une tierce personne (par exemple un collègue via du JavaScript) ou via une autre manière (une API qui extrait des données par exemple) ? (je généralise un peu la notion de communiquant)

Si votre réponse est oui, alors il faut attacher une classe sémantique à votre balise, et ce même si des classes non-sémantiques y sont déjà attachées. Juste pour dire « youhou, ce truc que j'ai positionné ainsi, je le référence comme étant tel-truc pour qu'on puisse l'atteindre et le manipuler ».

Revenons à nos deux questions plus haut. On met tout sur la structure HTML ou tout sur la CSS ? Hé bien, ça dépend du cas de figure et de votre approche bien sûr. Je le dis de suite, ce ne sont que des exemples de ma vision personnelle, ça dépend vraiment du contexte.

Des exemples

Si je reprends OOCSS, l'idée est de séparer les propriétés de positionnement d'un bloc de celles de mise en forme du même bloc. C'est pour cela que si une maquette me demande de positionner en flottant à droite avec des marges, etc. un bouton, je vais utiliser ceci avec RÖCSSTI :

<button class="right button-reload ml1"…

Dans ce cas, les classes non-sémantiques right et ml1 de RÖCSSTI suffisent à positionner le bouton, et la classe button-reload va s'occuper de styler le look du bouton proprement dit. C'est de l'OOCSS vite fait bien fait.

Si on me dit « sur la page qui affiche tel produit, il me faut un lien de retour à la liste positionné à droite », je vois pas l'intérêt d'y accrocher une classe sémantique, ce lien n'a que peu de valeur et n'a à priori pas de besoin d'être manipulé par une API extérieure ou via du JavaScript. Donc, là je le dis très clairement, je me brosse d'utiliser une classe sémantique dans ce cas.

<a class="right ml1">retour à la liste</a>

Si je tombe sur un cas où les classes non-sémantiques ne suffisent vraiment pas à couper la moutarde comme diraient les anglophones, évidemment je vais créer une classe spécifique et tant qu'à faire lui donner un poil de sens.

Autre cas, supposons qu'on me dise : « attention, la structure ne devra pas bouger, mais on aura des styles alternatifs ». Là évidemment, je vais éviter les classes non-sémantiques, car dans ce cas, elles vont inscrire dans le marbre le positionnement de mes contenus. Cela m'est déjà arrivé – et pas uniquement sur mon site personnel –, même si c'est rare. Un client dont je tairais le nom m'a imposé un redesign sur un délai quasi-intenable. Fort heureusement, la structure n'utilisait pas de classes non-sémantiques, j'ai donc retouché au minimum la structure, et j'ai tout basé le redesign sur la CSS, ce qui m'a permis de réaliser l'impossible.

Supposons que je sois dans la situation suivante : j'ai deux contributeurs peu rompus au CSS et je suis surchargé de travail. Typiquement, je vais aller vers des classes autant réutilisables que possible, pour la simple raison que mon temps sera le point le plus critique et qu'il sera plus difficile de me monopoliser, et au passage, ils comprendront mieux des classes non-sémantiques.

Etc. Les cas de figures sont tellement nombreux et interdépendants que ces choix peuvent varier. Bien sûr, ces points de vue sont purement pragmatiques. Le CMS, l'équipe, le client, vos connaissances, la taille du projet, sa complexité, etc. tout cela, ce sont des paramètres qui peuvent influer.

Et vous ferez comme moi, vous vous planterez. De votre faute ou non, mais vous vous planterez, tout simplement parce qu'un postulat de base aura changé ou était faux. Ce n'est pas un drame.

Pré-processeurs

Les pré-processeurs permettent des choses qui seraient beaucoup plus laborieuses sans, typiquement, si je reprends le premier exemple du bouton, le code pourra ressembler à cela :

<button class="button-reload"…

et dans la CSS version Sass :

.button-reload {
@extend .right; // ce qui donnera .button-reload, .right { float: right; }
@extend .ml1; // idem
}

Le pré-processeur CSS peut offrir dans certains cas la possibilité de reporter la complexité de la gestion des classes sur la CSS et non plus sur la structure HTML. Encore une fois, il n'y a pas de vérité absolue, selon les cas, cela peut rendre de grands services, et dans d'autres cas, cela peut être pénible.

Pour conclure

Comme vous pouvez le voir, selon l'approche, les choix peuvent varier. Ceci dit, ces débats incessants sont un peu stériles, car même en ayant une approche bourrin sur les classes en structure HTML, cela n'empêche de toute manière pas d'en rajouter une avec une valeur sémantique.

Quand le sage désigne la lune, l'idiot regarde le doigt.

Bref.

Tandis que l'idiot alimente des querelles de chapelles, le sage pratique CSS.

Ite missa est.

Sur le même sujet

Une petite astuce pour tester votre rythme vertical en CSS (le 21/08/2013)

Je m'intéresse particulièrement au problème de rythme vertical en CSS ces quelques jours, les dernières mises à jour de RÖCSSTI n'y sont pas étrangères d'ailleurs, même si ce sujet y était déjà traité.

Voici une petite astuce tirée de Vertical Rhythm Tool : si vous avez Stylish sous Firefox (une extension qui permet de facilement créer/gérer des styles utilisateurs), vous pouvez créer un style utilisateur et y coller ceci :

body {
background: linear-gradient(to bottom, #BA9B9A .1em, transparent .1em ) !important;
background-size: 100% 1.5em !important;
}

Par exemple, j'ai testé ça sur une page d'une de mes dernières réalisations, à savoir le site de la Société Électrique Intercommunale de la Côte. J'ai juste renommé body en #main pour mon cas.

Exemple de rythme vertical en CSS

Comme vous pouvez le voir, dans ce cas, le rythme vertical fonctionne plutôt bien.

Bien sûr, il faudra peut-être adapter le code si vous utilisez un autre navigateur et selon votre site, il faudra adapter la valeur de background-size selon le line-height de votre site. En tout cas, si votre client proteste en disant « il y a trop d'espace entre les titres et sous-titres », vous activez ce style utilisateur, et vous lui envoyez la capture d'écran pour preuve.

À propos des contrastes de texte sur le Web (le 19/08/2013)

Les contrastes de texte sont vraiment un sujet que je trouve facile à traiter :

  • on a des valeurs plutôt bien établies dans les recommandations,
  • grâce à la puissance de CSS, mettre à jour ces valeurs est d'une simplicité à l'épreuve des balles.

Pourtant, je constate encore que bon nombre de sites ne prennent pas en compte ce point. Si le laïus qui va suivre peut achever de vous convaincre de prendre quelques minutes pour traiter ce point, j'en serai le premier ravi !

Attention, tout ce qui va suivre est un ressenti personnel, n'y voyez donc pas une tentative de règle absolue.

Je constate que quand je reçois des maquettes à intégrer ou quand je crée moi-même une maquette, le point des contrastes est un des premiers que je vérifie.

Avant que cela devienne un réflexe, j'avoue que les valeurs me semblaient arbitraires, pourquoi 4,5 pour 1 et 7 pour 1 ? En fait, le meilleur moyen de comprendre ces valeurs est encore d'être confronté à une maquette qui n'atteint pas la première valeur. Je me suis dit « oh je dénature les couleurs » et en fait, une fois que j'ai trouvé un couple de valeurs correspondant un 4,5 pour 1, la sensation que j'ai est « c'est dur de revenir aux anciennes valeurs », les nouvelles étant quand même bien plus lisibles.

Et idem pour le 7 pour 1, une fois que j'ai la bonne combinaison, en fait, il n'y a rien à changer, c'est tellement agréable à côté d'une combinaison moins contrastée… qu'il me parait impossible de revenir aux précédentes valeurs. C'est confortable, agréable, ni trop ni pas assez.

L'idéal étant de respecter les valeurs de contrastes même pour les diverses formes de daltonisme, pour cela ContrastA est une excellente solution.

Au final, j'ai remarqué qu'être juste ce qu'il faut au-dessus de 7 pour 1 pour valider selon les différentes formes de daltonisme était suffisant, pas besoin d'aller chercher plus loin, les textes trop contrastés par rapport à leur fond sont même plutôt fatigants.

Voici une capture d'écran.

Différentes valeurs de contrastes : 3,24:1 ; 4,58:1 et 8,29:1

La première valeur en partant du bas est clairement insuffisante, je me fatigue les yeux. La seconde est bien plus correcte, je commence à trouver le tout agréable. La dernière offre un réel confort.

Maintenant, quand vous vous poserez la question des contrastes, faites un cadeau à vos lecteurs, offrez-leur le confort. Leurs petits yeux vous en seront reconnaissants.

Pour en savoir plus sur le sujet, vous pouvez lire mon article sur OpenWeb : les contrastes de texte sur le Web.

Les bénéfices d'une gestion de contenus efficace (le 12/08/2013)

Je travaille actuellement sur une refonte d'un site assez conséquent, et j'ai le plaisir de devoir travailler sur un site que j'ai moi-même conçu il y a quelques années. Bien sûr, j'ai pu mesurer à quel point j'ai progressé en CSS depuis, même si je n'en suis pas au point d'avoir honte de mon travail de l'époque ! :)

Le premier plaisir est de voir que j'avais pas trop mal réfléchi à l'époque, surtout côté contenus : les URLs n'auront pas à varier, et hormis quelques éléments comme le remplacement de br par des p dans certaines pages, les contenus sont étonnamment frais pour un site qui a quelques années.

C'est justement de cela dont je veux parler : le site n'utilise pas de CMS comme CMS Made Simple ou Wordpress, il a été construit quasiment de manière artisanale, avec amour, et – plus sérieusement – avec un système d'administration sur mesure.

Ce dernier, au lieu de fonctionner uniquement avec de grandes zones d'éditions riches, fonctionne plutôt avec de nombreux champs : titre, sous-titre, etc.

J'ai déjà parlé de ce système dans pourquoi gérer des pages, gérez votre activité. Certes, on pourrait me dire que ce côté artisanal et sur mesure peut coûter plus cher qu'un site fait avec un CMS plus classique – et encore, si l'on a une vision à court terme.

Là en l'occurrence, je vois de nouveaux éléments majeurs qui appuient cette approche. La refonte se passe ainsi : je n'ai pas à retoucher à l'administration du site, je ne m'occupe que du front-end. Je ne sais pas si vous mesurez le bonheur d'avoir des données quasi-indépendantes de l'ancien graphisme/présentation (alors qu'il a été alimenté pendant 4 ans), en tout cas, je peux vous assurer que c'est proprement génial. Autant pour le client – son budget surtout – que pour le développeur.

Le prix de l'interface d'administration peut donc être considéré sur au moins 2 à 3 mandats. Avec un mandat tous les 4 ans, c'est plutôt rentable. Nous sommes bien d'accord, c'est du « placement long terme » pour du Web.

Autre point directement lié, le fait d'avoir des contenus peu/pas abimés facilite assez le passage au responsive s'il est envisagé. Moins les contenus sont stylés à grands coups d'édition riche, plus il est possible de les tordre et de les présenter comme on le souhaite.

Toujours lié à cette fraicheur de contenu, si l'on doit ajouter des éléments de complexité comme des microdatas, c'est uniquement le développeur qui doit s'en soucier, le client ne s'en occupe pas une seconde… et c'est bien normal !

Dernier avantage, même si le nouveau site est radicalement différent du précédent, le client ne continue de gérer que son activité, il n'a pas à réapprendre tout pour être maitre de son site.

En tout cas, chers clients, quand nous insistons pour que vous n'ayiez pas la possibilité de faire tout et n'importe quoi côté pilotage de votre site, vous comprenez maintenant en quoi cela peut être un avantage.

Intégrer les moteurs de recherche du site sous Google Analytics (le 09/08/2013)

Dans la suite directe de mon intervention à la Kiwiparty au sujet de Google Analytics, voici une petite astuce toujours bonne à connaitre quand on développe un site qui va utiliser Google Analytics.

Il est possible d'intégrer les moteurs de recherche du site sous Analytics (ainsi le client pourra voir ce qui est le plus recherché et donc agir en conséquence), et c'est même plutôt simple à faire.

Tout d'abord, il faut aller sous la gestion du profil, dans « admin » > « profil » > « Paramètres du profil ».

Tout en bas, dans « Paramètres de recherche sur site », il faut cocher « Effectuer le suivi de la recherche sur site ». Le moteur de recherche interne au site étant un formulaire passant par GET et le formulaire étant du genre : <input type="text" name="kw" id="idsearch" />, j'ai juste eu à indiquer kw dans le champ « Paramètre de requête »

Paramétrer la recherche sous Analytics

Vous laissez reposer, il faut attendre 48 heures avant que les infos n'arrivent dans les rapports, et cela vous donne ceci dans la partie « contenus » > « recherche sur site » :

Résultats de recherche sous Analytics

Comme vous pouvez le voir, cela vous indique les recherches et même les mots clés recherchés (là je ne les ai pas affichés, comme c'est pour un client). Ce qui peut être une information très intéressante pour le client, à n'en pas douter.

Bref, c'est une petite astuce à laquelle il faut penser, toujours dans l'esprit pour le concepteur de sites de « permettre aux autres de mieux bosser en leur faisant remonter des informations ».

Je vous présente Madame Print (le 05/08/2013)

Dans l'étrange petit monde de la réalisation de sites Web, tout le monde essaie de progresser. Tout ? Non ! Un petit village résiste encore et toujours à l'envahisseur, ce village s'appelle l'agence print, que je vais surnommer « Madame Print » pour l'occasion.

Madame Print

Cette Madame n'est ni pire ni meilleure qu'autrui, toutefois, elle est souvent source de frustration voire de colère extrême pour les intégrateurs et autres développeurs de tous poils. Sa potion magique est la suivante : le Web, c'est du print.

Partant d'un tel postulat, il est aisé de comprendre que l'approche Web de Madame Print ne peut que faire des étincelles. En résumant très vulgairement, le print, c'est le domaine où l'on contrôle tout : la typo, la mise en page, etc. Le print, ce sont les cohortes de Jules César : parfaitement ordonnées, rien ne dépasse, tout est sous contrôle.

Évidemment, vouloir tout contrôler sur le Web… ahem. Oui, pour peu qu'on connaisse un peu ce média, c'est par essence complètement impossible : l'utilisateur ayant le dernier mot en toute circonstance, il peut donc sabrer la présentation en moins de temps qu'il n'en faut pour le dire (ne parlons même pas des contenus que l'utilisateur peut mettre sur le site). En soi, ce n'est pas un mal, mais pour Madame Print, c'est un crime de lèse-majesté.

Au final, le Web est vu par Madame Print comme un sous-média : par exemple, la typo y est malmenée, les navigateurs sont toujours insuffisants dans ce domaine. D'ailleurs, le site Web est un perpétuel frein à la créativité selon Madame Print. Cette dernière ne voit pas des pages Web, mais des pages tout court. En résulte la célèbre complainte des intégrateurs « y a aucune cohérence dans les styles du site ». Peu importe pour Madame Print.

Si Madame Print lâchait un peu plus prise, ses designs ne seraient pas si mal, néanmoins… elle ne connait pas les règles du Web, donc elle sort de temps en temps – très souvent – un concept non-sensique, une navigation farfelue, des maquettes avec tellement de contraintes que l'intégrateur sait déjà que le projet part au casse-pipe. Les sites en « background-first » sont par exemple une invention de Madame Print, avec le brief « poussez les contenus, le texte ne sert à rien » en guise de mot d'ordre.

On parle de contraintes, mais Madame Print est une experte de l'oubli, toujours parce que Web = print. Combien de fois vous enverra-t-elle une maquette sans un lien dans le contenu et donc sans aucun style pour l'élément le plus important du Web, le lien ? Ne parlons même pas des titres Hx, mais pourquoi voudriez-vous mettre des titres et des sous-titres, on n'est pas dans un document administratif enfin !

Curieusement, si Madame Print est toujours prompte à critiquer les navigateurs web – honteusement incapables de rendre correctement de la typo de base –, Madame Print se lâche sur les mêmes règles de typo qu'elle défend pourtant ardemment : combien de textes sans majuscules, de méconnaissance complète des règles de typographie selon les langues, de textes en gras mis entre parenthèses (important mais pas important donc), etc.

Vous noterez au passage que quand Madame Print vous demande de développer un site, les délais sont ridiculement courts. Normal, faire un site n'est pas un vrai métier pour Madame Print. Habituée des environnements maîtrisés, elle ne peut pas comprendre pourquoi selon le navigateur, le rendu peut varier. D'ailleurs, intégrer un site est une histoire de tableau pour Madame Print : comment voulez-vous contrôler tout au pixel près sans ?

Ne parlons pas de mediaqueries avec Madame Print : on parle de site en version iPad, iPhone. Allez donc lui faire comprendre que c'est la même CSS qui fait le job ! Si vous avez un peu de chance, le monde du smartphone ne l'inspirant pas – pas assez de place pour exprimer sa créativité –, elle vous sortira un « débrouillez-vous pour le mobile ». Oui, cela m'est arrivé à plusieurs reprises, et c'est le pied !

Si le front-end est une inconnue pour Madame Print, alors le back-end, c'est la plongée dans l'horreur : pourquoi parler de contenus alors qu'on parle de pages ? En plus, l'idée qu'un contenu puisse dépasser de la zone prévue pour cet effet ne risque pas d'effleurer Madame Print. « Mais le titre va s'afficher sur une ligne ! » vous dira-t-elle. Oui, mais non.

Bien sûr, Madame Print va être prompte à fustiger le CMS, sans bien évidemment se rendre compte que son design non-sensique n'est pas compatible avec une gestion de contenu, c'est juste mal pensé.

Idem pour une boutique en ligne, Madame Print va faire un truc joli, mais ne pas penser à la mise à jour de cette boutique, grosso modo où il faudra refaire le site. Mais compte tenu du temps ridiculement court qu'elle vous donne pour faire un site et de sa structure de pensée plutôt « baroque », le raisonnement se tient. Ou pas.

D'ailleurs, on blâme le CMS, mais Madame Print exècre également les systèmes de gestion de contenu : impossible de styler, toutes les pages s'affichent ennuyeusement de la même façon. Vous aurez beau lui expliquer qu'une bonne ergonomie implique d'avoir tous les éléments au même endroit et cohérents entre les pages, que nenni, c'est un frein à la créativité de Madame Print.

Voila, ce ne sont que quelques aspects de la personnalité de Madame Print. La bougresse est plus bête que méchante – quoi que –, tout simplement car son postulat conscient ou inconscient est de vouloir faire avec le Web ce qu'elle faisait en print. Bien sur, le Web étant jeune, Madame Print ne voit pas de raison d'évoluer, cette mode du Web ne sera pas durable, on finira par faire le Web comme elle a toujours appris…

Cela me plait de croire à ce « mensonge » (le 29/07/2013)

Curieuse coïncidence de l'écriture, j'avais envie d'écrire un billet sur la vérité et le mensonge, et j'apprends qu'un blog assez étonnant sobrement nommé « le blog d'un condamné » a été en fait écrit par un certain Ploum.

Je suis assez surpris qu'il en soit l'auteur, le connaissant plutôt pour ses traits d'humour linuxiens, entre autres. Si vous ne connaissez pas ce blog d'un condamné, le sujet est simple : l'auteur a appris qu'il va mourir dans 30 jours, donc potentiellement chaque billet est son dernier. Au fil des jours, on va apprendre les questions qui lui passent par la tête.

Le blog en question a connu un certain succès, ayant plus de 8000 suiveurs sur Twitter par exemple.

Curieusement, un aspect m'a surpris : de très nombreux gens se sont d'abord posé la question de savoir si ce condamné était une personne réelle ou fictive. Certains sites ont même longuement étayé sur le sujet, souvent même plus que sur le propos lui-même.

En fait, quelque part, cela me dérange. À croire qu'une histoire ne peut être que vraie ou crédible que si elle est racontée par quelqu'un qui vit vraiment cette histoire. À croire qu'aucune histoire fictive ne puisse véhiculer une vérité. Vous vous imaginez dire à la Fontaine « mais un Renard et un Corbeau qui parlent, c'est un mensonge !» ?

Pourtant, sans avoir envie d'expliquer longuement pourquoi, j'ai la conviction que certaines personnes pourront se poser les mêmes questions que ce condamné dans un cas de figure analogue. Planter des légumes et se dire qu'on ne sera pas là pour les récolter. Avoir un bébé et se dire qu'on ne sera pas là quand il passera son bac par exemple. Ou encore se dire qu'un visage aimé puisse être vu la dernière fois. Prendre réellement conscience de sa « finitude » est une expérience assez singulière, pas forcément traumatisante ou terrifiante.

La seule conclusion que j'ai, c'est que si on me disait que je n'avais plus que 30 jours, je me rendrais compte que je n'aurais pas assez de 2 vies pour m'occuper de l'essentiel.

Qu'on ne me fasse pas dire ce que je n'ai pas dit : je suis au courant qu'on trouve tout et n'importe quoi sur Internet, c'est même Abraham Lincoln qui l'a dit le premier.

Je ne sais plus qui a dit : « les poètes utilisent le mensonge pour dire la vérité ». J'aime cette citation. Je peux tout à fait avoir conscience qu'on me mente, et pourtant voir une vérité dans le propos. Ce qui m'effraie, c'est qu'il n'y ait un jour plus de personnes intermédiaires entre « je crois aveuglément tout ce que je lis » et « je ne décortique que l'origine du propos ».

À titre personnel ou professionnel, je mens tout le temps. Quand je prends une métaphore pour expliquer quelque chose à un client qui ne comprend rien aux sites Web, c'est un mensonge. Quand je dis à un gamin qu'il doit être sage pour que le Père Noël lui apporte ses cadeaux, c'est un pieu mensonge (tout le monde sait que c'est le Saint-Nicolas qui récompense les bons élèves). Et pourtant, il y a bien une part de vérité là-dedans.

Un dernier exemple : lors de la Kiwi Party, j'ai pu discuter avec un de mes héros du Web, à savoir Tristan Nitot. Nous parlions d'un excellent orateur – non présent – dont je suis très admiratif, notamment pour ses capacités de communication et sa capacité à faire des présentations improvisées au dernier moment digne d'un grand conteur. Tristan m'a dit « tu sais, c'est une impression, il doit sûrement stresser ».

Bien sûr.

Mais cela me plait de croire à ce « mensonge ». Car si je pense que cette personne le fait, alors je crois que je peux essayer aussi.

Le story-telling, les 3 histoires (le 28/07/2013)

Lors de mon précédent job, un partenaire avait un logo assez amusant, un mot qui ne voulait rien dire mais « qui sonnait bien ». Quand les gens lui demandaient d'où venait ce mot, il invoquait la traduction en sanskrit d'un mot. En général, les gens étaient fascinés et l'expression du mot avait un bon capital de sympathie.

Bien sûr, c'était l'histoire qui était racontée aux clients. La vraie histoire était que le mot en question était en fait les 3 initiales des gosses de la cousine de sa femme, ou quelque chose comme cela.

En fait, bien avant que moult conférences ne viennent nous dire que le story-telling est quelque chose d'important pour nos sites Web – et pas seulement pour ces derniers –, j'ai toujours adoré cette notion d'histoires à divers niveaux de lecture ou de compréhension.

En général, il y a :

  • la vérité basique ou la vérité première,
  • celle pour le grand public,
  • celle pour le cercle privé,
  • et parfois celle que seul l'auteur connait.

J'en ai parsemé certaines de mes animations, de mes articles ou de mes billets. Typiquement, une des dernières animations que j'ai fait avec Terragen 2 colle tout à fait à ce fonctionnement :

  • j'ai repris un paysage qui me plaisait avec Terragen 2,
  • j'ai fait une ballade au-dessus d'un paysage glacé et figé,
  • j'adore Erik Satie,
  • je raconte une sensation de solitude à ma façon, enfin, peut-être.

Parfois, les raisons sont moins glorieuses. Une personne m'a contacté pour me dire tout le bien qu'elle pense de tel choix de musique, et je n'ai jamais osé lui dire que j'ai choisi au pif ou que c'était la seule qui collait bien à l'animation.

Curieusement, c'est en mettant le plus de soi dans un travail… que ce « soi » est le plus discret. Pour vivre heureux, vivons cachés.

Et vous, aimez-vous disséminer divers niveaux de lecture dans ce que vous produisez ?

Pour visualiser les Microdatas d'une page (le 26/07/2013)

La petite astuce du jour : si comme moi, vous vous intéressez aux Microdatas et que vous suivez le Train de 13H37, vous avez entendu parler de Microdata parser.

Si vous avez la Webdevelopper Toolbar sous Firefox :

  • allez faire un petit tour dans « Outils>Régler outils »,
  • là vous pouvez cliquer sur « Ajouter… »,
  • il vous suffit de préciser le nom de l'outil, pour ma part, je l'ai baptisé « Microdata viewer »,
  • de cocher URL pour « Type d'outils »,
  • et d'indiquer http://tools.seomoves.org/microdata/?url= dans le champ URL.

Et hop, voilà un raccourci bien pratique créé vers ce service !

Le même genre d'astuce est possible :

Le plaisir d'être fainéant n'a pas de prix !

Les économies de fond de tiroir (le 25/07/2013)

Pas plus tard qu'il y a deux jours, il m'est arrivé une petite mésaventure au travail : les piles de ma souris se sont soudainement mises en grève, et j'ai dû utiliser mon ordinateur sans.

C'est toujours une bonne leçon d'accessibilité de se retrouver sans souris : d'un coup on apprécie énormément les liens d'évitement pour aller directement au contenu, les sites avec une navigation « naturelle » sont assez agréables à utiliser, etc.

Toutefois… ce n'est pas le sujet que je veux aborder. Dans ma mésaventure, bien sûr je n'avais pas de souris filaire à disposition ni de piles de secours (évidemment !). Je ne suis pas du genre à vivre au-dessus de mes moyens, et encore moins du genre à réclamer le dernier matos high-tech au travail, néanmoins la perte de temps que cela m'a occasionnée m'a fait grincer les dents. Une souris correcte vaut grand maximum 50€. J'ignore le prix de piles, mais cela ne doit pas être bien élevé non plus. Soyons honnête : je n'ai pas perdu énormément de temps, environ une demi-heure où ma productivité a chuté.

Comme c'est la deuxième fois que cela m'arrive avec des circonstances assez similaires – et cela peut potentiellement arriver de nouveau – je me dis par contre que l'investissement en une souris un poil moins énergivore ou en quelques piles de secours aurait largement été amorti. Au final, une économie de fond de tiroir s'avère bien plus coûteuse qu'un petit investissement.

Évidemment, la mésaventure qui m'est arrivée prête à sourire et n'est pas dramatique ! Toutefois, je ne peux m'empêcher de penser à certains de mes précédents postes où j'ai été confronté à ce genre de « pratiques », et où je me dis qu'à trop chercher l'économie à court terme, on finit par perdre des sommes assez considérables.

Des guides de styles pour votre intégrateur (le 16/07/2013)

Si vous êtes Web Designer/graphiste/etc. (nous dirons graphiste par simplification), et si vous voulez être aimé de votre intégrateur stressé et débordé de travail, voici quelques pistes.

Nous partirons de l'idée que l'intégrateur est plus orienté développeur front-end que Web Designer. En clair, il est moins habitué à manipuler Photoshop/Illustrator/<ce que vous voulez> que vous (et plus habitué à coder). Nous sommes bien d'accord, l'intégrateur est capable de le faire et peut le faire, mais vous serez bien plus efficace à cette tâche.

Partant de ce postulat, on peut en déduire un fait : l'export des images sera bien plus rapidement effectué par le graphiste, c'est-à-dire vous. Il vous faut donc quelques bases sur l'optimisation des images, les formats, etc. Assez des exports en qualité maximale !

Bien sûr, vous ne ferez pas de maquette sans que l'intégrateur ne vous dise un rapide « ok pas de souci avec ce que tu as fait », afin d'éviter un gros couac potentiel avec le client (qui aura validé quelque chose d'impossible à pondre sans contrainte particulière non annoncée au client). Ce n'est pas uniquement pour vous embêter, c'est aussi pour éviter de mettre toute l'équipe dans l'embarras.

C'est encore plus critique sur des sites en responsive. D'ailleurs, au moment de faire les exports, discutez avec votre intégrateur si vous n'êtes pas sûr, il pourra vous économiser du travail en vous disant « n'exporte pas ça, je le ferai en CSS ». D'ailleurs, quand vous maquettez des versions petit écran, demandez à votre intégrateur, il pourra vous aiguiller en vous disant par exemple « attention, ce genre d'adaptation est impossible pour une simple raison d'ordre du code, fais plutôt ainsi ».

Ensuite, plutôt qu'un long discours, prenons un court exemple. J'ai eu le plaisir de travailler sur le site de Myolux.

Voici le genre de guides de style que j'attends d'un graphiste : Exemple de guide de styles (PDF de 1,42 Mo).

Guides de styles, tailles de typos

En général, une image détaillée avec les dimensions des blocs vient avec, afin que je ne travaille pas au pifomètre, surtout pour la page d'accueil. Pas besoin d'un truc magnifique, une image avec quelques flèches, quelques encarts avec les dimensions me suffisent amplement.

Pour les intégrateurs (qui bavent d'envie) et les autres qui lisent ces documents, ne le cachons pas : oui, le code que mon graphiste a mis est parfois inexact/imparfait. Ceci dit, j'ai compris son intention, et c'est mon problème de traduire cette intention en CSS/HTML, pas le sien. Donc, n'en exigez pas trop non plus de votre graphiste.

Revenons à vous, chers graphistes. Vous pensez que j'en exige trop peut-être ? Mais c'est uniquement pour bien respecter votre travail que j'ai ce genre de demandes. Et c'est aussi pour ceux qui suivront que ce genre de document est vital. Accessoirement, cela montrera votre sérieux au client si vous lui fournissez ce genre de document.

On est d'accord, sur du projet ultra-rapide et rikiki, il n'y a pas besoin d'une telle armada de guides de styles, un export avec les dimensions et quelques indications rapides (liens, typo) me suffiront amplement. Néanmoins, voulez-vous prendre le risque que votre création dont vous êtes si fier soit légèrement massacrée par un intégrateur qui n'a pas le temps de faire dans le détail ?

Ajoutons à cela que quand j'ai un graphiste qui fait tant d'efforts et qui met autant de bonne volonté, je vais me plier en quatre pour freiner le moins possible sa créativité et la respecter le plus fidèlement possible, il est assez rare que je dise un « non » franc et massif à une idée venant de quelqu'un qui mouille la chemise comme on dit (sauf si j'ai une réelle impossibilité technique).

Hé oui, ce n'est qu'un juste retour des choses.

La recherche du coupable (le 14/07/2013)

Dans le même esprit que la dette technique en exemple, je vais vous raconter une histoire vécue il y a peu. Je vous propose donc une petite enquête policière : « la recherche du coupable de la chaine de production ».

Comme toute enquête, nous aurons plusieurs protagonistes :

  • le développeur,
  • le client,
  • et l'enquêteur, moi en l'occurrence.

Plantons le décor : le site Web envoie des données à un CRM via un export de données en XML. Ledit CRM renvoie également des données, toujours dans le format XML, le site ayant un parser qui mouline ces fichiers et insère les données correctement.

Tout ce qui est côté CRM est du ressort du client, tout ce qui est côté site est du ressort du développeur.

Suite à plusieurs ajouts sur le site, l'import/export des données a été modifié. Les données sont censées revenir dans un certain ordre, disons que les données « B » ont besoin des données « A » pour fonctionner correctement sur le site. À cet effet, si les données « A » ne sont pas revenues avant les données « B », elles seront stockées dans un dossier d'attente.

Et c'est là que commence notre histoire, le client appelle le développeur et signale qu'il doit y avoir un problème, le dossier en question déborde de fichiers XML. Le développeur vérifie… 350 fichiers en attente. Pour un système prévu pour être une zone très temporaire, c'est un peu fort !

Le développeur observe un peu les noms de fichiers, il constate déjà que l'export du CRM fait un peu trop de zèle : les mêmes enregistrements sont exportés plusieurs fois, parfois même à seulement quelques secondes. Coupable : le client ?

Le développeur commence un travail méticuleux de tri, le nombre de fichiers XML est réduit à une petite centaine. Le client remarque à juste titre que le système du dossier d'attente pourrait être un poil moins stupide, coupable : le développeur ?

Le développeur remarque qu'attendre 6 mois pour signaler cela n'était pas une bonne idée. Du reste, si le CRM faisait ce qui a été défini pour l'envoi de données (l'ordre d'arrivée, d'abord les données « A » et ensuite les données « B »), ils n'en seraient pas là. Coupable : le client ?

Durant l'analyse des données et du pourquoi de leur rejet par le parser, le développeur remarque que le CRM envoie des données bizarres, le parser n'est pas construit pour gérer des cas non-prévus. Pour donner un ordre d'idée, par exemple, le champ « id_web » contient le numéro de la commande au lieu d'un simple nombre. Coupable deux fois : le client ?

Là, vous seriez tenté de dire que le client a tout faux, on a défini une procédure, on sort des clous et l'on s'étonne que cela ne marche pas ! Hé bien, ce n'est pas aussi simple que cela.

Le client demande au développeur de vérifier les exports de données du site vers le CRM. Il y a deux parties qui exportent ces données. Le développeur ouvre la première et stupeur : les données avec lesquelles il popule le « id_web » sont… bien celles des numéros de commande ! Un copier/coller malheureux ou une faute d'inattention sûrement, donc le CRM ne renvoie jamais que les erreurs qu'on lui a envoyées. Coupable : le développeur ?

Le développeur vérifie la seconde partie, assez semblable à la première. Là, il doit se rendre à l'évidence, les données populant le champ « id_web » sont… bien celles des numéros de commande !!! Sauf que… le développeur a sciemment mis ces données là-dedans, il a fait une requête SQL vers la base pour sortir ces données. Là, impossible d'incriminer une erreur d'innatention ou un copier/coller malheureux. Du coup, le développeur a sûrement dû faire quelque chose qu'on lui a demandé. Coupable : le développeur ? Le client ?

Stoppons là l'enquête, même si nous aurions pu la continuer indéfiniment. Je suis sûr que nous serions arrivés avec deux accusés, une poule et un œuf.

En fait, nous avons trouvé le vrai coupable. L'enquêteur.

Il y a sûrement un coupable, une erreur primordiale, toutefois, la chercher indéfiniment peut être une vaste… perte d'énergie, surtout que cette énergie pourrait être consacrée à trouver une solution.

La recherche de l'erreur, c'est humain. La compréhension en est importante, je ne le nie pas. Maintenant, j'ai volontairement simplifié cette histoire, imaginez-là avec 5 intervenants côté « client », et 5 à 6 développeurs qui se sont suivis côté « développeur ». Imaginez également que le système ait été prévu pour fonctionner d'une certaine manière et qu'il ait été détourné de cette manière.

Moi-même, je ne fais pas exception, il m'arrive régulièrement d'être rapidement affirmatif et de dire que l'erreur ne vient pas de moi. Et il m'arrive même d'avoir raison. Toutefois, par simple honnêteté intellectuelle, je reconnais que les torts sont sûrement partagés dans bon nombre de cas. Et encore plus, je constate que passé une certaine quantité d'énergie dépensée à les chercher, cela me fatigue, et surtout, cela ne sert à rien, au mieux à se conforter dans une idée qu'on n'a pas commis d'erreur. Illusoire à partir d'un certain niveau de complexité.

Sur le même sujet, vous pouvez regarder « Le client, ce gentil méchant », une vidéo de Sud Web édition 2013.

L'importance des conférences/rencontres (le 12/07/2013)

Être intégrateur, c'est être seul. Non pas qu'on bosse seul, mais à quelques exceptions près s'ils sont dans le domaine, votre famille, vos amis, vos voisins… n'y comprennent rien. Discussion réelle avec ma voisine :

— Vous faites quoi dans la vie ?
— Je suis intégrateur.
— C'est quoi ça ?
— Je crée des sites internet si vous préférez.
— Ah, dans l'informatique donc !
— Oui !
— Et vous travaillez dans quelle fabrique ?
— …

Certifié vécu, même si c'est un des plus extrêmes. Et encore, là c'est mignon, des fois, c'est plus dans la boulet-attitude.

En fait, tu mets des images dans des pages et tu lis tes e-mails.

Comment voulez-vous être compris par des non-initiés dans ce domaine ? Hormis si vous avez la chance d'avoir des personnes pour qui l'informatique n'équivaut pas à TOUS les domaines potentiels où y a un ordinateur, en général, c'est cause perdue. Vous m'imaginez faire comprendre la beauté d'un code HTML valide ou l'utilité de mon nano-framework CSS RÖCSSTI à mon cousin paysagiste pour qui l'informatique se résume à jouer au solitaire et aller sur « Gougle » ?

Même en vulgarisant, au mieux vous aurez fait comprendre l'idée, mais pas la quintessence du propos.

Ajoutons à cela que si vous avez la malchance de bosser dans une agence pas du tout sensibilisée à la qualité, aux standards, etc. bref, « au Web bien fait », vous pouvez également vous sentir très seul au boulot. Allez parler d'accessibilité à un graphiste print pour qui l'intégration est un domaine de satanistes destructeurs de beauté graphique…

Fort heureusement, ce n'est pas mon cas, mais c'est plus fréquent que ce que l'on croit, même sans être manichéen.

Maintenant que vous voyez mieux notre monde, imaginez. Vous vous retrouvez 4 à 5 fois par an avec plein de gens passionnés, habités, engagés, parfois que vous admirez en secret depuis des années, avec qui vous discutez sur Twitter ou même qui vous ont inspiré vos idéaux. C'est intense, puissant, et cela vous fait vous sentir compris, parfois même c'est transcendant. J'ai entendu une personne parler d'histoire d'amour autour d'idéaux et de visions du Web, et je ne peux qu'acquiescer, même si l'image peut sembler forte.

Les discussions aidant, on se rend compte qu'on est plus ou moins dans les mêmes galères, qu'on cherche les mêmes choses, que tous veulent bien faire leur travail, autant pour eux que pour leurs clients. Ajoutons à cela que nos métiers autour du Web évoluent à une vitesse difficilement imaginable, donc nous devons nous tenir au courant.

Imaginez donc quand on rentre de ces rencontres et/ou conférences, on a pris une vraie dose de drogue qui nous donne une patate assez violente, d'ailleurs, certains ont parfois le contrecoup quelque temps après. Imaginez bouffer de l'accessibilité pendant 3 jours et revenir au monde réel ou il faut encore expliquer pourquoi il faut mettre un alt à une image.

Donc, pour tous ces gens qui sont totalement étrangers à ce monde : comprenez ce besoin que nous avons, laissez-nous rencontrer et discuter avec nos pairs, laissez-nous refaire le monde… quoique en matière d'internet, je dirais plutôt : laissez-nous faire ce monde.

Les trois composantes : le travail, l'argent et le temps (le 04/07/2013)

En tant qu'intégrateur, j'ai remarqué que trois composantes se mêlent et s'entre-mêlent joyeusement quand j'observe ma « carrière ». En fait, j'ai besoin de trois choses : le travail (l'expérience et l'activité), l'argent (le pognon) et le temps (libre). Et selon le nombre d'années d'expérience et la situation (familiale, professionnelle, etc.), mes besoins de chacun sont assez différents.

Trois composantes sur trois dimensions : temps, argent, travail

Évidemment, je parle de ce que je connais, mais je suis sûr que cela peut se transposer à d'autres métiers. Je précise que je parle uniquement de mon métier avec ces composantes, pas de ma vie à côté.

Typiquement, quand j'ai débuté, j'avais du temps, peu de travail et peu d'argent. Bien sûr, on a toujours besoin d'argent – il faut pouvoir vivre –, mais la priorité est surtout d'avoir du travail, afin de se faire de l'expérience.

Quand je discutais salaire avec mes premiers employeurs, l'évidence était là : j'avais plus besoin de travail que d'argent ou de temps. D'ailleurs, le temps libre que j'avais à ce moment compensait largement ce manque de travail : il me permettait d'apprendre pour justement me permettre d'avoir plus de travail.

Quelque temps après, – en toute modestie – j'ai un peu progressé dans mon métier, et même si j'avais toujours besoin de travail, j'avais plus besoin d'argent : je commençais à être plus efficace au travail, côté temps, ce que j'avais me convenait, toutefois, j'avais envie d'un peu plus de « confort » (sans avoir une vie de nabab non plus :) ). Dans ce cas, le temps peut également être mis à contribution pour obtenir plus d'argent.

Logiquement, plus il y a de travail, moins je me soucie de l'argent. Et en fait arrive une période où la chose qui manque le plus, c'est le temps. Pour faire mes projets personnels, m'investir dans des projets comme OpenWeb, etc.

Là, mon rapport au temps et à l'argent change : là où j'aurais vendu mon temps pour presque rien au début, je serai beaucoup moins enclin à utiliser mon temps libre juste pour de l'argent – même si j'en ai toujours besoin pour vivre, comme tout le monde.

Et cela varie toujours : quand j'ai dû changer de job, logiquement, le temps a été de moindre priorité. Quand le travail déborde, j'ai besoin de temps, etc.

En fait, ce que ces composantes m'ont appris, c'est de savoir mieux gérer celle que j'ai le moins à une période donnée. Idéalement, si ces composantes peuvent se nourrir entre elles en s'équilibrant, c'est parfait !

Quand une opportunité professionnelle ou la question de mettre des priorités s'impose, je réfléchis toujours ainsi : quelle composante me manque le plus ? De laquelle ai-je le plus besoin ? C'est bassement pragmatique, mais en fait, ça me simplifie beaucoup la réflexion.

Et vous, quel est votre rapport temps/travail/argent ?

Retour sur ma présentation « Google Analytics vu de l'intégrateur/développeur » (le 01/07/2013)

Deuxième partie, cette fois sur ma conférence sur Google Analytics à la Kiwi Party édition 2013.

Vous pouvez en trouver la présentation :

J'ai eu le plaisir de présenter ce sujet qui fait partie de mes habitudes de travail, l'idée était bien d'expliquer l'importance de penser à ces points en amont, et surtout de poser de bonnes bases pour comprendre et permettre ces possibilités. Sans être un expert absolu dans le domaine, le comprendre et le faciliter est une approche intelligente à mon sens.

Je constate d'ailleurs que c'est un point souvent mal connu des concepteurs de sites. Quand on parle objectifs, tunnels de conversion, etc. souvent, l'interlocuteur vous regarde et se demande de quelles bêbêtes mythologiques vous lui parlez.

Et pourtant, ce sujet a bien failli ne jamais voir le jour : je l'avais proposé à plusieurs reprises comme sujet de conférence pour d'autres événements, et il a été plusieurs fois refusé. Je me suis approprié le conseil que le collectif OpenWeb donnait à l'occasion d'un billet sur Paris Web : transformer un sujet en article, en l'occurrence, c'est le Train de 13H37 qui m'a permis d'écrire Connaître l'efficacité d'un site via Google Analytics. Je le redis, n'hésitez pas à vous lancer et à écrire sur les sujets refusés lors des conférences, sur votre blog ou sur des sites comme OpenWeb/Alsacréations/etc.

Au final, plus d'un an après avoir fait les premières propositions, finalement, je me suis retrouvé sur scène pour présenter un sujet équivalent. :)

Passé le trac du démarrage (c'est un sujet où j'ai des connaissances, mais où je suis loin d'être une brute), la conférence s'est très bien passée, d'après les retours des personnes y ayant assisté, elles ont appris de bonnes choses et ont apprécié l'approche. Si vous avez des retours à formuler, n'hésitez pas.

En tout cas, le format plus long (1 heure) que mes dernières conférences m'a permis de pouvoir aborder ce sujet avec un peu plus de sérénité et sans le stress absolu d'un lightning talk. J'ai pu aller suffisamment loin sans larguer les débutants ni trop ennuyer ceux qui connaissent plus le sujet.

Je le redis encore, merci Alsacréations d'avoir retenu ce sujet, et on remet ça quand vous voulez !

Qui sait, peut-être que ce sujet m'emmènera encore plus loin à l'avenir ? En tout cas, être refusé à plusieurs reprises lors d'appels à orateurs a été la meilleure chose qui me soit arrivée concernant ce sujet.

Kiwi party 2013, petit compte-rendu (le 01/07/2013)

J'avais déjà eu le plaisir d'être orateur lors de la précédente Kiwiparty, j'ai pu reprendre du service cette année. Petit parcours personnel de cet événement particulièrement fruité !

Kiwiparty 2013

CSS pour des livres numériques

La première conférence a été présentée par Bert Bos, rien de moins que l'un des créateurs du langage CSS. Le sujet m'a particulièrement intéressé car il a abordé les CSS destinées au print, notamment au livre numérique.

Ses slides sont ici : CSS pour des livres numériques.

J'avais déjà eu le plaisir et l'honneur de rencontrer Bert Bos lors de Sud Web 2012, et le moins qu'on puisse dire, c'est que de se retrouver devant une des personnes qui a créé l'un de vos langages préférés… hé bien, c'est quelque chose ! Toujours aussi aimable et gentil, c'est une personne extraordinaire et un puit de connaissances, s'il était besoin de le préciser.

J'aurais adoré suivre celle de Vincent de Oliveira sur CSS (voir les slides de « Ce que vous avez toujours voulu savoir sur CSS »), mais ce fut impossible pour moi : je devais animer la mienne sur Google Analytics ! J'y reviendrai plus tard. En attendant, vous pouvez jeter un œil à sa présentation, un véritable cours de CSS complet. :)

Y a pas de pépins, y a que des solutions

« Y'a pas de pépins, y'a que des solutions ! », animée par Chloé Temesvari et Philippe Roser, était une conférence très amusante, où l'on a pu voir de nombreux pépins vécus en projet, abordés avec beaucoup humour et du point de vue ergonomique si j'ose dire.

Le duo a super bien fonctionné, un régal à écouter !

Je n'ai par contre pas eu le temps de prendre connaissance de l'autre conférence en parallèle, AngularJS et le futur du développement web.

Après une délicieuse pause repas à midi – j'adore les flammenkueches et le vin blanc – la journée s'est poursuivie pour ma part avec Hugo Giraudel et une conférence sur Sass (même si j'aurais adoré suivre celle de Jean-Pierre Vincent, Accélérer ses pages Web).

Des CSS kick-ass avec Sass

Voici un sujet qui m'intéressait particulièrement, m'y étant mis depuis quelque temps avec mon « nano-framework » CSS RÖCSSTI.

Dans un style précis et hyper-efficace, Hugo Giraudel nous a montré moult exemples d'utilisations du préprocesseur Sass, et surtout de bonnes réflexions dans leur utilisation avec CSS.

Les slides sont également disponibles : des CSS kick-ass avec Sass.

Comprendre les pointer events en décortiquant le polyfill hand.js

Là, c'était un peu la surprise, j'hésitais entre les deux choix proposés (L'accessibilité, mon ingrédient secret de Jennifer Noesser étant le second choix), et je me suis dit « allons voir quelque chose de totalement nouveau », nouveau pour moi en tout cas, ne connaissant strictement rien à ce domaine.

David Rousset a réussi le tour de force de bien expliquer un sujet auquel je ne connaissais… que dalle. C'était expliqué très simplement, et puis… voir une démo d'Internet Explorer 11 avec WebGl, quelle surprise !

Encore une fois, le choix suivant fut cornélien.

L'intégration d'e-mails responsive

Rémi Parmentier, aussi connu sous le pseudo @Hteumeuleu, a montré ses diverses techniques pour créer des e-mails responsive. Très drôlement présenté, et pourtant sur un sujet aussi horriblement compliqué. J'ignore si vous avez déjà eu le plaisir d'intégrer des newsletters, mais cela devient rapidement ch… pénible. Imaginez alors en responsive, c'est infernal.

Les slides sont disponibles : L'intégration d'e-mails responsive.

La conférence en même temps fut donnée par Romy : du zoning au mockup, itinéraire d'une maquette web. Un modèle de clarté, comme toujours avec l'auteure.

Firefox OS

La dernière conférence que j'ai pu suivre était animée par Tristan Nitot. Déjà ravi d'avoir pu manger à midi à ses côtés (10 ans que je voulais le saluer autrement que via internet interposé), j'avoue… que cette conférence m'a fait un drôle d'effet. L'entendre parler de l'universalité du Web et de tous ces sujets aussi importants… j'ai eu l'impression qu'on me faisait défiler 10 ans d'OpenWeb devant les yeux (désolé, je n'ai pas trouvé mieux comme métaphore). J'ignore si quelqu'un a remarqué l'émotion que ça m'a occasionné, étant discrètement installé au fond de la salle.

J'espère que l'assistance a mesuré l'importance de ces paroles. Ensuite, le plaisir de voir ce projet fou qu'est Firefox OS prendre vie est un régal, j'imagine que nous ne mesurerons son importance que dans quelque temps.

Côté organisation

Comme chaque année, la fine équipe d'Alsacréations nous a reçus en toute simplicité… comme des rois. Toujours prompts à répondre à la moindre de nos demandes, sans jamais se prendre au sérieux, c'est un pur bonheur. Ajoutons à cela que l'événement est gratuit, et là, vous ne pourrez dire que comme moi :

chapeau bas la Team Alsacréations, vous avez assuré comme des chefs, merci pour ce magnifique moment !

Quant à ma conférence, ce billet étant déjà assez long, je vais aborder le sujet dans un autre billet à suivre.

Mettre du SVG dans vos logos (le 24/06/2013)

Avec tous ces sites en responsive, le problème d'optimiser certaines images pour les écrans à haute densité de pixels – appelés Retina par abus de langage – commence à se faire sentir.

Disons-le très net : j'ai très peu de demandes expresses de clients sur le sujet de l'optimisation Retina. Toutefois, comme j'aime optimiser en standard tout ce qui peut l'être aisément, j'ai pris l'habitude de demander à mon graphiste chéri des exports SVG des logos des sites internet. Ainsi, le fait d'avoir un format vectorisé solutionne de facto le rendu du logo sur ces écrans, sans pour autant sacrifier le côté performances du site ni le fonctionnement de ce dernier.

Prenons donc un exemple, le logo du site de l'agence CSM.

Voici le code du logo :

<a href="../fr/" accesskey="1">
<!--[if lte IE 8]>
<img src="../layout/images/logo-csm.png" alt="Retour à l'accueil de CSM" width="240" height="84" />
<![endif]-->
<!--[if gt IE 8]><!-->
<img src="../layout/images/svg/logo-csm.svg" alt="Retour à l'accueil de CSM" width="240" height="84" onerror="this.removeAttribute('onerror'); this.src='../layout/images/logo-csm.png';" />
<!--<![endif]-->
</a>

Dans l'idée, SVG étant supporté partout sauf pour IE8 et inférieurs, on proposera donc le logo en SVG pour tout le monde, et en roue de secours une version dans un format GIF/JPEG ou PNG pour les vieux IE.

Pour le cas où un quelconque navigateur autre que les vieux IE ne supporte pas les images en SVG, l'erreur sera détectée et la version en PNG prendra automatiquement le relai (une sécurité sûrement dispensable, mais on n'est jamais trop prudent sur une image aussi importante qu'un logo).

Ajout : un tweet me signale qu'Android 2.x pourrait bénéficier de cette sécurité, pas si dispensable que cela donc !

Côté htaccess, il ne faudra pas oublier ces lignes :

# activera la compression pour SVG
AddOutputFilter INCLUDES;DEFLATE svg
AddOutputFilter INCLUDES;DEFLATE image/svg+xml

# fera fonctionner les fontes SVG sur iPad
AddType image/svg+xml svg svgz
AddEncoding gzip svgz

Les premières activeront la compression, faisant passer le poids du fichier SVG de 24 ko à 7 ko. La suite garantira que le type MIME soit correctement défini pour faire fonctionner les polices SVG sur iPad.

Et voilà ! Sans révolutionner le monde, cette méthode sera un petit plus pour vos sites, en attendant qu'on ait une solution meilleure pour toutes les images sur les sites responsive.

Si vous avez envie de vous amuser, vous pouvez utiliser la ligne suivante dans votre head.

<link rel="logo" type="image/svg" href="http://www.csm-sa.ch/layout/images/svg/logo-csm.svg" />

L'exemple vient du site relogo, ce n'est pas un standard, c'est juste rigolo. :)

Pour en lire plus sur le sujet, vous pouvez lire ou relire cet article de Stéphanie Walter : Un logo cliquable SVG avec alternatives.

Quelques mauvaises croyances en CSS (le 22/06/2013)

Rémi parlait un jour des licornes en intégration : à juste titre il montrait que certains bouts de code ont été totalement inventés et n'existent que dans l'imaginaire collectif.

Cela m'a donné une idée : tuer/rappeler quelques mauvaises croyances, trop souvent présentes chez les débutants. C'est loin d'être exhaustif, mais là ce sont celles que j'ai le plus vues.

Pour avoir l'infobulle sur une image, il faut mettre un alt

On remercie bien Internet Explorer 7 et inférieurs qui ont insufflé cette croyance complètement inexacte : c'est bien sûr l'attribut title qui permet d'afficher une infobulle sur tous les navigateurs. Combien de personnes sont tombées dans le piège de ce rendu non standard ! Au point que cette erreur soit mentionnée sur Wikipédia.

Le display:inline-block ne marche pas sur Internet Explorer

Effectivement, il ne fonctionne pas parfaitement sous les Internet Explorer inférieurs au 8. Toutefois, si l'élément est à la base de type inline, utiliser inline-block marchera parfaitement même sur les vieux Internet Explorer. C'est très pratique pour les liens, les label, et plein d'autres cas !

Le combo float:left; display:block;

Là je ne sais pas trop d'où vient cette croyance : le fait d'appliquer float à un élément suffit à pouvoir le dimensionner, le display:block; n'est pas nécessaire. Peut-être est-ce une croyance héritée du bug double margin float des vieux Internet Explorer ? Ce but se résolvait en mettant display:inline; dans des éléments positionnés en flottant, alors est-ce que le réflexe serait resté ?

Il est impossible de sélectionner via CSS selon les attributs d'un élément HTML

Cette croyance est celle qui me désole le plus, combien de personnes croient encore qu'il est impossible par exemple de cibler en CSS les liens dont l'attribut hreflang est en anglais.

Alors que cela se fait très bêtement via a[hreflang="en"]. Vous pouvez relire sur ce sujet les 30 sélecteurs CSS à connaître absolument.

Et vous, vous connaissez d'autres croyances de ce genre ?

Ajout : width: 100%, tu es le Mal ! et Le saviez-vous ? display est inutile sur un élément flottant par Raphaël Goetter abordent ces sujets et d'autres dans la même veine.

Cher client, comprenez ma satisfaction (le 18/06/2013)

Ce billet est la suite de « cher client, je comprends votre colère ». Relisez-le pour comprendre toute la quintessence du propos qui suit.

Cher client (vous permettrez que je vous appelle ainsi), comprenez ma satisfaction.

L'agence de communication continue à nous faire part de vos besoins de maintenance. Nous les exécutons en temps et en heure. Nous supposons que la légère tension suite à la mise en ligne mouvementée dont nous vous avions parlé dans notre précédent message est donc terminée, nous nous en réjouissons.

Nous constatons que certains de vos employés nous contactent directement. Cela nous fait plaisir, même si, léger point de détail, nous ne savons à qui envoyer la facture. Officiellement, nous ne sommes que le sous-traitant de l'agence de communication. Cette dernière nous permet de facturer les travaux que vous leur commandez.

Il faudra que nous résolvions ce léger problème, car 40 heures de développements supplémentaires et de support direct, c'est quand même une somme. Sans vouloir être insistant car je sais que votre emploi du temps est chargé, fort heureusement, nous arrivons, enfin, vous arrivez à nous joindre, surtout quand vous avez une demande.

Même si vous nous avez indiqué ne pas avoir eu de documentation concernant le fonctionnement du CMS (ce qui nous semble donc être confirmé par vos employés qui nous appellent régulièrement), nous pouvons vous assurer que nous avons transmis une documentation complète à l'agence de communication.

Nous ne pouvons croire qu'ils aient oublié de vous la transmettre, car un de vos employés nous a fait part d'une documentation qui leur a été envoyée. Nous avons juste eu du mal à comprendre que la documentation avait été renommée, enfin, vu que l'agence de communication est en théorie votre prestataire, nous pouvons comprendre qu'ils aient repris notre travail. Toutefois, votre employé a eu la présence d'esprit de nous l'envoyer, afin que nous vérifions que nous parlions bien de la même documentation, seuls les logos ont été changés.

Qu'il me soit permis par ailleurs de mentionner que vos employés semblent très contents de notre réactivité, ils s'adressent désormais de plus en plus souvent à nous en direct, et non plus à l'agence de communication. D'ailleurs, cette dernière nous a signalé que nous n'avions pas à traiter avec vous ainsi… toutefois, vu la situation lors de la dernière mise en ligne, nous préférons vous rendre service le plus rapidement possible, même si cette situation de discussion à trois par groupes de deux peut être parfois embarrassante.

En tout cas, nous sommes ravis, les dernières modifications ont pu nous permettre de voir que vous aviez lancé un nouveau site basé sur le template que nous avions intégré. Nous avons pu noter que le nom de votre ancien prestataire remplaçait celui de l'agence de communication, nous en déduisons donc qu'il a repris et apprécié ce que nous avions fait. Nous nous réjouissons de voir également que les propos très durs que vous avez eus à leur encontre et dont vous nous aviez fait part n'étaient pas définitifs.

En tout cas, vous pouvez être sûr que ce dernier est toujours d'un grand professionnalisme : il a repris la CSS expurgée (on appelle cette opération la minification), ce qui implique la perte des commentaires dans la CSS.

C'est dommage, nous aurions bien aimé que le framework CSS qui a permis la création de votre site soit cité, car la licence de ce dernier (gratuit, est-il nécessaire de le rappeler ?) invite seulement à citer l'auteur original. Néanmoins, ce n'est pas grave, nous prenons acte et indiquerons à ce dernier combien vous avez apprécié son travail.

Cordialement.

Prenez le temps d'absorber (le 15/06/2013)

Quand j'étais étudiant en DEUG MIAS, j'ai eu des cours passionnants comme la thermodynamique.

Bon, en fait, je suis un menteur, certains de ces cours ne m'ont jamais passionné, j'y ai même eu les notes les plus calamiteuses de toute ma vie en partiels. Néanmoins, j'ai pu voir la différence entre effort continu et régulier (j'apprends toute l'année) et effort brutal (j'apprends à l'arrache avant les partiels).

écritures cunéiforme - ce à quoi va ressembler un cours de thermo si vous apprenez à la rache

Tout cela me ramène à mon métier d'intégrateur et à sa veille permanente parfois angoissante pour les débutants. La course à la puissance effrénée que se mènent certains à grands renforts d'articles toujours à la pointe de la dernière API – absolument inutilisable en production – ou de je-ne-sais-quelle-méthode-à-la-mode ne doit pas vous détourner du seul vrai sens de cet amoncellement de connaissance doit vous apporter : l'outil, la seule bonne chose sur laquelle miser, c'est votre cerveau, votre expérience, votre savoir-faire, vos connaissances, bref : vous.

Ne misez sur un outil que si ce dernier vous permet de magnifier vos connaissances… ou le cas échéant s'il vous libère beaucoup de temps pour le faire.

Si comme moi vous adorez lire des tonnes de bouquins et en partager la lecture, j'insiste : faites-le pour votre bon plaisir, et donnez-vous le temps pour les digérer… ou en tirer la substantifique moelle comme dirait ce bon vieux Rabelais.

Pourquoi ce propos ?

Je constate que les débutants ont tendance à se focaliser sur la pure technique et surtout sur l'amoncellement de cette dernière. Connaître énormément de technique, dans le métier d'intégrateur, c'est très bien, ça, je ne vais pas dire le contraire ! Néanmoins bouffer de la technique pour en bouffer sans avoir pris le temps de la digérer, d'en comprendre les enjeux, d'en connaître les implications, c'est autant suicidaire que de ne pas faire de veille technologique.

Je peux vous en donner un exemple avec ma propre personne : un des derniers ajouts sur mon framework CSS RÖCSSTI est la possibilité d'utiliser le positionnement tabulaire. J'aurais pu l'ajouter il y a très longtemps sans chercher plus loin : hop, un copier/coller depuis KNACSS et on n'en parlait plus. Seulement, je le dis tout net : même si ce positionnement a énormément d'avantages, je ne m'en servais que très peu.

Le premier – mauvais – réflexe ayant déjà été évité (pomper bêtement sans utiliser), j'aurais également pu me précipiter directement dans le second : me dire « puisque Untel l'utilise, alors je vais en faire de même, sans chercher plus loin » (utiliser bêtement sans mesurer).

Non, non, cent fois non. Ce n'est pas parce que Untel dit cela que ça a force de vérité absolue. C'est sûrement intéressant (tout est intéressant dans notre métier, surtout si vous suivez quelques bonnes personnes sur Twitter par exemple), et donc digne d'intérêt. De là à y aller les yeux fermés, non. N'oubliez jamais que les paroles d'une personne sont assujetties à un contexte ! Coquin de sort : on a tendance à croire que ce contexte est absent parce que les articles assomment le lecteur avec des formes affirmatives en mode enclume (les articles anglophones sont très forts à ce jeu).

Or c'est bien évidemment faux : la pratique vous apprendra à voir quels choix faire à quels moments. D'où l'intérêt de faire beaucoup de pratique.

Selon moi, le bon réflexe est de savoir prendre son temps : si vous pratiquez suffisamment, vous allez avoir un cas où cette connaissance stockée dans votre crâne va montrer son utilité. Pour reprendre mon exemple avec RÖCSSTI, j'ai récemment eu le cas où le positionnement tabulaire résolvait un problème auquel j'étais confronté, et plaisir suprême, il ne rentrait pas en contradiction avec les autres navigateurs – IE7 principalement – pour permettre l'affichage correct (ce dernier ayant eu un fix via une classe conditionnelle, que vous pouvez d'ailleurs retrouver dans RÖCSSTI).

D'expérience, il suffit en général de se poser la question « quand vais-je bien pouvoir utiliser ce truc ? » pour que la pratique se charge de vous offrir un exemple sur un plateau d'argent ! Donc ne vous affolez pas de ne pas utiliser le dernier truc à la mode, cela viendra.

Grosse mise à jour de RÖCSSTI (le 11/06/2013)

Une fois n'est pas coutume, c'est une mise à jour majeure que vient de vivre mon « micro-framework » CSS RÖCSSTI.

Au menu :

  • une réorganisation globale des différentes parties, avec notamment l'ajout de sections dédiées aux breakpoints mineurs,
  • une amélioration des commentaires indiquant les sections, afin de pouvoir mieux les repérer quand on navigue dans la feuille de style,
  • l'ajout de la possibilité de styler des éléments avec le table layout (inspiré par les derniers couacs de rendus sur l'iPad),
  • etc.

Si le terme était encore à la mode, je dirais que RÖCSSTI vient de passer en version 2.0 ! :)

En prime, RÖCSSTI vient de s'offrir une version LESS. Si vous ne connaissez pas ce pré-processeur CSS, je vous invite à consulter le site officiel de LESS. Différentes variables sont en début de fichier, pour une productivité (= fainéantise) maximale.

Pour l'instant, la version LESS de RÖCSSTI est disponible en français sur Github, elle sera traduite dès que possible dans la langue de Shakespeare.

Vivre et laisser écrire (le 10/06/2013)

J'ai eu le plaisir d'écrire un article sur la mise en place de la qualité Web pour le site w3qualité. Ce dernier s'intitule « la qualité Web, un tramway nommé désir ».

Une fois n'est pas coutume, j'ai envie de partager non pas un article en question, mais plutôt le cheminement qui mène à cet article.

La première étape, celle que je ne peux pas expliquer, c'est l'idée. J'ai eu cette idée, elle est venue toute pimpante. Enfin, je dis toute pimpante, c'est un peu brut de décoffrage. Bon, très brut de décoffrage.

Ma première idée était de montrer la qualité Web de manière offensive, en somme de montrer qu'en s'emparant de ce sujet, il peut être un bon vecteur de changement et d'amélioration. Souvent, c'est un vocabulaire qui sonne « défensif » quand j'entends parler de qualité Web (éviter les risques, on doit y venir, etc. ), et comme j'ai un esprit de contradiction, je me suis dit : « faisons l'inverse ! ». (ce qui ne veut pas dire que le vocabulaire défensif ne soit pas approprié à la qualité Web !)

Bref, l'idée est là : prendre un contrepied et faire un retour d'expérience. Arrive l'étape la plus dure : résumer de manière accrocheuse et synthétique quelque chose qui n'est déjà pas totalement débroussaillé dans mon crâne pour le proposer au site w3qualité. Comme d'habitude, je mise sur mon enthousiasme et je livre en vrac l'idée qui me trotte en tête. L'idée tente le collectif du site.

Après, il n'y a plus qu'à raconter l'histoire. C'est encore le plus facile, toutes ces idées qui s'entrechoquent dans mon crâne ne demandent qu'à être tapotées sur ma tablette, vu que ce sont principalement des retours d'expérience. En général, je commence toujours par taper dans une note le brouillon. En deux soirées, l'article est dégrossi, j'ai juste raconté ma vision personnelle de la qualité Web. Un peu de rangement, et la proposition est faite.

Bien sûr, impossible de continuer la saisie sur iPad, pour coller avec mes propres standards, il faut que je puisse mettre des tags HTML, des abbr, respecter quelques conventions de typo, etc.

Chemin faisant et après une remarque de Delphine, je m'aperçois que ma première idée de métaphore guerrière a du plomb dans l'aile si j'ose dire : en fait, sans trop m'en rendre compte, j'ai écrit une approche de la qualité façon force tranquille que bourrin. Finalement, la métaphore du voyage se révélera plus adaptée à mon propos. Sans m'en rendre compte, l'article est même déjà écrit en ce sens.

C'est typique dans la plupart de mes billets ou articles : je vous conseille d'ailleurs d'apprendre à lâcher prise, laissez votre propos s'envoler sans le cloisonner à une idée de départ. Déjà vous écrirez beaucoup plus (facilement), et surtout vous aurez de belles surprises !

Je refais un tir de vérifications et de mise en forme, Delphine me suggère d'ajouter quelques images pour soutenir le propos, chose que j'omets assez souvent. Comme le sujet de la qualité Web est un sujet assez récent (comprenez : récent comme le Web), je m'amuse à choisir des images plutôt anciennes, afin de créer une sensation de longévité au sujet. Comme j'adore les cartes anciennes, je me dis que l'occasion est toute trouvée.

Seul regret, je n'ai pas trouvé la dernière image que je souhaitais : je voulais une image de montre avec de nombreuses complications pour donner l'idée du raffinement ultime de la qualité, un côté high-tech ancien. J'ai toujours été fasciné par le musée du Temps à Besançon qui m'a permis de voir une des montres les plus complexes qui soit, la Leroy 01. Malheureusement, il m'a été impossible de trouver une photo ayant une licence permettant sa réutilisation gratuite. À défaut, j'ai repris une image de mécanisme de pointe en horlogerie.

Un autre petit plaisir quand j'écris un article : glisser de petites touches personnelles, dans ce cas les images et photos. Même si personne ne les comprend ou ne sait ce à quoi vous faites référence à titre personnel, c'est amusant. C'est du story-telling… mais discret. Sur OpenWeb, je glisse souvent la réplique – et certains du collectif me chambrent pour cela – « science sans conscience n'est que ruine de l'âme ». C'est ce que je pense être le plus important pour le Web : peu importe la technique tant qu'elle est maniée par un cerveau intelligent et une personne responsable.

Donner de votre personnalité ou de vos valeurs si le billet ou l'article le permet, ainsi vous aurez mis un peu de vous dans cet écrit.

Note de lecture : Projet Responsive Web Design (le 05/06/2013)

J'ai eu le plaisir de lire le livre de Jérémie Patonnier et Rudy Rigot, à savoir « Projet Responsive Web Design ». Le livre est préfacé par Kaelig Deloumeau-Prigent.

Projet Responsive Web Design

Ce livre aborde le délicat sujet de la conception d'un site en Responsive, sujet auquel je me suis déjà frotté à plusieurs reprises, tant à titre professionnel que privé. Il y détaille de manière claire tout ce que cela implique sur toute la chaine de production d'un site, du recueil des besoins à la maintenant post-mise en ligne.

Qu'en retenir ?

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.

Quant au livre, je ne saurais que trop vous conseiller de le lire : bien écrit, clair, précis, agréable à consulter, c'est sans aucun doute un très bon moment de lecture. Le parti pris de couvrir toute la chaine de production permet d'avoir une bonne vision d'ensemble de ce genre de projets. Je suis le premier à regretter que les profils ont trop tendance à se spécialiser sans avoir un minimum de vue d'ensemble, et rien que pour cette précieuse vue d'ensemble, le livre vaut le détour !

J'y retrouve la grande et large culture Web des deux auteurs… sans aucune flagornerie (seul un imbécile ne le reconnaitrait pas), car si vous les avez déjà croisés lors d'événements Web (en orateurs ou en simple discussion en off ), vous aurez sans doute remarqué que les deux personnages sont du genre… très compétents !

Pour le plaisir, une citation tirée du livre :

…si nous souhaitions pousser le bouchon à peine plus loin, il (l'intégrateur) sera sans doute l'ultime super-héros du Web !

Si vous vous demandiez encore pourquoi une telle phrase… lisez ce livre, nom d'une media-query ! :)

Vous pouvez également consulter le site dédié au livre Projet Responsive Web Design.

J'ai décidé d'arrêter de sauver le monde (le 04/06/2013)

Il y a quelques années, j'ai connu la refonte de site la plus intense qu'il m'ait été donné de faire. Elle s'est étalée sur de nombreux mois, il y avait tellement de travail que j'ai cumulé les heures supplémentaires à un point rarement atteint (précisons que la semaine de travail en Suisse est de 42 heures). Vacances reportées, journées à rallonge, etc.

Soyons honnête : j'ai fait ce surplus de travail de bon cœur, car la situation l'imposait et tout le monde était sous le feu des balles. La dernière semaine a été terrible, les demandes affluaient en masse, je n'avais même plus le temps de stresser : il fallait aller au plus vite. J'ai même appris à totalement court-circuiter certains mécanismes de mon propre esprit pour pouvoir foncer encore plus vite, c'est une sensation absolument étrange que je vous souhaite de vivre au moins une fois.

Toutefois, ces efforts ont été récompensés, le client était content et mon boss aussi.

Par contre, j'ai pris une étrange résolution à la fin de l'année en question : j'ai décidé d'arrêter de sauver le monde. N'y voyez aucune fainéantise, manque de prise de responsabilité, interdiction de coup de bourre, etc. Tout cela arrive, et cela se gère. Absorber une charge même très élevée, épauler un collègue surchargé, assumer ses bêtises, etc. tout cela, c'est normal, et à mon humble avis, c'est même juste être responsable dans son travail.

Je me suis juste interdit de trop compenser une organisation défaillante ou un manque de sérieux manifeste. Autrement dit, je suis parti de l'idée de juste poser quelques limites :

  • toute demande livrée n'importe comment sera traitée du mieux que je peux, mais si je suis en simple exécutant et non responsable, je ne fais que poser la question sans amener en même temps la réponse,
  • 5 trucs urgents qui doivent être faits tout de suite feront comme à la boucherie : un ticket et chacun à la suite,
  • les foutages de gueule manifestes des débutants qui ne lisent pas ce que je leur indique de lire seront traités comme tels : de la bêtise de gamin,
  • hors de question de faire le boulot à la place d'un autre (à l'exception d'un collègue la tête sous l'eau bien sûr) : si par exemple, je suis en charge de l'intégration et que la mise des contenus ne m'est pas demandée, je fais de mon mieux pour permettre à l'autre de bien bosser, mais c'est tout.
  • etc.

Tout cela avec une règle obligatoire : jamais de mauvaise volonté. Un collègue qui demande de l'aide est toujours bien reçu par exemple. J'ai donc lancé cette expérience, et le résultat fut assez étonnant.

La première chose, c'est qu'il faut être capable d'expliquer rationnellement une impossibilité : vous me demandez ça de suite, or j'ai ça en cours, impossible de faire deux choses en même temps, etc. pas toujours simple quand on aime rendre service ! Ceci dit, même les clients comprennent.

Deuxième chose qui découle directement de la première : j'ai pu noter énormément de travers de communication très agaçants, surtout chez ceux qui se reposent sur vous. J'en ai déjà parlé dans « je déteste les coups forcés » :

– tu peux faire cela ?
– oui, mais pas de suite, je suis sur quelque chose.
– en fait, il le faut pour tout de suite.

Tout cela parce que la demande n'est pas assumée comme telle. Dans le même genre :

– il faut qu'on fasse ça ! (sous-entendu vous)
– hé bien il va falloir attendre, j'ai déjà une urgence pour tout de suite, dernier délai.
– oui mais il faut qu'on le fasse !
– je t'en prie, fais-le, je ne peux pas.
– je peux pas non plus, et c'est urgent ! (le « fais-le » n'est pas loin)
– il va falloir faire un deuil d'une urgence alors.

Vous noterez l'emploi du « on », pronom impersonnel, afin de ne pas assumer, de ne pas se mouiller dans le propos. Si j'ai bien retenu une leçon, interdisez-vous l'emploi du « on ». Vous allez voir qu'utiliser « tu , « je  ou « nous » simplifie énormément l'engagement des responsabilités. Il est même très drôle d'expliquer une posture rationnelle à quelqu'un qui espère qu'« on » (= vous) va ramasser la m… à sa place. Vous aurez peut-être droit à du chantage affectif de sa part !

Le fait de vouloir arrêter de sauver le monde va vous faire vivre des couacs, pas forcément à titre personnel, mais il arrive que les projets se vautrent lamentablement : maillons foireux, laisser-aller, etc.

Même en arrêtant de sauver le monde, les gros couacs vous imposent de vous remettre en cause : avant d'expliquer objectivement que vous n'avez rien à vous reprocher… hé bien il faut être au top justement, et c'est très difficile, en toute honnêteté intellectuelle bien sûr ! Quand la faute est collective, j'ai cherché systématiquement une solution qui interdisait autant que possible de retomber dans lesdits couacs. Du coup, les checklists avant projet ont été créées et enrichies, les procédures ont été affinées également.

En revanche, sur des projets sur lesquels je ne suis pas du tout intervenu, tout non-respect ou je-m-en-foutisme des règles qui évitent les erreurs a reçu le même accueil : « j'ai écrit telle checklist, j'ai fait telle chose pour éviter ça, si vous refusez de faire comme il faut, assumez-en les conséquences, pas mon problème ! ». C'est un peu dur, mais c'est efficace.

En fait, vous pourriez croire que cette façon de penser va vous faire stagner… et bien non, elle ne vous empêche pas d'améliorer votre manière de travailler, bien au contraire ! Elle va par contre impliquer de gros changements : curieusement pour montrer qu'un système est insuffisant et/ou générateur de frustrations, il va falloir montrer qu'il est absurde et montrer « qu'on ne peut pas fonctionner comme ça ». Une fois que la prise de conscience que le système n'est pas bon est faite, vous pourriez être surpris de la subite énergie que d'autres vont déployer pour le changer. Dingue comme un inconfort que vous masquiez en sauvant le monde se révèle être un sérieux atout du changement ! :)

En tout cas, je continue d'expérimenter cette méthode, c'est très intéressant. Du coup, je choisis de sauver le monde ailleurs. :)

Non, mon but n'est pas de « vous emmerder » (le 03/06/2013)

Cher <ici une personne>, je le dis de suite : non, mon but n'est pas de « vous emmerder ». Je sais que vous me demandez les accès de l'administration de tel site. Et je sais que je peux vous les fournir, l'ayant conçu.

Mettez-vous à ma place : si je vous transmets ces infos, et que pour n'importe quelle raison, je n'étais pas habilité à le faire, l'erreur viendra de moi, et vous pouvez être sûr que je vais me faire démolir auprès de vos instances.

Pire, tant que je n'ai pas de preuve que vous êtes bien la personne que vous prétendez être (un e-mail peut être piraté), et que vous êtes bien habilité à avoir accès à cette interface d'administration (un employé licencié qui souhaite démolir un site, c'est stupide, mais cela existe), j'ai encore moins de raison de vous donner ces accès.

J'ai conscience que votre demande est urgente, et croyez bien que je regrette de ne pas pouvoir en faire plus. Donc, comprenez bien qu'il n'y a rien du tout de personnel et que mon but n'est pas – selon vos propos – de « vous emmerder ».

Et vous, cela vous est déjà arrivé ce genre de situation ? ;-)

Un peu d'élégance, que diable ! (le 31/05/2013)

Amusant, je pensais écrire un billet sur le manque d'élégance, et l'actualité vient de me donner du grain à moudre.

Le site Linuxfr a été mis en demeure par la société Linkeo sur le prétexte qu'un commentaire posté en réponse à une offre d'emploi (postée gratuitement sur le site !) ait été jugé comme étant un dénigrement.

Honnêtement, est-ce que la mise en demeure d'un site sympathique comme Linuxfr pour quelque chose de pas bien méchant était la meilleure chose à faire ? Un simple mot aux modérateurs et l'affaire se traitait en toute discrétion, et personne n'en aurait jamais entendu parler.

Or là, c'est un véritable bad buzz que la compagnie en question vient de récolter, désastreux pour l'image.

Honnêtement, je dis toujours « ça coûte quoi d'être élégant ? ». La réponse est claire : pas grand chose. Et même si l'on est dans son bon droit, mettre un poil la forme ne coûte pas plus cher.

Vous croyez que cela n'arrive qu'aux autres ? Je peux vous assurer que non.

Pas plus tard qu'il y a deux jours, je remarque qu'une agence a réutilisé un travail que j'avais fait à titre professionnel (une intégration avec RÖCSSTI). Le tout ne m'aurait pas gêné, si la licence sous laquelle était distribuée RÖCSSTI n'avait pas été totalement ignorée (elle demande juste d'indiquer la paternité).

Si à la rigueur, la personne en question avait juste pris le temps de me contacter et l'avait fait correctement (« écoutez, on a dû reprendre votre travail pour tel client, vous n'êtes pas mentionné, mais on tenait juste à vous l'indiquer »), je n'aurais rien dit, enfin si j'aurais même dit « merci ».

Si encore, je demandais 1000 euros à chaque utilisation, je comprendrais, mais là, juste dire que ça vient de tel site…

Pourtant, être élégant, ce n'est pas compliqué : RÖCSSTI respecte clairement la licence CC-BY de KNACSS. Et toutes les CSS que j'ai faites avec l'indiquent en commentaire. J'aurais pu faire croire que j'ai tout inventé moi-même et oublier cette mention, mais franchement, ç'aurait été petit et ça ne m'aurait pas grandi (si j'ose dire).

Idem, quand vous faites une remarque sur le travail de quelqu'un d'autre, y mettre un peu de forme ne coûte rien. Cela évitera de desservir votre propos, lire à ce sujet je hais les donjons et le populisme.

L'autre jour, j'écrivais un article pour OpenWeb, et j'ai eu envie de reprendre un lien de qualité comme complément de l'article, un petit message discret à l'auteur pour savoir si cela ne le dérangeait pas que mon article mentionne le sien en complément, je lui indique comment son site va être mentionné, et toc, accord de la personne en question, surpris au passage de « tant d'attention » selon ses paroles. Cela ne coûtait rien et je n'y étais pas forcé, mais cela m'a en prime attiré la sympathie d'une personne.

Etc. les exemples pourraient se trouver à la pelle, autant dans le bon que dans mauvais. Tout ce dont je suis sûr, c'est que vous attirer les foudres du monde sur Internet ne vous rendra pas heureux. Bref, qu'on se le dise, un peu d'élégance, que diable !

Ajout : voici un excellent exemple d'élégance mâtinée d'humour, lisez l'erratum de Rudy Rigot pour une micro-faute sur mon nom de famille. Vous voyez, et comme je suis élégant aussi, j'écrirai bientôt une note de lecture du livre en question, et je serai élogieux car ce livre m'a beaucoup plu.

De l'utilité des commentaires sur les sites (le 28/05/2013)

Je constate que les commentaires sur les articles ou sur les billets se font plus rares. Moi-même, je ne fais pas exception : j'utilise énormément Twitter et je mets souvent un petit message de remerciement ou je re-twitte (selon l'expression) l'article en question.

Tout cela participe grandement à l'enrichissement de mes connaissances, et aussi de celles de ceux qui me suivent par la même occasion, c'est un outil indispensable de ma veille technologique.

Toutefois, je me pose de plus en plus la question de la pérennité de cette façon de faire.

Imaginons qu'on pousse le raisonnement plus loin. Il resterait donc des articles sans commentaires, et on ferait le côté discussion via Twitter.

Depuis plusieurs mois, je me pose les questions suivantes : comment un débutant peut-il arriver à prendre le train en route, sachant que par exemple l'intégration est un métier d'expérience, de veille permanente, et d'apprentissage par l'erreur ?

Et surtout : comment éviter aux débutants de faire les mêmes erreurs qui ont déjà été commises ? (oubli des préfixes, mise en page par tableaux, bêtises en accessibilité, etc.)

Si je prends mon article Intégrateur de l'extrême : les tablettes bas de gamme, Rémi m'a par exemple laissé un commentaire où il me parle d'un raccourci sur Android pour faire une capture d'écran.

En fait, j'ai une certaine inquiétude par rapport à la volatilité des remarques et surtout de l'enrichissement qu'elles apportent aux articles. Je pense que se priver de cela serait bien dommage.

Pour reprendre cet exemple, si Rémi a laissé ce commentaire, n'importe qui qui lit cet article en bénéficiera, même deux ans après. Alors que s'il avait juste envoyé un tweet pour me dire la même chose, au mieux ceux qui me et le suivent sur l'instant en auraient bénéficié.

Le raisonnement est le même pour des articles sur des sites plus connus, comme OpenWeb ou d'autres. Je regrette de voir si peu de commentaires sur certains articles, alors qu'ils génèrent beaucoup de réactions en « off ». Quel dommage de se priver de tant de richesse à long terme !

Du coup, c'est clairement décidé : je compte prendre plus de temps pour commenter des articles. Déjà pour les auteurs qui nous font l'immense cadeau de faire l'effort de les écrire, et aussi pour celui qui le lira 1 ou 2 ans après, sait-on jamais.

Et vous ?

Bug sur Internet Explorer sur les attributs width et height de img (le 24/05/2013)

Pas plus tard que ce matin, un client m'appelle pour me dire que des images ont disparu sur son site sous IE, alors qu'elles sont bien dans le code.

Tout de suite, premier réflexe : vérifier les problèmes générés par le HasLayout. Raté, ce n'est pas ça.

Second réflexe : penser que les images JPEG en question sont en CMYK (les vieux IE ont quelques soucis avec). Raté, pas ça non plus.

Pire, le problème apparait également sur IE10. Je cherche une solution CSS, rien. Au final, cela venait en fait du code HTML. Tout simplement, si vous mettez des attributs width et/ou height vide(s) sur la balise img, IE ne les affichera pas (d'après ce que j'ai pu voir, IE10 réduit la valeur de l'attribut à 1 dans ce cas).

Plutôt qu'un long discours, un court exemple : j'ai listé 7 exemples de ce bug d'attributs vides sur cette page. Regardez la page sous Firefox, et observez-la sous IE : 5 cas ne fonctionnent pas sous IE.

  • S'il n'y a aucun attribut, cela fonctionne.
  • Si ces attributs sont remplis correctement, évidemment, cela fonctionne.
  • Si un ou les attribut(s) est(sont) présent(s) mais vide(s), patatrac, l'affichage plante.

Autant être clair, je n'incrimine pas IE en particulier, c'est bien une erreur de code qui est juste bizarrement interprétée par ce navigateur.

En tout cas, nous sommes bien d'accord : cette situation ne devrait jamais arriver, la bonne pratique étant de spécifier ces attributs tout le temps. Toutefois… qui a dit que cette bizarrerie ne pourrait jamais arriver ? :)

Réinventer le chemin… pas la roue (le 20/05/2013)

En matière d'intégration, j'entends souvent chez les débutants (et même les moins débutants) la réflexion suivante :

Pourquoi réinventer la roue ? Y a qu'à utiliser tel framework/tutoriel/utilitaire/etc.

La réflexion n'est pas idiote, loin de là : déjà dans un contexte de production, il est possible d'être amené à faire des choix qui favorisent la rapidité. Aussi, il peut être utile de disposer d'outils qui font le sale boulot, de s'inspirer d'autres choses, de s'appuyer sur une base, etc.

Moi-même, je ne fais pas exception : mon « nano-framework » CSS RÖCSSTI s'inspire et reprend des éléments d'autres projets (comme KNACSS), c'est même écrit dessus.

Néanmoins, un point me chagrine dans cette approche : éviter de réinventer la roue est une chose intelligente, néanmoins cela va vous dispenser du chemin parcouru (par la roue si j'ose dire). Plus gênant, cela peut vous priver des chemins de traverse pendant que vous parcourez ce chemin.

Quand j'ai commencé à intégrer – mode vieux con –, disons-le net, il fallait tout inventer : la documentation était quasi-inexistante, l'intégration était le parent pauvre du Web, etc. Du coup, je reconnais que j'ai parfois un peu tendance à aller trop loin dans la réinvention de la roue. Mais dans mon esprit, je me dis que l'effort fourni pour connecter mes petits neurones m'aura fait apprendre plus que d'utiliser bêtement quelque chose. Et ça me donne beaucoup d'idées.

Maintenant, je constate chez les p'tits stagiaires que je vois passer une approche presque aussi dangereuse si elle est trop extrême : le « je n'(ré)invente rien ». Savoir utiliser quelque chose est bien, mais c'est quand même selon moi plus intéressant de comprendre comme cela marche. Et pour cela, quoi de mieux que de partir from scratch ? Quand je vois des personnes qui se présentent comme futurs intégrateurs et qui sont terrifiés à l'idée de partir de zéro ou du minimum, j'avoue que ça me laisse pantois.

C'est pour cela que je maintiens : si quelqu'un a envie de réinventer la roue, dans la mesure du possible, laissez-le faire. Il a besoin de parcourir un chemin, et qui sait où ce chemin pourrait l'emmener ?

Mars Render en HD disponible (le 20/05/2013)

J'avais recalculé certaines parties de l'animation « Mars Render » en HD pour l'émission Ushuaïa Nature, et au final, je l'avais recalculée intégralement pour mon plaisir.

Le Mont Olympe dans Mars Render HD

Si vous êtes curieux de ce que calculer une animation en HD implique, alors faites un tour sur l'annonce de « Mars Render » recalculée en HD, j'y dispense des chiffres intéressants.

L'animation est d'ailleurs toujours disponible sur Youtube : Mars Render HD sur Youtube.

Pourquoi vous reparlé-je de cette animation ?

En fait, j'ai toujours été un peu frustré de ne pouvoir faire comme pour toutes les animations de ce site, à savoir la mettre à disposition sur la page de mes animations avec Terragen.

En essayant de réduire un peu le poids, je suis arrivé à un fichier de 750 Mo, du coup… j'ai craqué, et tant pis pour ma bande-passante (que je vais activement surveiller quand même). La vidéo est disponible sur la page de mes animations avec Terragen.

Vous pourrez voir la qualité incroyable des paysages créés par Arnaud et Florent Creux, ainsi que ceux d'Yves Maquinay. Les images ont un piqué extraordinaire, c'est un peu comme si vous redécouvriez votre film préféré en Blue-ray alors que vous aviez l'habitude de le voir sur une VHS.

Et je peux bien l'annoncer, une autre animation qui a toujours été parmi mes préférées est en train de subir le même traitement, à savoir un recalcul complet en HD !

J'aime mon graphiste (le 18/05/2013)

Oui, il est possible de trucider cette légende urbaine comme quoi intégrateurs et graphistes ne sont pas fait pour s'entendre.

Comme le dirait Octave dans le film « 99 Francs » :

Il est à moi, c'est MON graphiste.

Mon graphiste a plein de qualités extraordinaires, déjà, il a le bon sens de discuter avec moi quand il fait ses maquettes, ce qui m'évite des échanges houleux comme par exemple – par exemple hein – je reçois une maquette impossible à faire tourner avec un CMS qui par principe permet d'ajouter des pages. D'ailleurs, il a compris que quand il est perdu pour pondre une maquette pour smartphone, il peut venir me voir pour que je puisse lui donner des pistes d'après mon code.

Ensuite, au lieu de croire comme la plupart des blaireaux sortis des écoles d'arts que la Terre entière va s'agenouiller devant sa créativité (bien sûr, tous sont le nouveau Picasso du Web), il écoute et essaie de comprendre la chaine de production à tous les étages. Il a le grand mérite de s'y intéresser.

Il a compris que si je lui demande des exports en sprites CSS, ce n'est pas juste pour le plaisir de lui casser les pieds, mais que cela sert la qualité du site. Pareil, quand je lui parle de contrastes, il a compris que le site n'est pas là pour favoriser son ego, mais bien pour des utilisateurs.

Il a également pigé que la créativité se loge à des endroits bien surprenants parfois.

D'ailleurs, le fait qu'il m'écoute me donne encore plus envie de respecter son travail, c'est quand même dingue ce qu'une bonne entente produit. En fait, on n'a pas besoin tant que cela de discuter des heures comme je pourrais le faire avec un bobet qui ne comprend rien à rien de mon boulot d'intégrateur. Des fois, je reçois des images en sprites sans même les avoir demandées. D'ailleurs, parfois, je n'imaginais pas utiliser cela dans certains cas, et il me pousse à le faire. D'ailleurs, mon framework CSS est aussi là pour permettre de mieux respecter ses maquettes.

On se consulte bien sûr, personne n'est parfait, ni lui, ni moi. Mais cette entente nous fait en fait discuter que sur des questions intéressantes, pas des engueulades stériles de crétins butés.

Vraiment, j'aime mon graphiste, c'est un vrai Web Designer

Pour gagner du temps à tester les Microdatas (le 16/05/2013)

La petite astuce du jour : si comme moi, vous vous intéressez aux Microdatas, vous connaissez peut-être le Google Structured Data Testing Tool.

Si vous avez la Webdevelopper Toolbar sous Firefox :

  • allez faire un petit tour dans « Outils>Régler outils »,
  • là vous pouvez cliquer sur « Ajouter… »,
  • il vous suffit de préciser le nom de l'outil, pour ma part, je l'ai baptisé « Rich Snippet Tool »,
  • de cocher URL pour « Type d'outils »,
  • et d'indiquer https://structured-data-testing-tool.developers.google.com/sdtt/web?#url= dans le champ URL.

Et hop, voilà un raccourci bien pratique créé vers ce service !

Le même genre d'astuce est possible :

Le plaisir d'être fainéant n'a pas de prix !

Note de lecture : WebGrids, structure et typographie de la page web (le 13/05/2013)

Oui, vous pourrez me dire que je lis bien beaucoup ces temps-ci !

Toutefois, je ne pouvais ignorer les recommandations d'Emmanuel Clément qui m'avait chaudement recommandé ce livre : « WebGrids, Structure et typographie de la page web », écrit par Anne-Sophie Fradier.

WebGrids, Structure et typographie de la page web

Ce livre aborde un sujet sur lequel je suis bien… ignare (pour tout dire), à savoir la typographie.

L'ouvrage commence par une rapide histoire de la typographie, enchaine avec les spécificités du support, parle longuement des grilles et de l'agencement des blocs dans ces dernières, et termine par la composition du texte courant.

Je ne peux que constater que la recommandation d'Emmanuel était bonne : très agréable à lire, accessible sans être bateau, j'ai eu un certain plaisir et même un plaisir certain à le lire. Bon, disons-le net, je l'ai dévoré en moins de deux jours.

L'auteure prend le parti de ne pas assommer d'informations le lecteur et de le laisser découvrir cet univers de manière assez progressive, ce parti pris fonctionne parfaitement : étant assez débutant dans ce domaine, ma curiosité a été bien entretenue tout au long du livre, et je me rends compte à la fin de cet ouvrage que le sujet était en fait très dense. Le livre fait mouche sur beaucoup de points, assurément !

Je ne peux que vous recommander à mon tour de vous y intéresser, c'est un moment de lecture très intéressant et très agréable.

Le maillon le plus souple (le 11/05/2013)

Une pensée du week-end en passant…

De ma petite expérience du monde du travail (10 ans), j'ai pu remarquer que bon nombre de personnes n'ont aucune souplesse dans leur métier, avec peu ou prou le même raisonnement : partant de l'idée que « je suis le maillon fort donc le monde doit s'adapter à moi, la preuve, je suis indispensable », ces personnes ne plient jamais leur manière de travailler et c'est au monde autour de s'y conformer.

Si je n'ai rien contre un peu de rigueur dans son travail et de le défendre, le côté psycho-rigide de cette façon de penser m'exècre au possible, et encore plus dans les métiers du Web.

Il n'y a rien qui ne me rende plus dingue qu'un graphiste pas foutu d'écouter les contraintes de l'intégrateur, qu'un intégrateur infoutu de comprendre les problèmes du développeur back-end, qu'un développeur back-end qui massacre le travail de l'intégrateur avec l'argument vomitif du genre « mais l'inté, il sait pas coder », etc.

À toi, débutant et nouveau maillon dans la chaine de la création du site Web, je te le dis très simplement : comprends cet écosystème et comprends que ce n'est pas au monde de plier, c'est à toi de le faire.
Quand tu auras suffisamment compris cet écosystème, tu le feras infléchir sans même t'en rendre compte, mais cela n'aura plus d'importance.

Pour ma part, étant au front en matière de sites Web, je pense que la souplesse est une qualité pas seulement souhaitable, mais réellement indispensable. Je suis même encore plus exigeant avec les intégrateurs : leur travail étant un point de liaison entre le graphiste et le développeur, il se doit de comprendre leurs besoins et d'offrir toute la souplesse de son savoir pour permettre à toute la machine de bien fonctionner.

Dans le même genre, j'aime beaucoup l'approche que Luc Poupard explique dans un article intitulé « Les petits ruisseaux font les grandes rivières ». Je ne peux que vous encourager à lire cet article : je ne sais pas s'il a Free, mais il a tout compris.

Note de lecture : CSS3, le design web moderne (le 09/05/2013)

Avec énormément de retard, voici enfin une note de lecture sur « CSS3, le design web moderne ». Ce livre a été écrit par Vincent De Oliveira et Cédric Esnault, il est préfacé par David Rousset.

CSS3, le design web moderne

Le livre présente rapidement « l'état de l'art » de CSS, embraye sur les éléments du langage (principes, sélecteurs, unités, etc.), traite de tous les effets graphiques de CSS3 (ombres, dégradés, etc.), enchaine avec une solide partie sur la typographie, passe par le positionnement, le Web mobile, et termine par les transitions, les animations et les transformations. En guise de dessert, une partie finale sur les outils et ressources CSS vient compléter ce repas très complet  !

Très complet, j'y ai retrouvé l'immense savoir de leurs auteurs. J'ai eu le plaisir de rencontrer plusieurs fois Vincent De Oliveira lors d'événements comme la Kiwi Party, et le moins qu'on puisse dire, c'est qu'il connait diablement bien son sujet !

Assurément, c'est un très bon livre si vous tenez à vous mettre à la page en matière de CSS3 ou à perfectionner vos connaissances. Ajoutons à cela que le Web évoluant très vite, on peut vite avoir besoin d'utiliser toutes ces merveilleuses nouveautés. Le lire m'a d'ailleurs donné quelques idées !

De nombreux exemples très sympathiques sont en plus dispensés sur le site du livre « CSS3, le design web moderne », je ne peux que vous encourager à aller le visiter.

Du très bon boulot tout cela !

Tout ça n'a plus d'importance (le 04/05/2013)

Plusieurs remarques trouvent un écho dans ma petite tête où se mélangent plein de choses en cette fin de semaine.

On parle d'accessibilité dont on se fout, de justifier l'accessibilité, Sophie lâche un pragmatique « Et si on essayait d'être efficaces ». Tristan parle du bonheur, facteur de réussite.

Tout cela m'amène à citer un article de Rémi : Et si on créait de meilleurs sites pour rien.

En fait, c'est ça la clé. Tout ça n'a plus d'importance.

Si vous cherchez avant tout quelque chose en retour, vous courrez après un fantôme. Les apparences, les petits jeux ? Vous avez du temps pour ça ? Des excuses, ou vous attendez quelque chose ? Assumez, et n'attendez pas.

J'y vois même un écho particulier quand j'entends « je ne suis pas le mieux placé pour ». Ah ! Si Adam avait eu le même raisonnement, il aurait répondu à Ève « je ne suis pas le mieux placé pour te faire le voyou » (ou manger le fruit défendu, quelque chose comme ça), et on aurait été bien emmerdés…

Je redeviens sérieux.

Je ne me pose même plus ces questions. Je passe beaucoup de temps pour OpenWeb ? M'en fous, ça me fait plaisir. Pourtant, je peux vous citer 100 arguments tout à fait valables qui pourraient être utilisables pour dire que contribuer à OpenWeb est quelque chose de bien. Mais en fait, je sais que c'est bien et j'en ai l'intime conviction, et ça me suffit. Quelle motivation je trouve à donner du temps pour aider d'autres projets ? Je sais que c'est bien, et j'ai pas besoin d'autre justification.

J'ai pris beaucoup de temps pour écrire un article ? M'en fous, ce temps est mieux utilisé qu'à regarder une stupidité à la télévision. Le Web bien fait, comme l'expression l'indique, ça ne se lit pas, ça se fait.

Tout ça n'a plus d'importance.

Par contre, cela ne dispense pas que toutes ces (bonnes) choses prennent du temps, que je puisse avoir besoin de déconnecter pour faire autre chose, que je ne peux pas faire parfait de suite, que je ne peux m'abstraire d'être en bonne santé, de manger, que ça n'est pas toujours facile, etc.

Mais le reste, les justifications à deux balles… tout ça n'a plus d'importance.

L'interface d'admin pourrie et l'essentiel (le 29/04/2013)

Quand j'ai refondu ce site il y a maintenant 9 ans (et quelques jours), en bon fainéant que je suis, je me suis programmé une interface d'administration. Certes elle est très spartiate, mais elle me permet d'éviter d'aller systématiquement dans le code dès que je veux ajouter un lien, écrire un billet ou encore mettre à jour mon CV.

En voici une capture :

Interface d'admin spartiate

Vous voyez que je n'ai vraiment pas exagéré quand j'ai dit qu'elle était spartiate. Je n'ai d'ailleurs jamais pris le temps de l'embellir.

Quand je me suis amusé à la refaire avec jQuery Mobile afin de la rendre un peu plus jolie, je me suis dit que l'ancienne allait être plus ou moins mise au placard : pas prévue pour autre chose que les navigateurs desktop, franchement pas terrible point de vue design, un peu limite question ergonomie, etc.

Curieusement, je me suis bien trompé.

En fait, cette vieille interface d'admin, même si elle est loin d'être exempte de défauts, a pour elle d'être hyper efficace pour mon besoin. En fait, il y a tellement peu de fioritures que l'essentiel est là : super légère et donc rapide à charger, elle ne buggue jamais (là où la nouvelle me fait quelques bizarreries avec le cache manifest sur mobile), les jolies transitions de jQuery Mobile sont certes sympas, mais dispensables, etc.

D'ailleurs, ce n'est pas la première fois qu'on me fait la remarque : mes premières interfaces d'administration étaient elles aussi plutôt spartiates, toutefois, parfois mes clients ont dû :

  • mettre à jour en urgence leur site,
  • se retrouver en situation de handicap forcé (les piles de la souris qui lâchent par exemple),
  • l'utiliser avec une connectivité réseau très mauvaise.

En fait, ceux qui ont eu ce(s) problème(s), parfois plusieurs en même temps, m'ont fait part de leur satisfaction : le système étant basique mais extrêmement simple, il fonctionne bien dans ces cas de figure. D'ailleurs, même si ces systèmes ont été conçus à une époque où le Web Mobile était embryonnaire et les tablettes n'existaient tout bonnement pas, ils encaissent plutôt bien ces périphériques, grâce à leur extrême simplicité (HTML, CSS, et du JavaScript non obstructif du plus basique qui soit).

Qu'en retenir ?

Loin de moi l'idée de tenir un discours du genre « c'était mieux aaaavaaaant », toutefois, ces expériences m'ont fait cogiter. Je retrouve l'idée que j'avais abordée quand je parlais du syndrome du site OGM. Vous pouvez mettre tous les embellissements, tous les raffinements, tous les petits gadgets possibles et imaginables, si votre système ne répond pas au cœur de la demande correctement et efficacement ou si le cœur en lui-même n'est pas stable, ça ne fonctionnera pas.

Note de lecture : Accessibilité Web, d'Armony Altinier (le 27/04/2013)

J'ai fait l'acquisition d'« Accessibilité web, normes et bonnes pratiques pour des sites plus accessibles » lors du dernier Paris-Web, où le précieux sésame était en vente en avance (sur la sortie). Curiosité de l'agenda, j'ai rencontré Armony Altinier il y a quelques jours à la Conférence Romande sur l'Accessibilité du Web à Lausanne, et je finis son livre quasiment au même moment ! (tu vois Armony, je n'avais pas menti quand je te disais que je l'avais presque fini)

Accessibilité Web, d'Armony Altinier

En guise de mise en bouche, le livre explique très simplement ce qu'est l'accessibilité du Web, le cadre juridique, pour qui c'est destiné, les technologies d'assistance, etc.

Ensuite, le livre parcourt le référentiel Accessiweb où sont disposés de nombreux exemples de ce qu'il faut et ne faut pas faire, toutes les thématiques sont abordées (formulaires, liens, images, multimédia, etc.). Une partie en fin de livre est consacrée à ARIA et HTML5.

Une dernière partie parle de l'accessibilité au-delà des normes, notamment des méthodes pour commencer une démarche vers l'accessibilité, la conduite du changement, etc.

Que dire de ce livre en un mot ? Enfin.

Déjà, enfin (enfin !) un livre sur l'accessibilité. Enfin quelqu'un a eu le courage de se lancer dans un livre et d'aller au bout. C'est complet et cela permet d'avoir des bases solides et claires sur le sujet de l'accessibilité des sites Web. La grande force de ce livre outre sa richesse, est d'expliquer les choses avec bon nombres d'exemples, et c'est très agréable, ça sonne concret. Assurément, c'est une réussite qui doit faire partie de votre bibliothèque de toute urgence.

Pour conclure, deux choses : déjà bravo Armony. Faire un recueil aussi complet et accessible (!) sur le sujet n'a pas dû être une mince affaire. En tout cas, j'ai pris un certain temps pour le lire, car je ne voulais survoler aucune partie, ce qui n'aurait pas rendu justice au travail de l'auteure.

Et en second, je me permets de reprendre les dernières phrases de ce livre, que je trouve absolument superbes.

Si vous considériez votre travail comme un simple empilement de lignes de codes, vous ne liriez sans doute pas ce livre. En tant que développeur, concepteur de site, graphiste Web, rédacteur, commercial, décideur : vous avez le pouvoir de donner plus de liberté à des millions d'internautes.

La seule question à vous poser est la suivante : Êtes-vous prêt(e) à changer le Web ?

Un grand pouvoir implique de grandes responsabilités.

L'accessibilité, on s'en fout de plus en plus ? Moi, non. (le 26/04/2013)

Alors, suite à une remarque lancée par QuentinC sur Alsacréations : L'accessibilité, on s'en fout ?, plusieurs réactions.

Déjà posons le contexte de mes réactions, je n'avais pas compris sur Twitter que l'intéressé était directement concerné par le sujet, étant selon ses paroles quasiment non-voyant. Donc, effectivement, ma parole était maladroite et a pu être mal comprise, et ça je m'en excuse. Sans aucune condescendance car je la maintiens, toutefois je vais l'expliquer ici bas.

Sophie Drouvoy a commenté cette remarque sur son blog, à lire de suite.

Stéphane Deschamps y est allé de son commentaire, fort intéressant également : Défaitisme et accessibilité.

Voici pêle-mêle les réflexions que cela me pose.

On s'en fout de l'accessibilité

« On » ? C'est qui « on » ? Moi, non.

Non, en dehors de tout affect, je pense qu'il ne faut pas s'en foutre. Objectivement. Ne serait-ce que pour des raisons de bon sens, se couper sciemment d'un public est un non-sens en matière de Web, qui est et doit être avant tout une solution universelle, même et surtout si elle est imparfaite. Comme je l'écrivais dans mon article sur les contrastes de texte sur OpenWeb :

Les problèmes de vue s’accentuant avec l’âge et le secret de l’éternelle jeunesse n’ayant pas encore été découvert, il est aisé de comprendre qu’un jour ou l’autre, inévitablement, la question de la lisibilité des textes va se poser à une grande majorité de personnes.

Évidemment, la phrase ne concerne que les contrastes, mais elle peut bien se généraliser à l'accessibilité. Sans être sourd, en roulant, je remarque que j'écoute la radio plus fort qu'il y a 10 ans, et je n'ai pas une voiture plus bruyante pour le justifier. D'ailleurs, j'ai des lunettes depuis quelque temps.

Mythes autour de l'accessibilité

Comme le dit très justement Stéphane, il y a un mythe autour de l'accessibilité : certes cela coûte moins cher de l'inclure dès le début, mais cela n'est pas gratuit pour autant.

Cela prend du temps en formation, en code, etc. rien n'est gratuit en ce bas monde.

Ajoutons à cela que le Web évolue très vite, et l'accessibilité suit ce rythme effréné, ce qui m'a été confirmé à la Conférence Romande sur l'Accessibilité du Web. Les nouveautés de HTML5, ARIA, le support de tout cela dans les aides techiques comme Jaws, etc. tout cela évolue à une vitesse très impressionnante. De l'aveu même d'un des plus grands experts accessibilité (Jean-Pierre Villain pour ne pas le nommer), on est sur une situation pas stable.

À mon sens, l'accessibilité ne gagnera qu'en rentrant petit à petit dans les mœurs, de la base vers les sommets. C'est mon approche en tout cas. Je constate qu'objectivement, ça rentre petit à petit, même si effectivement c'est loin d'être la panacée.

Une perte d'énergie

J'ai dit que le défaitisme est une perte d'énergie, énergie qui pourrait être mieux utilisée. Et je maintiens. Car selon moi, le temps qu'on passe à expliquer pourquoi on ne peut pas quelque chose peut être consacré à chercher comment le faire, ou même à le faire.

Comprenez ma façon de penser dans sa globalité : elle peut être extrêmement brutale, car cela implique que potentiellement rien n'est impossible, donc que cela ME force à me bouger le train. Et je peux vous assurer que c'est pas génial pour ma zone de confort ni pour ma fatigue, et parfois pour la zone de confort des gens autour de moi (collègues entre autres). Typiquement, quand je vois qu'un collègue ne veut pas faire un effort minime pour l'accessibilité, alors que je lui ai expliqué comment faire, ça me fout en rage.

Ajoutez à cette façon de penser que je préfère voir le verre à moitié plein.

Par contre, qu'on ait un passage à vide, un ras-le-bol, ça je peux le comprendre, qu'on ait un handicap ou non d'ailleurs, c'est humain, et je ne fais pas du tout exception. En soi, j'attaque le défaitisme, pas les personnes (je ne suis pas un monstre non plus :) ).

Une formidable leçon d'espoir

Comme le dit encore très justement Stéphane, « vous allez me dire que je fais dans l'affect ». En ce qui me concerne, je ne vais pas le nier, il y a une part d'affect dans la volonté d'améliorer l'accessibilité de mes sites. Effectivement, j'ai un problème quand je me dis qu'une personne que je connais, que j'ai rencontrée, que j'apprécie est bloquée par ma faute sur un site alors que j'ai une solution.

Tout comme Stéphane, quand je fais de l'accessibilité, je pense surtout à quelqu'un, je l'avais déjà écrit il y a presque un an dans un commentaire sur l'Accessiblog.

C'est pour cela que j'invite les gens ayant des handicaps à en parler, à nous montrer, à faire du mobbying, à nous expliquer, beaucoup plus (et sur ce sujet, ça m'a donné des idées). Les événements comme la Conférence Romande sur l'Accessibilité du Web sont formateurs, car enfin je peux comprendre et m'améliorer. Et surtout je peux voir. On peut bien me dire 100 fois qu'il faut mettre un label pour lier un énoncé à un champ de formulaire, mais quand on me montre le réel bénéfice, je comprends.

Sans aucun angélisme (vraiment aucun), je trouve par exemple cela extraordinaire qu'un aveugle puisse surfer sur un site internet. C'est fantastique. C'est même pour moi une leçon d'espoir de voir cela rendu possible. Quand je m'aperçois qu'un commentaire sur mon site a été posté par une personne aveugle, je me dis que c'est génial, grâce à cela, je vais pouvoir discuter avec vraiment n'importe qui.

En soi, ça c'est pour l'affect. Pour mon côté pragmatique et pas du tout affect, je trouve cela sain dans le sens où cela supprime la discrimination, tant positive que négative. À mon avis, quand on se débarrasse de la discrimination, on vire aussi quelques cancrelats comme le misérabilisme, le politiquement correct, et ce n'est pas un mal de toucher ainsi du doigt le mot égalité.

C'est aussi pour cela que j'adore blaguer avec une certaine Sophie en lui demandant si elle fait la sourde oreille. Respectueusement, je chambre n'importe qui, et je vois pas pour une personne avec un handicap devrait y échapper. C'est une personne avant tout, et pas de discrimination, hop, blague pourrie pour tout le monde !

Le mariage pour tous (le 21/04/2013)

Félicitations aux anti-mariage pour tous, ils ont réussi à me faire écrire un billet sur le sujet.

Pour être très honnête, au début, ce sujet m'en touchait une sans bouger l'autre, je n'en avais rien à cirer. Non pas que je sois opposé à cette loi, mais j'estime que les affaires de sexualité, qu'on soit hétéro, homo, bi, solo, etc. en fait je m'en fous : ça ne regarde que ceux qui vivent leur sexualité. Perso, je m'occupe de la mienne, et je laisse aux autres le plaisir de s'occuper de la leur.

Je voyais cette loi passer après un ou deux débats enflammés, en soi, un peu de bruit pour la forme de quelques « réac's », et merci au revoir.

Mais comme dit la publicité, ça, c'était avant.

La pauvreté des arguments contre le mariage pour tous me dépasse, à croire qu'il faut avoir uniquement deux parents de sexe différent pour pouvoir être aimé, bien élevé, etc.
Je crois que si l'amour qu'on peut porter à un enfant devait se limiter de quelque manière que ce soit, il est grand temps de se poser des questions. Je n'imagine même pas une seconde que ma sexualité puisse limiter l'amour que je peux porter à un gosse.

J'ai lu de nombreux témoignages, en simple curieux. Je reconnais que certaines histoires dépassent mon entendement.

Et j'ai été frappé de voir comme ce débat a dérivé, et surtout l'animosité des antis. Encore, si la loi disait que les couples homos ont subitement plus de droits que les couples hétéros, je pourrais comprendre, mais franchement, je me pose la question : est-ce qu'une simple loi qui autorise le mariage pour tous méritait un tel bordel ?

Je regarde les photos des manifestations d'aujourd'hui, et je suis choqué que des symboles comme le drapeau français soient affichés à côté de slogans violents à l'encontre de citoyens français. Merde, un pays, ça doit être au-dessus de telles considérations, uni dans la diversité serais-je tenté d'ajouter.

Chapeau bas, les slogans anti-mariage pour tous me sont tellement détestables qu'ils me font avoir une encore plus grande sympathie pour la cause des pros. Qu'on se mêle à ce point de quelque chose qui ne regarde que les intéressés me débecte.

Je ne vois même pas en quoi cela pose problème. Qu'est-ce qu'on se fout de savoir qu'une femme aime une autre femme ou qu'un homme aime un autre homme, et que ces derniers soient reconnus comme unis ? À choisir, autant aimer !

Je ne pense pas que le monde puisse souffrir d'un peu plus d'amour, par contre, d'autant de haine… non, cela n'est vraiment pas nécessaire.

Intégrateur de l'extrême : les tablettes bas de gamme (le 12/04/2013)

Curiosité des vacances, j'ai eu l'occasion de tester plusieurs sites (dont certains des miens) sur une tablette plutôt bas de gamme. Évidemment, je ne résiste pas à l'envie de partager cette expérience.

Une mise au point : ce billet n'est pas une charge contre ce genre d'équipement, je m'intéresse plutôt au rendu de sites dessus. Vous excuserez d'avance la piètre qualité des photos, j'ai fait du mieux que j'ai pu.

Préambule

Quand on pense au test sur la vieille croûte, on pense généralement à un vieil ordinateur dépassé ou alors un vieux portable pas mis à jour. Quand on pense tablettes, on pense généralement à l'iPad ou à une autre tablette de bonne facture. Toutefois, le test sur cette tablette relativement récente montre que cette vision du test dans de mauvaises conditions… ne se limite absolument pas aux vieux tromblons de l'informatique.

Présentation très rapide de la bête

Voici la bête, c'est une tablette Go-Nomad :

Écran d'accueil de la tablette Go-NomadLa tablette Go-Nomad et son clavier

La résolution est de 800 par 480 pixels en paysage, le tout est propulsé par un système Android 4.0. L'écran de 7 pouces est de très mauvaise facture, les habitués de l'iPad et de sa réactivité en seront pour leur grade, c'est une vraie horreur, il faut appuyer lourdement pour activer un lien. Le rendu des couleurs est catastrophique, je reviendrai sur ce point quand on consulte des sites.

L'impression générale est : cheap. Tout est tiré vers le bas pour un prix très agressif.

Le rendu de certains sites

C'est là que cela devient rigolo : j'ai pu voir des curiosités de rendu non-sensiques. Mon propre site personnel construit en mobile-first s'affiche globalement bien là où des sites plus simples ont des problèmes de rendu que j'ai pu déjà pu voir sur de vieux navigateurs (genre sur un vieux Safari pour n'en citer qu'un). Ceci dit, je n'ai pas utilisé de propriété extraordinairement moderne, si j'oublie les media-queries bien sûr.

Mon site personnel sur la tablette Go-NomadCSM sur la tablette Go-Nomad

Mettons au point un détail de vocabulaire : quand je parle de bien s'afficher, c'est que le site est consultable sans souci, on arrive à accéder au contenu. L'affichage n'en est pas optimal ou même beau pour autant, loin de là ! Les dégradés CSS3 sont rendus, mais la faible palette crée des dégradés pas très doux à l'oeil, c'est le moins qu'on puisse dire. Et encore, les photos limitent la mocheté du rendu (!).

Un rendu de dégradé CSS3, catastrophique sur la tablette Go-Nomad

Le rendu des webfonts est très très lent. Souvent, la page est chargée mais le texte n'apparait pas avant de looooongues secondes. J'ajouterai bien que le bonheur des webfonts qui embellissent beaucoup les sites est mis à mal, le rendu de certaines étant parfois très laid, sans que je puisse y trouver une logique. De bons contrastes et des tailles de polices pas trop petites limitent la casse cependant.

Toujours au rayon lenteur, si vous faites pivoter la tablette, attendez au moins une bonne dizaine de secondes pour faire la magie responsive s'opérer. Et encore, j'ai essayé sur des sites plutôt légers.

Le défilement est insupportablement – abomifreusement – pénible à effectuer sur ce type d'écran, j'ai réellement adoré les sites avec des liens d'évitement les plus simples possibles. Ne parlons pas de l'exécution de JavaScript, très lente aussi sur les sites « chargés ».

Les liens d'évitement, le bonheur avec la tablette Go-Nomad

Quelques sites un peu avancés en matière de positionnement CSS sont cassés, mais rien de très surprenant. Quelques curiosités comiques viennent égayer le tout : bordures non rendues (‽), arrondis bouffés arbitrairement (‽‽), détails rendus invisibles.

Conclusion

Si votre objectif est d'être affiché parfaitement partout, vous allez vite déchanter, les détails des designs ne seront pas bien rendus, et ce genre de périphérique ne s'y prête globalement pas. Par contre, l'objectif d'être consultable à peu près partout reste tout à fait atteignable. On parlera de dégradation gracieuse. :)

Le travail sur les performances Web va montrer ici tout son intérêt, le rendu étant lent, il faut vraiment diminuer le poids des pages et limiter le nombre de requêtes. Une bonne mise en cache fait beaucoup de bien. L'idée n'est pas d'offrir un site parfait (ce qui est impossible dans ce cas de figure), mais bien de limiter la casse. Curieusement, les images en Data-URI remplacent avantageusement les dégradés CSS3.

Idem pour l'accessibilité, les efforts dans ce domaine vont montrer leurs fruits dans ce genre de situation. Un site pleinement responsive devrait s'en tirer correctement, s'il n'est pas trop compliqué.

Attention à ne pas aller trop loin dans l'utilisation d'effets : par exemple, les dégradés étant très mal rendus, la lisibilité peut grandement en pâtir. Pareil pour les liens rikikis, si cela peut poser des problèmes sur iPad si on a de gros doigts, imaginez sur ce genre de périphérique ! Le seul moyen que j'ai trouvé pour ne pas devenir fou était une sorte de stylet qui permettait de naviguer un peu mieux.

Le concept de jeu d'équilibriste que connait tout bon intégrateur trouve ici tout son sens. La bonne leçon à retenir : n'oubliez jamais que vos beaux designs peuvent être consultés dans des conditions bien inconfortables.

En tout cas, comme je l'indiquais dans un tweet, tester un site sur ce genre de périphérique, c'est une grande leçon d'humilité pour les intégrateurs et autres web designers.

Bonus

Voici quelques sites connus consultés avec cette tablette. Ils s'en sortent très bien. Curieusement, les photos échouent à rendre le pouvoir enlaidissant de l'affichage de cette tablette, il faut le voir pour le croire !

Alsacréations sur une tablette Go-NomadLe Train de 13H37 sur une tablette Go-NomadOpenWeb sur une tablette Go-Nomad

C'est offert par la maison. ;)

OpenWeb a 10 ans (le 12/04/2013)

J'aurai mis le temps à écrire sur le sujet, je suis un peu en retard car OpenWeb a dix ans depuis le 21 Mars 2013. Au moins, Laurent Jouanneau est plus ponctuel que moi, il a fêté les 10 ans d'OpenWeb sur son blog pile le bon jour.

Qu'il me soit déjà permis de féliciter l'équipe de départ qui a lancé ce projet, je peux bien le dire : OpenWeb a énormément influencé ma manière de voir le Web. D'ailleurs, ce projet continue de m'influencer, vous pouvez en lire quelques aspects ici : 10 ans d'OpenWeb avec Nicolas Hoffmann.

Laissez-moi vous raconter mon histoire avec OpenWeb. Comme toute histoire, elle commence par « il était une fois », et elle se termine en histoire d'amour.

Il était une fois

… bon passons les détails. J'ai rejoint le collectif en simple contributeur vers la fin 2004. L'article a été publié le 11 Mars 2005, « Avoir plusieurs présentations alternatives pour votre site ». Avec le recul, vous y verrez sûrement un article un poil dépassé, on ne fait plus de CSS alternative, ma bonne dame !

Avec le recul, j'y vois personnellement plutôt ce fait : j'avais à peine effleuré la puissance de CSS. Puissance qui ne cesse de m'impressionner et de m'étonner, même si bien sûr la manière de l'utiliser a beaucoup évolué.

Les articles suivants que j'ai écrits sont tous bâtis plus ou moins sur le même moule :

  • un sujet m'intéresse,
  • je décide de l'approfondir,
  • j'essaie d'en faire un bel article en retranscrivant ce que j'ai appris,
  • le collectif m'aide à mettre tout cela en place, à l'enrichir et à affiner le tout,
  • on publie et j'ai l'impression de ne pas être allé suffisamment à fond dans le sujet,
  • des mois après, je comprends parfois les tenants et les aboutissants des discussions, et je me rends compte que l'article qui a été publié a été plus loin que ma propre compréhension (un comble quand il s'agit de votre propre article, une sorte de syndrome de l'imposteur a posteriori).

En fait, s'approprier un sujet ne fera jamais de vous un expert, par contre, il vous fera parcourir un chemin. Et parfois, l'arrivée n'est pas là où vous pensez, mais peu importe, un chemin est parcouru.

Jusqu'à début 2012, je participais épisodiquement. L'article sur les contrastes de texte des sites a une histoire différente et marque un changement. Alors que je vivais l'ombre d'une année de l'ombre à la lumière, je me souviens avoir écrit cet article en convalescence sur ma tablette, ainsi qu'une participation à un appel à l'action pour le Web ouvert.

J'avais l'impression qu'OpenWeb avait besoin d'un nouveau souffle, avec pleins de choses dormantes. OpenWeb était pour moi un «  athlète de très haut niveau qui doute » : parfaitement capable de grandes choses, mais dont les performances et le potentiel sont gâchés par un flagrant manque de confiance en soi.

Sud Web 2012 lui redonnera une partie de ce souffle. Un redémarrage en trombe, on the rocks, gonflé mais diablement salvateur. La suite me ravit, de nombreux articles, et jusqu'à tout récemment où un redesign a été lancé.

Une certitude en tout cas, je veux y consacrer mon énergie.

Quelques pensées en vrac

En fait, j'ai toujours été fasciné par ce projet, dans le sens où il m'a toujours montré qu'on pouvait faire bien faire le Web en dépit de tout. Si 11 personnes, aussi talentueuses soient-elles (et elles le sont beaucoup !), ont été capables de démarrer ce site et de faire aussi bien, alors, je me dis que rien n'est impossible.

La grosse erreur que commettent beaucoup de gens (et je l'ai commise aussi) est de croire que ce « faire aussi bien » est castrateur (« ils ont fait si fort, j'y arriverai jamais »). Au contraire, c'est une formidable leçon d'espoir : ils montrent qu'il est possible d'arpenter un chemin. Et à plusieurs, c'est mieux, on partage ce chemin.

Cela ne nous renseigne pas sur ce chemin, ni sur le temps qu'il prendra, ni sur sa difficulté, mais la preuve de sa possibilité est là, rien que l'existence de cette preuve est une belle chose en soi.

Quoi qu'il en soit, cette pensée m'inspire une remarque : si vous hésitez à écrire ou faire quelque chose, que ce soit pour OpenWeb ou ailleurs, n'hésitez plus : faites-le. Si vous ne le faites pas pour vous, faites-le pour sauver le monde. Si vous ne voulez pas sauver le monde, sauvez quelques personnes. Si vous ne voulez pas sauver quelques personnes, faites-le pour vous. Ouvrez une porte, balisez un bout de chemin. Le chemin ne va pas vous manger.

Le retour est au centuple si vous en avez besoin.

Pour reparler d'OpenWeb, je veux qu'enfin les gens arrêtent de sanctuariser ce projet. Si d'ici quelque temps, les gens comprennent que comme son nom l'indique, c'est ouvert, alors là on aura fait un énorme progrès.

Une histoire d'amour

J'étais venu pour apprendre des choses sur le Web, et j'en ai appris. Beaucoup.

Au début, cette fascination que ce site opérait sur moi s'est transformée petit à petit en histoire d'amour. Non pas que je puisse tomber amoureux d'un site, mais les gens qui le font avec les valeurs qu'ils véhiculent me font aimer ce collectif. Comme dirait ma douce,
« en amour on n'a pas obligation de résultats mais obligation de moyens », alors, j'y mets mes moyens. Rien d'extraordinaire, rassurez-vous.

Avoir rencontré bon nombre de ces personnes n'a fait que blinder ce sentiment. Au début, je ne comprenais pas un des membres quand il parlait d'une longue histoire d'amour, maintenant je comprends toute la portée de ses propos.

J'étais venu pour apprendre, donc pour moi. Effectivement, c'était bien pour moi : j'ai trouvé un moi qui me plait là-dedans.

OpenWeb un jour, OpenWeb toujours.

Nouvelle checklist qualité (le 01/04/2013)

Je propose une nouvelle checklist qualité :

  • Le site doit comporter un konami code.
  • Si le site n'a pas de konami code, un autre easter egg doit être présent.
  • Il est indispensable d'avoir un fichier humans.txt au même titre que le fichier robots.txt.
  • Il est conseillé de mettre des jeux de mots débiles dans ce fichier humans.txt.
  • L'intégration CSS doit comporter au moins un jeu de mot débile ou complètement nul (les références culturelles cinématographiques comme width: 300px; /* this is sparta */ valident le critère), que ce soit sur le nom d'une classe ou en commentaire.
  • Dans le cas où la CSS est minifiée, il sera de bon ton de proposer la lecture de la CSS non minifiée à d'autres, sous le prétexte d'un code review.
  • Quant aux langages côté serveur, il sera de bon ton en commentaire de :
    1. maudire la planète,
    2. se plaindre du briefing complètement abscons des commerciaux,
    3. mettre des jeux de mots vaseux, blagues carambar acceptées.
  • Si le code serveur est minifié… non, oubliez, là c'est déjà très fort, point validé.
  • Si vous avez un fichier htaccess, comme jamais personne ne le lit, il est indispensable de mettre des âneries dedans, ASCII-art conseillé.
  • Merci de replacer ce point aléatoirement dans la liste, c'est le point bonus.
  • Il est indispensable de prévoir une entrée cachée dans la base de données, qu'on ressortira éventuellement aujourd'hui, afin de surprendre même le client.
  • Dans le cas d'un signalement de bug d'un client ou d'un contact, incriminez toujours le cache. C'est toujours la faute du cache.
  • Même si ce n'est pas la faute du cache, incriminez quand même le cache. C'est une excuse passe-partout.

Partant du constat que notre métier est trop sérieux, je vous invite à compter vos points sur cette liste, si vous avez :

  • de 0 à 3 points : votre cure de Prozac se passe bien ?
  • de 4 à 7 points : allez, encore un petit effort.
  • de 8 à 11 points : vous commencez à maitriser cette checklist qualité.
  • de 12 à 15 points : L'excellence, il n'y a que ça de vrai.
  • 16 points et plus : vous ne savez pas compter, il y a 15 points.

J'attends la validation d'Opquast pour obtenir le label « checklist poisson »…

Les petits bonheurs de la mise en production (le 28/03/2013)

Il est rare que je publie un e-mail, mais là, ça vaut son pesant de pépites. Une suggestion envoyée à propos du site « Est-ce qu'on met en prod aujourd'hui ? ».

Bonjour,

Notre process de déploiement étant entièrement basé sur ton site web, peux tu envisager quelques améliorations :

* Prendre en compte les jours fériés, ainsi que le nouvelle an chinois dans le cas où se sont eux qui font nos mises en prod (prévoit les jours fériés Indiens, un jour tous les informaticiens seront forcément indiens)

* Mettre des messages différents en fonction des semaines (envisage des contributions des visiteurs)

* Prendre en compte les pauses café (on va pas déployer pendant la pause café !)

Voila, j'espère que tu vas utiliser mes super idées pour améliorer ton site !

A+

(éclate de rire, et vais y réfléchir)

L'intégration est une arène (le 21/03/2013)

Un billet de Marie Guillaumet a eu un certain écho dans le petit monde de l'intégration : L'intégration web, cette leçon d'humilité.

Avant toute chose, je vous invite à le lire de toute urgence, pour ma part, j'y retrouve toute l'essence de mon métier, et la vision que Marie en a et les réflexions qu'elle aborde sont très justes.

J'y retrouve avec plaisir des questions qu'on s'est posées à plusieurs sur OpenWeb sur de l'intégrateur au développeur front-end : un maillon essentiel de la qualité Web, enrichies d'autres questions et de son expérience.

Ensuite, certains passages m'inspirent quelques remarques et autres pensées.

Prendre une décision dans cette immense champ des possibles ne dépend ni de vous, ni de moi. Aucune décision technique pour le web ne peut être la décision d’un seul individu. Pour pouvoir trancher, il faut s’en remettre aux objectifs du projet et à sa cible. Tout est question de contexte.

C'est ce qui fait le cœur de ce métier : selon moi, ce qui m'effraie et me fascine tant dans ce métier d'intégrateur, c'est qu'il doit constamment trancher avec énormément de variables (navigateurs cibles, performances, etc.). Particulièrement dans les petites structures, ou à peu près la moitié voir les 3/4 des contraintes passent par vous… quand elles ne reposent pas sur vous.

Un jeu de mot revient souvent dans le métier, l'intégrateur doit monter au front (en anglais, front signifie le devant, on appelle parfois l'intégrateur le développeur front-end ). En fait, ce jeu de mot est on-ne-peut-plus vrai, l'intégrateur est réellement en première ligne, c'est lui qui va aux charbons prendre les coups. Si vous n'aimez pas vous impliquer et/ou que l'idée de faire/défendre des choix vous fait peur, ce métier n'est pas fait pour vous. Je dis souvent quand je me lance dans une intégration que je rentre dans l'arène, l'image vaut son pesant de cacahuètes.

Bien sûr, il n'y a pas que des inconvénients, avoir des responsabilités et arbitrer, c'est valorisant.

La vérité est là, tapie dans l’ombre, et elle nous observe de toute sa majesté, un sourire aux lèvres : nous ne le pouvons pas. Nous allons nous tromper, et nous devons nous tromper, afin de nous améliorer nous-mêmes, de partager nos retours d’expérience et d’éviter à nos condisciples de commettre les mêmes erreurs que nous.

L'intégration CSS est vraiment un apprentissage par l'erreur, ça il n'y a aucun doute. Ceux qui sont qualifiés d'experts sont ceux qui en ont fait le plus ! :)

C’est un métier dans lequel le concept d’obsolescence programmée fait sens : chaque jour, nous produisons des fichiers qui seront obsolètes quelques semaines plus tard.

Là par contre, je nuancerai. Ne confondons pas la durée de vie d'un site et les techniques utilisées. Effectivement, il n'y a pas un site que j'ai fait sur lequel je n'aurais pas quelque chose à améliorer, même si c'est quasiment invisible. Nos connaissances se périment vite, ça c'est un fait indéniable. Il m'arrive même que mes propres CSS me piquent les yeux quand je les reprends : typiquement, maintenant que j'ai pris l'habitude de l'organisation carrée et ordrée de RÖCSSTI, mes anciennes CSS construites sans me paraissent très peu organisées et presque handicapées quand je cherche à les mettre à jour. En même temps, c'est plutôt un bon signe.

Ceci dit, le concept d'obsolescence programmée me gêne, cela implique que le site ou du moins la CSS serait à jeter à partir d'une certaine date, ça contredit totalement le fait qu'un site bien intégré s'affichera dans les navigateurs du futur. J'ai par exemple réalisé des sites il y a 5 ans voir plus qui sont toujours vaillants, même s'ils seraient bien sûr améliorables. En soi, la « technologie CSS » est robuste, pérenne et le site peut durer et continuer de bien s'afficher durant longtemps, même si ça serait améliorable.

Mais tout ce que nous apprenons en ce moment risque d’évoluer, jetant aux oubliettes les méthodes et les bonnes pratiques que nous sommes justement en train de théoriser.

Effectivement, toutefois, encore une fois je nuancerai. Ce qui est appris l'est une bonne fois pour toutes, par contre, ce que l'on choisit d'en faire va énormément évoluer. Là, par exemple, OOCSS est une grande technique à la mode, en tout cas ça en parle dur sur Twitter.

À mon sens, l'intégrateur éclairé doit surtout savoir repérer les limites de ces visions de CSS (tirer le bon grain de l'ivraie). Typiquement, OOCSS a de grands avantages, c'est indéniable, par contre, la contrepartie est une forte fragmentation des déclarations. RÖCSSTI m'apporte une excellente réutilisabilité de mes propriétés (DRY), toutefois, faire un refresh d'un site sans toucher à autre chose que la CSS peut être difficile (hé oui, quoi qu'on en dise, les CSS alternatives n'avaient pas que des inconvénients). Etc.

En matière d'intégration, tout choix a ses avantages et ses contreparties.

Le tout est d'en avoir une vision congruente, et – objectif suprême de l'intégrateur – inventer son propre style d'intégration.

Et quand vient notre tour de juger le travail de nos pairs, ne perdons pas de vue que nous ne connaissons pas les contraintes avec lesquelles ils ont dû jongler.

Cela, c'est quelque chose de vraiment important. Critiquer, argumenter, c'est bien. Prendre en compte le contexte, c'est vraiment mieux.

L'expression polie du domaine, c'est « être en contexte de production ». En clair, ça veut dire que vous êtes en temps limité et parfois même que 10 demandes arrivent en même temps (et parfois que vous en prenez plein la gu…). Même à temps perdu, le site parfait n'existe pas, alors en plein stress, à pleine charge en temps limité, vous vous doutez bien que la perfection est encore plus dure à atteindre.

Personnellement, plus je suis dans ce « contexte de production », plus je prends du recul quand on me demande un avis.

Un simple mot élégant « tiens je vois que tu as fait ça, c'est dommage, j'imagine que tu n'as pas eu la possibilité d'aller chercher plus loin ? », quoi qu'on en dise, ce n'est pas si difficile.

Je ne suis sûre de rien

Sûr, non.

Par contre j'ai des convictions. Le Web bien fait (accessibilité, qualité, etc.) a de l'avenir. La simplicité et l'élégance du code sont de bons indicateurs. L'universalité du Web n'est pas une option mais un principe.

Quand je me questionne sur l'effroyable complexité d'une technique, un réflexe : back to basics (retour aux fondements). Quel est la mission de base du Web ? Une solution universelle.

Tout ce que je sais, c’est que je ne sais rien.

Pas totalement rien, mais si peu de choses :)
En fait, c'est quand j'explique à un débutant que je me rends compte que je sais « quelques trucs ». Et plus j'en apprends, plus je me rends compte de l'immensité de tout ce que j'ignore.

Je choisis non pas de le passer, mais de le donner (le 18/03/2013)

Peut-être aurez-vous compris, à l'inverse des dieux de la mythologie, que votre temps est compté sur cette planète. Eux savent qu'il y aura toujours la possibilité de revivre, de refaire… nous n'avons pas toujours cette chance ou même cette possibilité.

Certains trouveront cette entrée abrupte, personnellement, cela ne me choque pas, c'est un simple état de fait.

Peut-être en prendrez-vous conscience lors d'un « accident de la vie » comme on les nomme, ou parce que votre santé n'est pas aussi bonne que vous le souhaiteriez, parce que vous le voyez s'écouler ou par simple sagesse… peut-être d'autres façons, ou même de plusieurs manières en même temps.

Rassurez-vous, il n'y a rien de déprimant dans mon propos, cette conscience n'a rien de négatif d'ailleurs, il n'y a pas de raison.

En fait, cela m'inspire mon rapport au temps. Peu ou prou, je me dis que mon temps, c'est de l'argent (par mon travail), c'est ce que je recherche (la connaissance), c'est le bonheur (l'amour, l'amitié), c'est la passion (le Web), etc.

En fait, mon temps, c'est ce qui me permet tout, avec une santé raisonnablement correcte bien sûr. C'est donc ma chose la plus précieuse. Une fois cela compris, le rapport au temps est vraiment différent, ce dernier étant donc limité.

En fait, j'ai choisi non pas de le passer, mais de le donner. Aux choses qui m'importent, aux personnes qui comptent, aux projets qui m'intéressent, etc.

Et depuis que j'ai pris ce point de vue d'une ressource précieuse que je possède et que je donne au lieu de passer (et en poussant ce raisonnement suffisamment loin), je trouve que la vie a une saveur délicieusement divine.

Retour sur le mini-buzz « mise en prod » (le 15/03/2013)

J'ai lancé ce micro-site « Est-ce qu'on met en prod aujourd'hui ? » le vendredi 22 Février de cette année. Cette page avait pour unique but de faire sourire mes connaissances et ceux qui rencontrent le même souci que moi : à savoir qu'on nous demande de mettre des sites en production le vendredi, ce qui est gênant s'il y a des soucis.

Je pensais que la page en question serait partagée une dizaine de fois, un ou deux éclats de rires, et merci au revoir. J'avais pris un hébergement tout simple, le plus basique qui soit (il n'y même pas de base de données).

La réalité a dépassé de très loin tout ce que je pouvais imaginer.

Est-ce qu'on met en prod ?

En fait, j'ai préparé la page à « la Rache » la veille, et lancé la page dans la matinée vers 10H20. Juste avant de le lancer, je me suis dit que ça serait bien de mettre quelques liens de partage sur Google+, Facebook et Twitter, au cas où (je ne m'en sers jamais). Je reprends les codes des méta-tags pour les partages sur ledits réseaux depuis un autre site fait au boulot, sait-on jamais ! J'avais ajouté les Twitter Cards, mais la page n'était même pas validée. Le tout toujours fait à « la Rache ».

Je lance le lien, effectivement, je reçois quelques mentions de personnes qui ont souri. Sauf qu'au bout d'un gros quart d'heure, tout s'emballe, quelques comptes Twitter bien suivis retweetent l'annonce. Tout à coup, je vois une quantité monstrueuse de mentions sur Twitter. Ironie du sort, j'avais pensé à mettre un code de suivi Google Analytics, je décide d'aller voir sur les rapports en temps réel (en général, je n'y vais jamais). 150 personnes sont sur la page en même temps, 200… 250 ! (‽)

La carte qui indique où sont les personnes qui sont sur la page en temps réel s'allume comme une guirlande. Je peux presque voir le truc se répandre : « tiens untel a retweeté, ça vient de toucher Lyon ». Je suis pantois devant le phénomène.

Carte des visites en temps réel

Toujours sur l'affichage des visites en temps réel, je vois même certains qui essaient de hacker la page ou de voir s'il y a un système derrière, des /?day=1, /?today=lundi sont tentés. J'avais même pas prévu un système aussi élaboré ! ;)

Là, je me dis que cela va se calmer en début d'après-midi, que nenni ! Plusieurs vagues reprennent régulièrement. Les dizaines de mentions me concernant sur Twitter sont toutes les mêmes, celles du texte du lien de partage : « Est-ce qu'on met en Prod aujourd'hui ? https://www.estcequonmetenprodaujourdhui.info/ de @Nico3333fr ».

Fin de journée, le constat est édifiant : un peu plus de 18 000 visites en une journée !

L'hébergeur ronchonne un peu, le quota de trafic (même si la page est très légère) a explosé, je reçois notification sur notification. D'ailleurs, j'en reçois encore, la page a bouffé plus du double de son quota de trafic mensuel en une semaine. Depuis son lancement, la page a reçu 42 000 visites, dont 28 850 visiteurs uniques. Bien sûr, c'est redevenu plus calme, même s'il y a toujours un pic le vendredi, allez savoir pourquoi. :)

Qu'en retenir ?

La plus importante à mes yeux : l'humour est très présent chez les développeurs, intégrateurs, etc., quoi qu'on en dise, ça fait du bien de rire et d'en rire, et de voir que plein de gens en rient aussi.

Des liens de partage discrets fonctionnent, si la page suscite un intérêt. Comme vous pouvez le voir, je ne les ai pas particulièrement soignés.

Il n'y a pas besoin d'énormes moyens, une idée rigolote qui fait prendre la mayonnaise suffit. La page a été faite à « la Rache » la plus complète. Alors bien sûr, si vous avez dans vos contacts des personnes susceptibles de faire suivre, ça sera beaucoup plus facile pour lancer la machine.

Au final, je pensais laisser cette page telle quelle, mais finalement je vais la mettre à jour régulièrement. Si cela fait sourire, je crois que ce ne sera pas un mal. Et si ô grand jamais, cela évitait à une personne de se coltiner une mise en production le vendredi, j'en serai le premier heureux.

Préprocesseurs, mais c'est de la CSS au fait ! (le 12/03/2013)

Autant pour moi, j'ai dû oublier un smiley (ou peut-être n'avais-je pas la place, 140 caractères, c'est parfois juste) pour indiquer le second degré dans un tweet sur les préprocesseurs.

Précisons-le de suite :

  • oui, je n'utilise qu'assez peu les préprocesseurs,
  • oui, sans être indispensables, je reconnais bien volontiers que ça aurait bien pu m'aider dans certains projets,
  • oui, installer des trucs à la ligne de commande me fait braire (même si je peux le faire, ce n'est pas le débat),
  • et non, je n'ai jamais dit que les préprocesseurs étaient une mauvaise chose en soi.

Si vous doutiez du dernier point, je vous invite à relire une astuce sur Alsacréations : Utiliser PHP pour gérer vos styles feuilles de styles CSS.

Pas envie ? Je vais le faire pour vous.

Une variable pourra s'écrire ainsi…

On peut même imaginer un tableau contenant les préfixes en début de fichier, et une simple boucle permettra de créer tous les préfixes, vous simplifiant la vie pour ces derniers.

Une simple convention de notation permettra de générer directement les fichiers statiques…

Oh oh, cela ressemble furieusement à un préprocesseur en fait (oui, il fallait aller chercher plus loin entre les lignes que de lire bêtement). Donc si vous croyez encore que j'y suis allergique, passez votre chemin.

Alors certes, je sais que sur Twitter, les discussions peuvent être compliquées vu les limitations… il n'empêche ! C'est impressionnant la vitesse de réaction et parfois l'animosité dont les défenseurs des préprocesseurs peuvent parfois faire preuve. Le billet dont est parti le troll est le suivant : j'en peux plus de vos préprocesseurs.

L'article dénonce un point : le nombre de tutoriels qui ne sont pas rédigés en CSS pur mais utilisant un préprocesseur. Personnellement, cela me dérange aussi, car au moins un tutoriel en CSS sera compréhensible immédiatement par tous, y compris ceux qui n'utilisent pas du tout les préprocesseurs. À la base, on a tendance à l'oublier, le préprocesseur est quand même là pour… oui, pour cracher de la CSS.

Une autre question me taraude : que fait un débutant quand il cherche à apprendre à intégrer ? Oui, il va regarder ce que font les autres (et s'il est un peu futé, il va regarder ceux qui sont réputés). Le gros risque que je vois à ce que soulève ce billet, c'est de se reposer sur le préprocesseur au lieu de réellement apprendre à faire de la CSS. Tout comme il est stupide de se reposer sur la compression Deflate pour les performances d'une CSS.

Quoi qu'on en dise, la factorisation des propriétés, l'utilisation appropriée de la cascade, l'organisation et même le simple ordre des propriétés de votre CSS peut faire la différence entre une intégration d'expert et un boulot de malpropre. Malheureusement, le débutant a de grandes chances de ne pas voir cette différence s'il n'a pas appris à la base à faire de la CSS.

P.S : petit supplément, les préprocesseurs peuvent aussi générer des choses problématiques, donc les pro-préprocesseurs (ouf, dur à dire), s'il vous plait, respirez un coup et arrêtez de dire que les préprocesseurs lavent plus blanc et font revenir l'être aimé, aussi bien soient-ils, ce ne sont que des outils qui ne remplacent pas l'interface chaise-clavier qui les manipule.

N'oublions pas les hommes (le 08/03/2013)

Aujourd'hui, c'est la journée internationale des droits de la femme.

Rien à voir, mais j'en profite juste pour faire entendre une voix qu'on entend trop peu : celle des hommes qui ont totalement intégré depuis longtemps le total respect des femmes et l'égalité homme/femme, que ce soit dans le travail ou à titre personnel.

Je vous rassure, non pas que nous souhaitions nous plaindre, nous poser en victimes ou revendiquer je-ne-sais-quoi, nous voulons juste faire un amical coucou pour rappeler aux personnes qui généralisent abusivement la condition masculine que nous existons aussi.

À ces personnes, je vous le dis : tous les hommes ne sont pas des machos. On peut être fier et/ou content d'être un homme sans pour autant que cela implique de mépriser les femmes. On peut être aimable ou poli avec une femme sans autre objectif d'être aimable et poli. On n'en a rien à faire d'avoir une femme ou un homme comme supérieur, le seul critère est qu'il ou elle soit compétent(e).

Donc, ne nous oubliez pas, ce serait vraiment regrettable. Ne niez pas que nous existons, ce serait encore plus terrible.

P.S : et à titre personnel, celui qui me dit encore que la femme n'a pas sa place en informatique, en l'occurence dans le Web, je lui ris au nez. Bon nombre de personnes parmi les plus admirables dans le Web sont des femmes.

Laissez-nous le droit d'en rire (le 02/03/2013)

Oui, chers clients, chers partenaires, chers patrons, chers « mettez-ici-ce-que-vous-voulez », parfois, vous trouverez des commentaires débiles dans le code PHP de nos sites, parfois, vous afficherez une CSS et vous serez peut-être surpris de voir des noms de classes ridicules et/ou des commentaires idiots.

Oui, vous pourrez croire – et j'insiste bien sur le mot « croire » – que nous nous moquons de vos sites, de vos entreprises, de vous-mêmes. Toutefois je puis vous certifier que ce n'est pas le cas, les seules personnes dont nous pouvons éventuellement nous moquer, ce sont nous. Et parfois des navigateurs qui nous offrent des moments de folie absconse. Surtout les vieux.

Même si nous avons fait énormément de progrès – et nous continuons d'en faire – gardez à l'esprit que faire des sites performants, qui s'affichent bien dans tous les cas de figure (dimensions avec le responsive, sur les vieux navigateurs, etc.) est vraiment quelque chose de difficile. Sans entrer dans le détail, cela demande des compétences incroyablement vastes, de la rigueur et une créativité folles.

Parfois, nous nous prenons la tête à un point difficilement imaginable. Nous ne vous en parlons jamais. Par contre, comme nous ne sommes que des humains, nous utilisons l'humour comme soupape de sécurité, tout comme le font plein de gens dans plein d'autres métiers.

Là est la nuance : nous faisons notre travail avec un très grand sérieux, mais sans nous prendre au sérieux. Croyez alors que si vous voyez une petite touche d'humour ou un pétage de plomb en commentaire, c'est surtout la preuve que vous avez un être humain qui est derrière, avec ses imperfections mais surtout avec tout le cœur qu'il a voulu mettre pour bien faire son travail. Pour vous.

Vous ne voyez pas nos conférences. Vous ne voyez pas comment nous écrivons nos articles ou quand nous créons. Derrière ces choses froides et méchantes que sont du code et/ou de la technique qui ne vous intéressent pas, il y a de l'humain. Et croyez-moi, ces humains en valent la peine.

Les seules choses qu'ils vous demandent sont :

  • que vous les écoutiez un peu,
  • le droit d'en vivre décemment,
  • et le droit d'en rire.

Dès lors, quand vous verrez un petit « easter egg » ou une touche d'humour, ne jugez pas, riez-en. Tapez « idkfa » en étant sur ce site, vous saurez peut-être que c'était le code pour avoir pleins d'armes à un vieux jeu nommé Doom (sur un clavier azerty). Et quand vous verrez le résultat, ne cherchez pas, souriez, c'est une blague.

Donc, pour que nous continuions à rester des humains, laissez-nous le droit d'en rire, et de rire.

Cher client, je comprends votre colère… (le 23/02/2013)

Note : ce billet est totalement fictif. Toute ressemblance avec des projets existants ou ayant existé ne serait que fortuite. Ou pas, la réalité dépassant souvent cette fiction. Second degré ? Mais non !

Cher client (vous permettrez que je vous appelle ainsi), je comprends votre colère.

La mise en ligne prévue pour hier a été reportée à aujourd'hui. Je reconnais qu'il est regrettable qu'il y ait eu ces cafouillages. Je comprends également qu'étant devenu votre principal interlocuteur, je suis en première ligne pour entendre vos reproches. Je ne comprends d'ailleurs pas l'agence de communication : tant que vous et elle étiez satisfaits de notre travail, nous gardions l'agence pour unique interlocuteur, vous ignoriez même jusqu'à notre existence. Et là, subitement, elle nous demande de vous contacter pour vous expliquer les problèmes, alors que nous lui avions détaillé clairement les soucis à vous retransmettre, non, je n'ai pas compris.

Pourtant, cette agence a suivi votre projet avec le plus grand sérieux : rien qu'aujourd'hui, j'ai reçu une dizaine de coups de fil de leur part afin de me rappeler votre mécontentement de cette situation. Croyez qu'ils prennent en compte avec sérieux vos intérêts, vu que même plusieurs personnes de l'agence ont appelé.

Autre preuve de sérieux, ils ont beaucoup écouté quand nous avons conçu ensemble votre site internet. Certes ils nous ont fourni les maquettes de votre site en version desktop, mais ils nous ont laissé le soin de concevoir tout le côté responsive de ce dernier. J'ose espérer que la tension de ces deux jours n'effaceront pas les commentaires élogieux que vous leur avez transmis (et qu'ils nous ont fait suivre).

Qu'il me soit permis de reconnaître mes torts : oui, j'ai présumé que votre hébergement serait suffisant pour faire tourner votre nouveau site. C'est de ma faute, je devrais pourtant savoir que tous les hébergeurs, présentent-ils aussi bien que votre désormais ancien hébergeur, ne sont pas tous sérieux. Indiquer PHP5 sans pour autant l'avoir à jour est vraiment quelque chose dont j'aurais dû me méfier.

Je reconnais que j'aurais dû réagir de suite hier matin, date à laquelle j'ai reçu les accès pour votre FTP. Il faut dire que l'agence de communication qui aurait dû rester votre unique interlocuteur m'a fait suivre ces accès avec les nombreuses modifications de dernière minute. Comme j'avais pour consigne de ladite agence de faire ces modifications en urgence absolue afin que cette dernière vous les transmette, j'ai tout mis en œuvre pour que le site soit parfaitement terminé en premier, bien mal m'en a pris, j'ai vérifié les accès de votre FTP seulement 3 heures après.

Fort heureusement, votre ancien site se connectait à l'ancienne base de données en utilisant les droits dits « root », car comme les accès transmis par votre ancien prestataire ne nous permettaient pas de faire quoi que ce soit sur la base de données, nous avons dû improviser. Enfin, nous avons été chanceux, ces droits nous ont permis de nous connecter à la base et de faire les essais nécessaires.

Bien sûr, je regrette que nous nous retrouvions en contact dans une ambiance aussi tendue. Ajoutons à cela que le fait que votre ancien prestataire ait été difficilement joignable à un moment aussi crucial n'a pas facilité cette mise en ligne chaotique : ce dernier avait réservé votre nom de domaine à son nom au lieu de le mettre au vôtre, vous n'aviez pas la possibilité de faire des modifications sans lui. Encore une fois, je suis fautif : j'ai fait la bêtise de croire que le prestataire technique aurait eu l'honnêteté de se mettre en simple contact technique sur la gestion de votre nom de domaine.

Néanmoins, je ne puis jeter la pierre à ce dernier, même s'il ne vous a toujours pas donné ces accès qui vous sont dûs, il nous a répondu afin de basculer les DNS en temps et en heure. Je regrette toutefois qu'il n'ait pu être disponible que jusqu'à 15H, cela nous aurait permis de faire les choses avec un peu plus de sérénité. Enfin, je comprends que son départ en vacances n'était pas négociable et que les DNS devaient du coup être basculés avant.

Il a fait preuve d'un grand professionnalisme : nous signaler les erreurs d'encodage de l'ancien site afin que nous puissions solutionner et régler 5 ans de dette technique, c'était aimable, vu que nous avons repris certaines bases de l'ancien site.

Toutefois, permettez-moi de défendre votre nouvel hébergeur, même s'il vous a semblé qu'ils mettaient du temps à répondre, je puis vous assurer que créer un hébergement, me transmettre toutes les informations, m'aider à solutionner quelques problèmes techniques de dernière minute, tout cela en moins de 3 heures, soyez sûr que c'est une preuve de grand professionnalisme. Qui plus est, sans entrer dans de verbeux détails techniques, ce dernier m'a permis d'activer certaines fonctionnalités qui accéléreront grandement votre nouveau site en responsive : diminuer de 2/3 le poids des fichiers textuels (on appelle cela la compression GZIP) là où les mêmes directives faisaient planter votre ancien hébergement, croyez-moi, c'est bien mieux.

En tout cas, maintenant que tous ces problèmes sont réglés, je vais me permettre de vous souhaiter un bon week-end, je ne sais pas pour vous, mais moi cette mise en ligne le vendredi m'a bien épuisé.

P.S : En tout cas, soyez assurés de la fierté de l'agence de communication, les captures d'écran de votre site sont déjà prêtes sur leur site, elles y présentent les aspects responsive de votre site : en smartphone, avec une résolution d'une tablette en portrait et en version desktop. Et afin de, j'imagine, ne pas diluer le page rank du lien vers votre site, ils ont préféré ne pas nous mentionner. C'est encore une grande preuve de professionnalisme assurément.

Les surprises de l'écriture (le 15/02/2013)

Souvent, quand je propose à quelqu'un d'écrire un article, l'argument suivant sort : « oh mais j'ai peur de dire une ânerie ».

Même si je reconnais avoir aussi cette crainte parfois (surtout quand je publie sur un site plus connu que le mien, comme Alsacreations ou Openweb), ce n'est pas toujours celle qui me tiraille le plus, après quelques expériences surprenantes.

En fait, si vous écrivez, vous constaterez deux choses :

  • il est impossible de satisfaire tout le monde (oui, il y aura toujours quelqu'un pour râler),
  • et vous n'aurez pas la maîtrise de ce que les gens verront dans votre article.

Le premier point est un effet qui vient dès que vous écrirez : n'imaginez pas que plus votre article sera pointu moins vous aurez de critiques. Vous trouverez toujours quelqu'un de bien intentionné (ou pas) pour trouver quelque chose à redire, soit de la technologie que vous évoquez, soit de votre propos. Abandonnez l'idée de plaire à tout le monde, c'est juste impossible, et c'est surtout une perte de temps.

La second point est plus délicat : parfois les gens vont lire en diagonale votre article, et ils pourront manquer une mise en garde ou du moins la quintessence de votre propos. Encore une fois, vous ne pouvez que difficilement lutter contre cela. Pour vous donner un exemple, il m'arrive encore de citer mon premier article sur Openweb, Avoir plusieurs présentations alternatives. Souvent, j'entends « oui, mais les CSS alternatives, on n'en fait plus ». C'est vrai, ceci dit, cela n'invalide pas le propos de l'article : trouver une structure unique permettant d'appliquer des styles différents. Même si je ne produis plus de CSS alternatives sous cette forme, il m'arrive encore de bénéficier de ces bons conseils lors de refontes rapides de certains sites.

Troisième point (oui, il n'y en avait que deux, c'est bien vous suivez, toutefois, c'est lié au second), il arrive que votre propos, aussi bien écrit soit-il, soit compris bien différemment de votre intention.

Je vous donne un exemple : j'avais écrit pour le Train de 13H37 l'article suivant : Conseils pour mieux gérer des projets complexes. Plusieurs personnes m'ont fait la remarque que c'était un article écrit de l'œil d'un chef ou d'un gestionnaire de projet. Une personne m'a même dit que j'avais de bonnes compétences pour devenir un futur chef de projet. Sauf que… pas du tout.

J'ai écrit cet article avec l'œil de l'intégrateur, et quand je parle de « mon équipe », cela n'est pas du tout en tant que gestionnaire de projet, mais en tant que partie de cette équipe. Je voulais surtout parler de l'attitude à avoir pour survivre à ces projets, car bien souvent, j'observe que les gens se précipitent vers l'attitude opposée, ce qui pourrit totalement ces projets. De plus, les articles se focalisent en général sur le savoir-faire, et très peu parlent du savoir-être. Pour avoir été sur un de ces projets au bout de mes forces et au-delà de tout ce que je pouvais imaginer en rapidité de production, l'attitude est vraiment quelque chose de primordial.

Là où c'est intéressant, c'est qu'en voulant parler d'une attitude de travail, certains ont compris gestion de projet, ce qui n'a pas grand chose à voir. Parfois, vous allez générer des discussions auxquelles vous ne vous attendiez pas une seconde, et ce, au total insu de votre plein gré. :)

Donc même si vous avez ces peurs, n'hésitez pas, écrivez ! Vous n'imaginez pas où un simple article pourrait vous emmener.

Thanks Mario ! But our princess is in another castle… (le 29/01/2013)

Si vous avez eu une NES, vous avez sûrement joué à Super Mario 1. Dans ce jeu, à chaque fin de monde, il y avait un niveau dans le château de Bowser qui se terminait toujours de la même façon : vous battiez un gros Bowser, et vous arriviez à la fin du niveau.

Fin de niveau Super Mario Bros 1 NES

Le tout était assez agaçant, car à chaque fois, c'était un Toad qui était là et qui disait la même phrase stupide : « Thanks Mario ! But our princess is in another castle ». En bon français, « Merci Mario ! Mais notre princesse est dans un autre château ». Et cela durant 8 mondes de suite.

Déjà, n'oublions pas la règle de communication : tout ce qui est avant le « mais » ne compte pas. « Je t'aime bien, mais » est un excellent exemple.

Au boulot, la grande variété de mes clients/collègues/contacts donne des réponses dans des styles très variés :

  • Enjoué : « c'est génial ce que vous avez fait ! »
  • Calme : « je vous remercie pour votre travail »
  • Sec et/ou désagréable : « c'est pas du tout ce que je voulais »
  • Etc.

Mais il y a une catégorie qui me rend fou, c'est la catégorie « Thanks Mario ! But our princess is in another castle… ». L'entendre une ou deux fois peut passer, mais certaines personnes ne peuvent s'empêcher de placer un « mais », lequel annule les félicitations ou le merci qui est juste avant.

Une fois passe, deux fois encore, trois à la rigueur… mais sans arrêt c'est insupportable. Quand j'étais en cours de communication, un des premiers principes que je me suis approprié (étant totalement d'accord avec), c'est la congruence : ne pas commencer sa phrase par « oui » si c'est pour dire « non » par exemple.

Dites de suite « non », ça ira plus vite ! ;-)

Bilan et résolutions de l'intégrateur pour 2013 (le 11/01/2013)

Rémi a posté ses trois résolutions d’intégrateur pour 2013, et cela m'a inspiré, je vais donc vous parler des miennes.

Le bilan de 2012 ?

Je pourrais parler de plein de choses :

mais je préfère faire simple : le métier d'intégrateur s'est incroyablement professionnalisé et complexifié cette année. De fin de maillon de la chaine, il est passé à une place d'atout maître dans la réussite de projets Web.

Et punaise, le Web francophone a vraiment de bonnes choses à dire, donc si vous avez envie d'écrire, n'hésitez pas, faites-le. Je vois tellement de gens intéressants dans les divers événements francophones auxquels j'ai pu participer/assister. Comme disait l'autre, n'ayez pas peur.

Les idées pour 2013

À défaut de résolutions, je préfère parler d'orientations ou d'idées pour cette année.

  1. Continuer à progresser en accessibilité, l'objectif est de faire une douce montée en compétence. Lentement, mais sûrement.
  2. Continuer à écrire, je peux d'ores et déjà vous annoncer que des articles sont prévus, dont certains en cours de rédaction. Et les idées foisonnent.
  3. Toujours bien s'occuper d'Openweb en particulier.
  4. (je n'avais pas d'idée pour ce point précis, je le laisse libre)
  5. Et surtout : que tous ces bons réflexes évoqués ci-dessus viennent le plus possible en standard dans mes réalisations à venir, dans la mesure du possible. Je n'ai pas la prétention d'être un expert en qualité Web, mais je veux vraiment que ces bonnes choses et ces progrès soit inclus au fur et à mesure. Je veux juste être fier de mon boulot (au mieux)… ou limiter la casse (au pire). Hé oui, la réalité des projets parfois nous dépasse/rattrape.

En conclusion :

  • Que ce métier évolue vite.
  • Ce métier est incroyablement nourrissant, intellectuellement parlant, pour celui qui aura la curiosité.
  • Il y a tant à écrire et à inventer pour que cette évolution se fasse bien.

Et c'est reparti de plus belle !

La réalité du développeur et la réalité du client (le 04/01/2013)

En cours de physique quand je faisais mes études supérieures, un prof m'a dit une fois à propos de trucs très compliqués (genre des équations différentielles auxquelles je cherchais solution) :

« Ne te prends pas la tête, aborde le problème d'un point de vue physique, pas mathématique. Genre si tu cherches une masse, les solutions négatives n'ont pas de sens, donc tu peux truander la résolution du problème ».

Remarque pleine de bon sens ! Pourquoi cette anecdote ?

Il y a quelques jours, un client m'appelle pour me demander un export de la base de données de son site Web, dans le but de vérifier avec son CRM si les deux bases coïncident bien.

Je fais un export rapide, le mets très brièvement en forme et lui envoie. Une journée se passe… et je reçois un e-mail m'indiquant que certains clients dans son CRM ne sont pas dans la base du site Web.

Surpris car ayant fait plusieurs consolidations il y a un an sur cette base, je décide d'enquêter et lui demande de me signaler plus précisément les problèmes. Je reçois mon propre export avec des entrées incriminées.

Je vérifie, effectivement, à première vue, les entrées signalées sont problématiques. Mon premier réflexe, ayant consolidé cette base moi-même un an plus tôt, est d'imaginer que ce sont de vieilles entrées. Pourtant, un point me choque : les entrées ont des dates de validité plutôt variées, et bon nombre d'entre elles devraient même être valides actuellement.

Or, si je transpose en langage courant : si un client a payé et n'a pas son accès, vous pouvez être sûr qu'il va – et il aura raison – hurler littéralement. Alors plusieurs, imaginez !

Je pousse mes recherches plus avant, et je découvre que ces entrées sont bien dans la base de données, mais juste que le client s'était trompé dans ses comparaisons entre sa base et la mienne.

Pourquoi cette histoire ?

Il arrive que la réalité du développeur et la réalité du client puissent être différentes, là où le développeur ne voit que des id et des enregistrements, le client voit son activité. Si vous voulez éviter des discussions stériles, il est important de parler le même langage, ou à défaut, de traduire votre langage dans le sien, et réciproquement.

Là, sur cette histoire, coquin de sort, c'est l'inverse qui s'est produit : le client a scruté une base avec l'œil d'un développeur sans transcrire cela dans le monde réel, en a résulté une aberration qui m'a sauté aux yeux, car justement j'ai transcrit cela en réalité « physique ».

Parfois les systèmes très complexes ne permettent pas ou très difficilement cette transposition… et c'est bien dommage. Cela permet au développeur de prendre du recul sur son travail et de lui faire sauter au visage les choses incongrues ou impossibles. Il va donc pouvoir alerter le client ou son supérieur de ces problèmes.

J'y vois un parallèle avec l'anecdote énoncée au début de ce billet, aborder les problèmes avec une solution physique permet d'éviter des solutions justes programmatiquement, mais qui n'ont aucun sens pour un utilisateur « réel ».

Encore un manifeste pour programmer des systèmes simples et naturels, le KISS en somme !

Note de lecture : Éco-conception web / les 100 bonnes pratiques (le 01/01/2013)

Grâce a une opération Kiwiz d'Alsacréations et aux éditions Eyrolles, j'ai eu le plaisir de recevoir « Éco-conception web / les 100 bonnes pratiques ».

Éco-conception web / les 100 bonnes pratiques

Ce petit guide présente et explique brièvement les enjeux de l'éco-conception web avec des chiffres impressionnants à l'appui :

  • les infrastructures de l'Internet (data-centers, réseaux, etc.) et le Web mobile représentent 3% de la consommation électrique mondiale,
  • et les émissions de gaz à effet de serre associées dépassent 2% du total émis par l'humanité, soit autant que celles de l'aviation civile (!).

Toutefois, ce n'est qu'une courte introduction, l'essentiel du livre consiste en des bonnes pratiques très concrètes à appliquer pour réduire l'empreinte écologique des sites et au passage améliorer les performances de ces derniers.

Chaque bonne pratique est accompagnée d'un exemple et de divers critères :

  • sa difficulté de mise en œuvre,
  • le niveau d'impact écologique (fort ou modéré),
  • si elle est prioritaire ou non à mettre en place,
  • et les postes d'économie sur lesquels elle permet d'effectuer des économies : processeur, mémoire vive, stockage, réseau et nombre de requêtes.

Tous les domaines sont concernés : l'architecture, l'intégration (une part conséquente), le code client (JavaScript, DOM, etc.), le back-end, l'hébergement et les contenus.

Les points forts de ce livre sont là : c'est très concret, cela touche à tous les domaines du Web, et c'est très agréable et rapide à lire. J'y ai retrouvé de nombreux points de qualité et de performance Web, et j'ai même retrouvé des points que j'explique depuis des années à certains clients, qui trouvent en plus une justification écologique là où je les justifiais juste par la qualité Web.

À mon humble avis, c'est une excellente lecture que tout professionnel du Web soucieux de qualité doit lire de toute urgence, pour ma part, je l'ai dévoré en moins d'une soirée avec un très grand plaisir. À lire de toute urgence !

Vous avez et vous aurez toujours le choix (le 30/12/2012)

Est-ce peut-être un effet d'une certaine maturité du Web, je constate de nombreuses interrogations d'ordre éthique, que ce soit sur ce que l'on produit (la qualité, l'accessibilité, etc.) ou sur les services que l'on utilise.

Côté production, la conférence de Mike Monteiro à Paris-Web 2012 le dit très bien : you are responsible of what you put in the world.

Côté services utilisés, je ne vais pas égrener les nombreux posts sur le sujet, les derniers qui me viennent à l'esprit sont la modification des conditions générales d'utilisation d'Instagram, et l'omniprésence de certains titans, comme Google ou Facebook.

Pourquoi ce propos ? Je vois de très nombreuses réactions à un billet nommé The Web We Lost.

Je n'ai rien contre l'idée de ce billet en soi, mais je tiens toutefois à rappeler la seule règle qui prévaut : vous avez le choix de mettre votre énergie là où vous le souhaitez, et vous avez la liberté de le faire.

Par contre, le choix de la liberté n'est peut-être pas toujours le plus facile, et encore, c'est très relatif. Vous voulez apprendre quelque chose ? Ça tombe bien, il est peu ou prou possible de tout trouver sur Internet. Ce n'est donc plus une question d'offre. Et si vous ne trouvez pas, vous avez les moyens de le créer vous-même.

Vous croyez que vous êtes prisonniers de quelque chose ? Mais libre à vous d'utiliser ce que vous aimez de la manière dont vous le voulez. Vous dénoncez quelque chose ? Investissez-vous donc.

Je peux vous assurer qu'une détermination sans faille peut soulever des montagnes. La seule chose qui soit un frein à votre détermination à faire des choses, disons-le franchement, est dans votre miroir. Vous avez le choix, vous avez toujours le choix. Envers et contre tous, vous avez et vous aurez toujours le choix.

Quand vous aurez accepté cet état de fait, vous agirez en personne libre.

Les bonnes résolutions des graphistes (le 29/12/2012)

Rions un peu en cette fin d'année où il est souvent question de bonnes résolutions : j'ai imaginé ce que seraient les bonnes résolutions… des graphistes, enfin, de certains graphistes.

Je vous invite à rêver d'entendre certains graphistes vous dire cela :

  • Je n'utiliserai pas plus de 3 typographies différentes dans mes maquettes. Et si possible, j'utiliserai des webfonts dont la license nous facilite la vie à tous.
  • Je promets que je respecterai la bonne résolution précédente. Si si, je le jure.
  • NON, 10 PIXELS, C'EST TROP PETIT POUR LE CORPS DE TEXTE ! JE RÉPÈTE… ah oui, et les majuscules, c'est pénible à lire aussi.
  • Non, dire au client que la maquette sera rendue telle quelle partout alors que j'ai mis plein d'options de lissage à la noix sur les polices sous Photoshop, ce n'est pas bien.
  • Si l'intégrateur me dit que tel élément de typographie n'est pas utilisable de manière sûre sur le Web, je ne fais plus mon enfant gâté et j'apprends à lâcher prise.
  • J'utiliserai l'option pour enregistrer des images optimisées. Car une image en deux couleurs qui pèse 600 kilo-octets, ce n'est pas normal !
  • Je ne serai plus de mauvaise foi : posséder un iPad, en vanter grassement les mérites tout en disant que Flash est une technologie d'avenir pour les sites internet, ce n'est pas sérieux.
  • Oui, je sais que tout le monde n'a pas un écran 40 pouces (ou plusieurs), même si c'est le cas chez mes collègues graphistes ! :)
  • Corollaire de la précédente, je ne vous demanderai plus d'adapter le site uniquement pour mon écran gigantesque !
  • Non, je ne vous demanderai plus de faire « comme sur tel site »… si le site en question charge 10 000 effets jQuery dispensables.
  • Corollaire de la précédente : quand vous parlez de problème de performances, j'ai compris que vous ne parliez pas de la rapidité d'exécution d'un script très lourd sur ma bécane de compétition en local, mais bien du temps pour le télécharger, et sa propension à faire ramer les machines plus modestes quand le site sera en ligne.
  • Non, je ne vous demanderai plus de programmer quelque chose sur un site « pour voir », et vous demander juste après de tout rechanger. La réflexion, c'est important, et ça se fait avant. Et le temps de l'intégrateur aussi est important.
  • Corollaire de la précédente : les maquettes sont là pour dire à l'intégrateur ce qu'il doit faire. Pas pour que je mobilise un intégrateur pour trouver ce que je dois lui transmettre.
  • Non, non et non, j'utiliserai les effets de calques sous Photoshop avec précaution !
  • Si l'intégrateur doit faire les exports, je lui fournirai un fichier Photoshop bien organisé, et plus une soupe de centaines de calques désordonnés.
  • Demander à l'intégrateur du pixel-perfect au point qu'il en mette une règle sur son écran n'a aucun sens, et maintenant, je sais en plus que ce genre de demande va m'attirer son animosité. Même si je viens du print où j'avais l'habitude de tout contrôler. En Web Design, c'est pas comme cela que ça marche.
  • Si je veux faire des efforts quand je vous envoie des indications sur les styles de ma maquette, je penserai que les balises ont un sens, donc si je mets un h2, c'est bien qu'il y aura un h1 avant.
  • Je ne ferai plus de maquette ou aucune balise hx n'est stylée de la même façon sur chaque page. Plus jamais.
  • Non, l'accessibilité n'est pas là juste pour brimer ma créativité mais bien pour rendre service aux utilisateurs, à TOUS les utilisateurs.
  • Non, les em ne sont pas une invention d'intégrateur juste pour me complexifier la discussion avec ce dernier.

Note : c'est de l'humour, nous ne sommes pas parfaits non plus.

Dans le même genre :

Retour d'expérience sur une CSS mobile-first/responsive (le 28/12/2012)

Chose promise chose due, je vous présente plus avant la dernière CSS de ce site, et un petit retour d'expérience sur une approche mobile-first.

Reprenons les objectifs énoncés dans le billet précédent et détaillons !

Lisibilité

Pour le dire clairement, j'en avais marre d'entendre que mon site était pas assez lisible, et moi-même je recherchais avant tout un confort de lecture tous périphériques confondus.

En postulat de base, j'ai fixé la taille de fonte à 16 pixels, et utilisé la police Roboto, très agréable à lire sur petit écran comme sur un grand. D'ailleurs, sur les grands écrans, la taille se porte même à 17 pixels, rien que pour vos yeux (fatigués s'entend).

Côté contrastes, bien sûr, les valeurs des couleurs ont été choisies en utilisant les outils habituels. Allez lire « Les contrastes de texte sur Openweb », cela m'évitera de devoir tout ré-expliquer ici ce qui a été mieux expliqué là-bas.

Le principal point qui bloquait sur mes précédentes CSS était le nombre de caractères par ligne, trop élevé. Cette fois, je l'ai réglé très simplement par un max-width: 40em; qui, d'après plusieurs essais, permettait un bon compromis (les grandes lignes ne me gênent pas, ce qui me handicape fortement pour comprendre que des lignes plus courtes sont plus agréables pour la plupart des utilisateurs).

Sinon le mot d'ordre était : de l'air, de l'espace, aérons ! Vivent les padding et autres margin à grands renforts d'em.

Bien évidemment, j'ai repris divers éléments de mon « nano-framework » CSS autoproclamé, RÖCSSTI.

Une CSS mobile-first

Disons-le tout clair, à l'instant où j'écris, cette CSS est la seule que j'ai conçue en mobile-first. Donc, pardonnez-moi d'avance si je dis des évidences ou des bêtises.

La première chose qui est bizarre en mobile-first, c'est justement de fonctionner à l'envers. Quoi qu'en disent certains puristes, en milieu professionnel, je pars toujours de la version desktop pour atteindre la version mobile. Non pas que l'approche mobile-first soit mauvaise, mais elle est peu répandue (mes clients ont parfois déjà du mal à penser « petit écran », alors « petit écran d'abord »…).

Donc vos CSS d'habitude jonchées de @media (max-width: 640px) { voient plutôt arriver des @media (min-width: 400px) {. C'est une habitude à prendre.

Le but du jeu est de définir le cœur de votre CSS pour le mobile, un tri rigoureux s'impose, vous ne devez garder que le strict nécessaire, et le cas échéant, fixer d'entrée de jeu des règles qui vont servir (là, il faut bien faire attention à éviter les redéfinitions). Pour cela, RÖCSSTI ainsi que ma précédente CSS m'ont bien aidé pour ne pas perdre de temps à cause d'oublis.

Le principal ennemi du mobile-first, c'est… notre écran quand nous codons ! Comment penser petit écran alors que mon propre écran ne l'est pas ? Il y a bien l'option « je fais un changement dans ma CSS et je teste de suite sur un petit écran », mais c'est pénible.

J'ai trouvé un très bon allié en la Web Developper Toolbar, notamment grâce à l'option Redimensionner > Modèles Adaptatifs.

Modèles Adaptatifs de Firefox

C'est vraiment très pratique, ainsi, l'impact d'une modification peut être vu très rapidement dans plein de résolutions. On est d'accord, cela ne remplace pas des tests, mais c'est vraiment un outil très bien.

La règle d'or : il faut à tout prix être bien satisfait d'un palier pour envisager une résolution supérieure, quitte à chipoter et fignoler.

Des performances

L'approche mobile-first va de pair avec une contrainte forte de performances. Pour cela, pas trop de souci, les Data-URL se sont chargées d'afficher les quelques rares images (ces images PNG ont été fortement optimisées avant d'être transformées), et sinon les propriétés de CSS3 viennent générer les quelques effets pour embellir ce thème quelque peu épuré.

Côté CSS, c'est un poids très raisonnable : 3,2 ko minifiée et compressée (avec donc des gradients et des Data-URL aux codes particulièrement lourds).

Afin de diminuer le poids du JavaScript par rapport à l'ancien skin, je me suis orienté vers jQuery In parts (jQuip), largement suffisant pour mes besoins, et bien plus léger que jQuery.

Au final, les chiffres sont assez satisfaisants, cela donne sur la page d'accueil :

  • selon Web Page Test, le first view est à moins de 2 secondes et le repeat view est à moins d'une seconde sur un navigateur de type desktop,
  • d'après le même test, le poids total de la page est à 58 ko pour 8 requêtes.
  • Côté mobile, selon Mobitest et Web Page Test, les temps de rendu sur mobile sont en moyenne en-dessous de deux secondes et demi. L'approche mobile-first y est pour beaucoup !

Je pourrais encore améliorer en me passant totalement de JavaScript ou en optimisant plus son utilisation (ce qui est tout à fait possible), mais cela viendra dans un second temps. Avoir beaucoup travaillé les performances lors de la précédente refonte m'a fait gagner énormément de temps. Le gros du boulot étant déjà fait, je n'avais qu'à me concentrer sur ce que je faisais de nouveau.

Du responsive

Je n'avais pas d'idée précise en démarrant la CSS, j'ai légèrement tatonné selon les périphériques, mais les choix sont venus rapidement : le contenu impose les adaptations avec les contraintes de lecture. Par exemple, les images de mon portfolio passent côte à côte passés les 500 pixels pour une raison simple : elles font toutes 200 pixels de largeur. En prévoyant une marge de sécurité entre ces images histoire de faire respirer le contenu (il y en a deux maximum par réalisation), le tour est joué.

C'est le même principe pour la gestion du menu et des images du portfolio sur la plus haute résolution prévue : en prévoyant une marge de sécurité, j'ai pu facilement m'amuser avec CSS pour les faire sortir du contenu. Du coup, le site profite facilement des meilleures résolutions.

La propriété qui m'a énormément aidé est la suivante : max-width: 40em;. Au lieu de raisonner en largeur fixe, j'ai raisonné en largeur maximale. Du coup, cela m'a beaucoup facilité la vie tout en solutionnant mon postulat de lisibilité de facto.

Après, j'ai ajouté petit à petit les effets CSS3 à partir de certains paliers pour soulager les plus petits écrans de rendus non indispensables.

La grosse (et bonne) surprise a été la gestion du zoom global : le site répond très bien au zoom global, avant comme arrière.

Et Internet Explorer dans tout cela ?

Disons-le assez franchement, les vieilles versions d'Internet Explorer ont été le cadet de mes soucis. Les visites sur mon site sont à 10% pour IE toutes versions confondues, et la version 9 et 10 représentent 60% de ces 10%. Autrement dit, j'ai considéré que les vieilles versions d'IE étaient quantité négligeable. Et les autres skins sont toujours disponibles si ça dérange.

Dans un second temps, je pourrai ajouter quelques classes conditionnelles pour améliorer le tout sous les IE inférieurs au 9, c'est tout à fait envisageable et faisable, le ciblage par classes conditionnelles n'interfèrant pas avec la CSS « normale ».

En conclusion

Faire une approche mobile-first est un exercice de style intéressant (si vous me permettez ce jeu de mot). Cela nous invite à casser les habitudes « je démarre en desktop et je cache des contenus » pour dire « je construis au fur et à mesure ». Cette approche est très efficace : les « petits écrans » se retrouvent à rendre le strict minimum au lieu de se taper le boulot à double, et ce sont les plus hautes résolutions qui encaissent une CSS plus « lourde ». Je mets « lourde » entre guillemets, car vu le poids de la CSS, c'est vraiment peanuts.

Ce n'est pas difficile en soi, c'est une petite gymnastique intellectuelle à prendre. Je n'ai pas pris énormément de temps pour la réaliser, c'est l'affaire de 2 bonnes journées de travail.

À mon humble avis, cette approche sera standard dans quelques années, le temps de se débarrasser des navigateurs qui la gênent fortement (IEs inférieurs au 9) et d'éduquer nos clients ainsi que nous-mêmes à cette manière de travailler. Elle a le mérite de mieux équilibrer les rendus et les performances entre les divers périphériques.

La sensation qui m'a motivé tout le long était l'impression de faire une CSS plus efficace, une CSS bio en quelque sorte.

Si vous voulez étudier la CSS, je vous invite à la lire ici : ND Mobfirst non minifiée. Attention, des morceaux d'humour débile peuvent s'être glissés dedans.

Par contre, une chose me sidère : j'ai écrit la base de la structure de ce site il y a presque 9 ans, même si je l'ai légèrement modifiée depuis, la structure n'a que peu évolué. Vous ne trouvez pas in-cro-yable que le code que j'ai pondu (avant même que le Web Mobile existe) me permette de faire de telles choses 9 ans après ? L'expression « je développe des sites pour les navigateurs du futur » prend ainsi une sacrée dimension.

Songez à cette pérennité quand on mettra en doute les standards du Web.

Un refresh minimaliste en mobile-first (le 26/12/2012)

Histoire de finir l'année en douceur, je viens de mettre à jour le site, avec une nouvelle CSS alternative… rien de moins que la 26 e depuis la relance du site.

Vous le constaterez, le tout est très épuré, les objectifs étant :

  • d'avoir un confort de lecture maximal,
  • d'avoir une vitesse de chargement améliorée par rapport au précédent skin (qui avait déjà fait assez fort en la matière),
  • d'être adaptatif à toutes les résolutions via une approche mobile-first.

Je ferai un billet retour d'expérience sur cette refonte incessamment sous peu.

Note de lecture : Intégration Web, les bonnes pratiques (le 17/12/2012)

Il existe de nombreuses références où sont montrées toutes les possibilités d'HTML5 ou de CSS3, et ces livres sont très biens. Toutefois, il y avait un manque de livres qui nous indiquent comment bien faire ou du moins ce qui est faisable en production, et surtout avec un œil professionnel.

Fort heureusement, certains livres sont venus combler ce manque :

Et un « petit » troisième est arrivé… enfin, je mets « petit » entre guillemets, car « Intégration Web, les bonnes pratiques » n'est pas un petit mémo de 15 pages, mais plutôt une référence.

Intégration Web, les bonnes pratiques

Qu'en dire ? (oui, je fais durer le suspens pour faire enrager Corinne Schillinger, l'auteure de ce livre, qui j'espère lira ce billet)
Et bien le premier mot qui me vient à l'esprit, c'est : bravo.

Arriver à condenser le spectre de mon métier en un seul livre, c'est déjà un tour de force en soi. Et le faire bien, c'est encore mieux. Excusez du peu, partir de l'organisation de son espace de travail, des outils pour coder, faire un détour par les environnements de test (tous : IE, les services, les terminaux mobiles, les aides techniques, etc.), aborder la structure HTML et les fondations d'un code robuste, les images, CSS, les conventions d'écriture, les optimisations, le débogage, la livraison, etc. et tout cela avec un vrai point de vue pragmatique de quelqu'un dont c'est le métier, cela enchante l'intégrateur que je suis.

Bref, c'est très complet et cela fourmille de détails – et en intégration, le diable se cache dans les détails –, le genre de détails qui font la différence entre un intégrateur correct et un (très) bon intégrateur. Je retrouve certaines de mes habitudes qui selon moi doivent être des standards de travail : un code organisé, des htaccess soignés, des performances soignées, et surtout un grand soin du détail. Et j’en ai appris plein d’autres.

Point agréable, le côté très riche du livre ne se fait pas au détriment de la lisibilité. J'ai appris énormément de petits trucs qui vont bien, donc rien que pour cela, je suis ravi de cette lecture.

En résumé, ce livre vous donnera une bonne idée de ce que vous devez savoir/maîtriser, et conséquence directe, il vous permettra de voir où sont vos faiblesses. Assurément, « Intégration Web, les bonnes pratiques » est une référence en la matière. Si vous pensiez que l'intégration Web est un sous-métier nécessitant peu de connaissances, ce livre devrait vous remettre les pendules à l'heure.

Dois-je vraiment le faire ? (le 13/12/2012)

Je vois une question qui revient assez souvent chez les débutants comme les expérimentés en matière de Web, à savoir : je me tâte à écrire sur tel sujet/faire tel projet, mais dois-je vraiment le faire ?

Les motifs incriminés pour ne pas le faire sont souvent les mêmes :

  • Tout a déjà été dit sur le sujet.
  • Je ne suis pas sûr que ça va intéresser quelqu'un.
  • Je ne suis peut-être pas le mieux placé pour en parler.
  • Je n'ai pas le temps.
  • Je n'écris pas bien.
  • Etc.

Que ce soit sur des projets comme Openweb, Alsacréations, 24 Jours de Web, Le Train de 13H37, etc. ou pour votre site personnel, la question existe et ces arguments reviennent régulièrement. Pour ma plus grande tristesse d'ailleurs.

Oui, car j'affirme haut et fort que ces arguments sont mauvais. Pour vous, pour le Web, pour les autres, pour les chatons.

« Tout a déjà été dit sur le sujet »

Même si un sujet peut vous sembler avoir été traité en long, en large et en travers, il faut garder à l'esprit qu'un sujet et sa connaissance peuvent toujours évoluer, particulièrement en matière de Web ! Et est-il absolument impossible qu'un débutant ait besoin de lire sur le sujet et apprécie de vous lire ? Et vous, vous avez fait le tour du sujet ?

« Je ne suis pas sûr que ça va intéresser quelqu'un »

Je peux vous citer mon propre exemple, j'ai écrit un petit article sur un ton léger pour 24 jours de Web, nommé Les id sont nos amis. Même si j'étais et je suis toujours content de l'avoir écrit et du message qu'il véhicule, avant qu'il ne soit publié, je pensais en toute honnêteté qu'il n'aurait aucun commentaire et qu'il trouverait un écho assez anecdotique.

Je me suis bien trompé : pas mal de réactions, ça a suscité quelques débats et interrogations, et l'auteur de 24 jours de Web m'indique qu'il a reçu plus d'un millier de visites. Et ce n'est vraiment pas le seul exemple que j'ai en tête. Et si vous ne le faites pas pour les autres, faites-le pour vous.

« Je ne suis peut-être pas le mieux placé pour en parler »

Peut-être avant, mais vous le serez une fois que vous en aurez parlé. Et sinon, qui va le faire ? :)

« Je n'ai pas le temps »

De deux choses l'une :

  • soit vous êtes totalement la tête sous l'eau, vous bossez 26 heures par jour et vous n'en voyez pas la fin. Effectivement, là, vous n'avez vraiment pas le temps.
  • ou vous êtes dans une situation plus équilibrée, vous avez le temps de regarder un film ou une série, vous avez un sommeil correct, etc.

Dans le second cas, il ne faut pas dire « Je n'ai pas le temps », mais plutôt « ce n'est pas ma priorité ». Seulement c'est parfois délicat à dire ou à reconnaître (et ce même s'il n'y a aucun jugement de valeur à avoir sur les priorités d'autres personnes).

Si cela vous pose un problème de conscience, j'ai trouvé une solution qui marche bien, je consacre un nombre d'heures à un sujet chaque semaine. Par exemple, j'adore Openweb, je veux y consacrer du temps mais sans pour autant ne faire plus que cela (j'ai d'autres centres d'intérêt). Dans ce cas, j'ai juste fait le choix de dire : je fais disparaitre des choses moins importantes pour libérer du temps. Personnellement, j'ai réduit la télé et le rapport instantané que j'avais avec certaines séries (ça attendra qu'elles passent sur les chaines françaises), j'ai supprimé quelques bricoles qui m'apportaient peu. Cela me permet de libérer quelques heures dans la semaine, et c'est parfait. Pas un grand effort à fournir en somme pour libérer du temps.

« Je n'écris pas bien »

Faites-vous relire. Et l'écriture, c'est comme la course à pied, ça s'améliore avec l'entrainement. Et on s'en fout, l'important ce sont les idées, le traitement viendra après. L'idée peut exister sans la forme, la forme n'existe pas sans l'idée.

Bref

Comme disait Jean-Claude Dusse, pour conclure : si vous vous posez la question d'écrire sur un sujet, n'hésitez plus, faites-le !

Créatif et rigoureux : de la pure magie d'intégrateur (le 07/12/2012)

Je vois souvent dans le métier une opposition assez nette entre les graphistes et les développeurs/intégrateurs. Chacun a ses clichés (plus ou moins vrais, vous pouvez troller en commentaire si le coeur vous en dit) :

  • Les designers/graphistes sont créatifs, ils ont les idées, mais ils sont bordéliques et inconstants quand il s'agit de dealer avec les intégrateurs.
  • Les intégrateurs sont plutôt rigoureux (à la limite du psycho-rigide pour certains), hyper-carrés, mais pas très créatifs. Du coup, ils sont souvent taxés de brider les graphistes et de leur gueuler dessus en permanence.

En fait, on présente souvent un antagonisme entre ces deux métiers, et c'est entretenu par une espèce de mirage dans l'inconscient collectif, à croire qu'un bon designer/graphiste ne peut pas être rigoureux dans son métier (ils apprécieront), et à croire qu'un intégrateur n'a aucune créativité (idem, ils apprécieront).

Quand je discute avec des débutants, ce mirage est toujours bien ancré, combien de fois ai-je entendu : «  je veux créer, donc je veux être graphiste. » ou « je suis nul en créativité, je préfère intégrer ».

Alors, je suis désolé, je vais tuer un mythe : être designer/graphiste demande une sacrée dose de rigueur, et être intégrateur demande également une créativité parfois exac