da scritch net works - Mot-clé - html

cpu-audio.js enfin en 7.0

Da Scritch — 2021-04-28T06:51:00+02:00

Ouais, j'avais d'autres billets techniques sur le même sujet, mais là, j'ai avancé sur le code plutôt que l'explication de texte ;)
Webdev

Commençons par un exemple avec une émission sur le son :

(S'il n'a pas encore démarré, un peu de patience, sinon le lecteur reste utilisable, c'est de la dégradation élégante)

Cela faisait un peu de temps que je n'avais pas donné de nouvelles de mon lecteur audio. Alors que pourtant j'avais écrit toute une série de billets à son sujet :

cpu-audio.js vient de passer en version 7.0. Le player audio de l'émission CPU en WebComponent a été revu en profondeur, avec moult corrections et notamment l'arrivée des thèmes graphiques en plus du système simple de configuration

L'idée d'origine de cette bibliothèque était de pouvoir donner une URL qui puisse pointer à un instant précis d'un audio dans une page web. Car le standard existe mais n'est pas implémenté par les principaux navigateurs. Or il est bien utile pour les émissions de 5h30. Et quitte à le faire, le faire avec un minimum de dépendances et un maximum de souplesse.

Par la suite, les principales API sont arrivées pour enfin stabiliser les Web-components, ce qi m'a permis d'enfin réaliser une bibliothèque javascript isolée, transportable, agnostique, petite (sous les 50ko) et toujours en vanilla.

J'ai donc déjà longuement raconté sur ce blog les démarches de conception qui m'ont permis d'y arriver et de le faire dans la licence GPL.

J'avais besoin de refondre complètement la bibliothèque pour la rendre plus maintenable, plus facile aussi pour que n'importe quel dev ou intégrateur front s'en empare. Il est ainsi possible de créer des thèmes graphiques sans toucher au code JS, ce dernier ayant même une tolérance d'implémentation.

Il reste toujours les idées qu'on avait jeté au début, que je ne réaliserai jamais seul mais que j'espère donner une base saine pour construire :

des thèmes plus aboutis et jolis
une WebExtension pour lire n'importe quel audio tranquillement
créer des playlist décentralisées pour montrer que le web est beau car remixable
créer des commentaires à la SoundCloud/MixCloud mais décentralisés
des outils encore plus poussés que l'éditeur de chapitre
ajouter un spectrogramme via add-on
Étendre pour l'utiliser aussi sur de la vidéo

Et n'hésitez pas à me contacter si vous avez besoin d'aide.

J'ai encore beaucoup de choses à dire, mais surtout beaucoup à remercier ; d'abord toute l'équipe de l'émission et ceux de la radio qui font qu'on reste très impertinents depuis 1981. Avec une pensée spéciale pour le Tetalab et Mixart Myrys où nous avions enregistré de nombreuses émissions et dans une panade noire.

Ensuite ceux qui m'ont aidé spécialement sur ce projet de code :

Thomas Parisot pour le standard Media Fragment, qui permet à ce player de créer des liens hypertextes temporels ;
Loïc Gerbaud pour des corrections ;
Guillaume Lemoine qui m'a bien aidé avec du prêt de matos au début ;
Benoît Salles et Michel Poulain pour les tests, Gabi Boyer pour m'avoir passé un iPhone SE, téléphone qui est certes toujours mis à jour, mais Apple n'arrive vraiment pas à tenir Safari aux standards.
@mariejulien pour m'avoir donné envie de ré-écrire un CONTRIBUTING.md plus accessible
Christophe Porteneuve de Delicious Insights, un ami et un formateur JS qui m'a donné un magistral coup de pied au cul. Ses formations JS sont de sérieux cadeaux pour les devs webs.
scombat qui a écrit une intégration minimale de cpu-audio.js dans React
Éric Daspet pour ses précieuses remarques sur la documentation

N'hésitez pas à le faire connaitre, si vous avez un projet audio dans le web qui nécessite un lecteur.

Retravailler un lecteur web audio dans les petites largeurs

Da Scritch — 2019-06-05T07:32:00+02:00

Parce que les chiffres ne mentent pas : nous sommes de plus en plus nombreux à avoir un smartphone. (Essayez de prononcer cette phrase d'un ton concerné en public sans rire, ça vous fera l'après-midi)
Webdev

Cet article est dans la série consacrée au développement de la bibliothèque cpu-audio.js et documente les affres de sa version 6.

Mettre de l'audio dans le web n'a pas été simple
Reconstruire son lecteur audio pour le web (sur la version 5)
Retravailler un lecteur web audio dans les petites largeurs
Le blues du Web Share (english version)
Deux couleurs bizarres en CSS
cpu-audio.js enfin en 7.0
Tout-terrain WebVTT pour de l'audio
Dichotomie entre podcast et web sur l'audience

Et cet article est long, car comme le premier, je tiens à documenter ma démarche. Et comme j'aborderais plusieurs thématiques, vous aurez plusieurs épisodes. Vous pouvez tester l'application ici ↓ dans sa version de travail en cours.

Pour lire ce billet, il est conseiller d'aller sur mon site dascritch.net. Si vous lisez ce texte, c'est que probablement vous n'y êtes pas.

Avant d'entrer dans le vif du sujet, je rappelle que je ne suis pas web-designer, mais un développeur d'applications web et que je n'ai qu'un minimum de bagages pour construire un web component faisant office de player audio. Que ce composant a été écrit afin de l'intégrer dans un site d'une émission radio, ceci dans le but de lier et de lire des sonores qui durent en moyenne une bonne heure. La plus longue des émissions de CPU dure 5h30, un exemple NSFW qui montre à l'extrême les contraintes.

J'ai qu'un minimum de culture en design, mais j'ai eu la chance d'avoir fréquenté depuis 2000 des designers web (des vrais) qui étaient exigeants et m'ont beaucoup appris à ~~coups de b~~ la dure.

Petits dans la poche, gros dans les contraintes

L'un des gros gros chantiers évolutifs de CPU-Audio.js pour cette version fut la mise au point d'une interface confortable pour les smartphones.

Par rapport à ceux dits de bureau, on a sur ce type d'ordinateurs deux problématiques supplémentaires :

Un écran nettement plus petit,
un dispositif de pointage bien moins précis.

Voici la comparaison avec mon web component sur mon propre blog dans sa version de Janvier 2019, tel que vu sur un ordinateur de bureau (1920 px de large) avec un pointeur de souris.

la souris a une précision au pixel et son curseur ne cache pas tout l'environnement immédiat

… et le même composant, mais vu sur un smartphone d'une largeur de 320 px (virtuels, résolution typique d'un iPhone 5 en mode portrait, en fait l'écran fait dans les 1080 pixels physiques, mais expliquer les dppx dans la foulée serait trop long).
Le disque rouge est une simulation l'espace d'appui d'un gros doigt normal prompt à la bourde.

environ 50 pixels de diamètre, sans compter l'imprécision dû au virage effectué par votre bus à une certaine vitesse

Il existe un certain nombre de règles de bonnes pratiques pour y palier :

mobile first : On présente en priorité les éléments les plus importants de la fonctionnalité voulue ;
On aménage des zones cliquables suffisamment grandes et espacées ;
Le composant doit s'afficher très très vite, et donc avoir un code très léger avec le moins de dépendances possibles, si possible aucune ;
Responsive Web Design (RWD) : On ajoute l'accessoire quand on a plus de largeur disponible.

J'étais déjà parti avec un design liquide (ou fluide ou coulant) pour être le plus confortable, dans l'idée que mon composant puisse être intégré quels que soient les choix sur le design du layout des sites. Pour la légèreté, je tente de maintenir le code compilé sous les 50 kB, même s'il a pris 20% de poids en plus entre la v5 et la v6.

Mais il y avait encore quelques manques dans la version 5 pour que mon player audio soit vraiment confortable à utiliser sur smartphones.

Et déjà un premier souci avec les CSS media queries breakpoints

Car effectivement, il est possible de cibler des définitions CSS par des règles media queries qui s'activent en fonction de la largeur de l'écran ou de la finesse de l'afficheur physique (via l'unité de ratio dppx évoquée plus haut entre parenthèses, oui je sais, ça fait lourd à lire tous ces apartés). Pour les définitions en fonction de la largeur d'écran, cela revient à définir un breakpoint, une dimension critique d'une media query ou le chouïa qui fait changer l'aspect, des propriétés peuvent changer plus ou moins radicalement. J'ai choisi cette stratégie car c'est la plus pratique pour une conception en design liquide.

Mais il y a un gros problème dans l'idée de concevoir un web component installable partout : Il n'est pas possible d'appliquer lesdites règles en fonction de l'espace disponible dans un élément parent en pur CSS. C'est faisable mais avec des polyfill en javascript particulièrement lourdingues.

Je m'explique : Si l'écran est d'une largeur d'écran de bureau (vers 2000 et au-delàààààà), mais qu'un intégrateur installe mon composant sur un site, dans une gouttière qui fait 320 pixels de large, l'aspect de mon composant ne sera pas adapté car les boutons seront trop gros, et par exemple pour les titres, ils ne rentreront pas dedans.
Autre exemple : supposons que la mise en forme du site est entre un bloc principal à largeur variable, et une colonne à taille fixe de 200 pixels. Si le lecteur est dans le bloc principal, il serait logique qu'il change de forme pour une largeur inférieure à 320 pixels quand la fenêtre tombe en dessous de 520 pixels…

@media (max-width: 320px) {
    dommage, hein ?
}

Tommy Hodgins a fait une proposition auprès du W3C qui me serait super utile et totalement indiquée dans mon cas : Les CSS Element Queries qui proposent de définir en breakpoints la dimension d'un élément englobant.

La proposition CSS Element Queries permettrait de définir des règles appliquées si la largeur de l'écran fait 320 pixels ou moins ou que l'élément #conteneur a une largeur de 320 pixels ou moins :

@media (max-width: 320px) , @element #conteneur and (max-width: 320px) {
    J'en rêve, mais j'en rêve ! (c'est déjà dans mon code)
}

Hélas, cette proposition ne semble pas être au programme du CSS working group du W3C et donc pas près d'être implémentée nativement. Et évidemment, tout polyfill est lourd, même avec l'arrivée prochaine de l'API ResizeObserver.
Pourquoi ? Imaginez que vous chargez 4 ou 5 web components dans la même philosophie de conception, qui chacune lance son polyfill… Ouais, évitez le CSS-in-JS dans ce cas-là : vous risquez de ne plus rien contrôler correctement.

Autre frustration : il n'est pas possible d'utiliser des variables CSS pour définir des breakpoints, des changements de résolutions significatifs. Dans mon projet, le style est défini est dans une CSS locale, tandis que les variables reparamétrables par l'utilisateur sont dans une CSS globale, normalement, toutes les variables qui intéressent les graphistes sont dans la CSS globale… sauf ce qui défini les breakpoints !
C'est pour ça qu'ils sont codés en dur à 640 px, 480 px et 320 px.

Pourquoi une telle frustration ? En fait, ce manque est intentionnel : les variables sont justement variables selon les usages et leur définition, pouvant vite devenir un casse-tête pour les navigateurs web à recalculer dans un media query.

Et on pourrait aussi avoir des… maladresses genre :

--largeur : 1000px;
@media (max-width: var(--largeur)) {
    --largeur : 500px;
}

Do not want comme on dit dans le secteur.

Il tourne actuellement au W3C une autre proposition, définir des constantes CSS d'environnement définissant des informations pour l'ensemble du document. Ces constantes peuvent être définies par le système hôte, le navigateur web ou dans la CSS (et on imagine, idéalement sur le sélecteur :root).
À leur appel en lecture, ces constantes peuvent prendre un paramètre optionnel qui sert de fallback. L'invariance de la valeur représentée en quelqu'endroit du DOM le rend alors utilisable pour définir un breakpoint.

Là aussi l'idée est géniale, et le dossier semble un poil plus avancé, l'implémentation native étant satisfaisante pour être jugée comme générale l'année prochaine. On a la lecture, pas encore la déclaration

:root {
    --largeur : 1000px;
}

@media (max-width: env(--largeur, 320px)) {
    ooooh ouuuuiiiii
}

breakpoint sur un élément, comme on peut, comme un porc

Dans l'immédiat, je suis arrivé à le faire sur le mini-site de présentation du projet grâce à une astuce limite du crade à faire dégainer l'Inspecteur Dirty Hacky

Pièce à conviction n°1, faites entrer l'accusé

J'ai utilisé des <iframe>. Et pourquoi est-ce crade ?

Il faut créer une ressource indépendant pour chaque instance appelée, ici 3 documents html de plus ;
Évidemment, il faut recharger le script cpu-audio.js, donc le charger et l'instancier 4 fois pour cette page ;
Idem pour la feuille de style ;
On instancie 3 objets DOM de page en plus, bouffant de la RAM ;
C'est impossible de faire un design liquide propre dedans sans pleurer sur certains cas ;
Et on perd des fonctionnalités comme :
- le lien avec media-fragment (c'est très très con : c'est la fonction qui a motivé l'écriture de mon script),
- l'anti-cacophonie (un seul sonore lu à la fois dans la page),
- les playlists,
- et le contrôleur global (le bouton ▸︎play dans l'encart à fond noir à gauche sur ma capture) ne voit pas ces instances.

Je ne l'ai utilisé que pour faire la démo des largeurs. Ne faites jamais ça chez vous, les enfants !

Le problème de la navigation fine sur une largeur fine

Revenons sur les problèmes fonctionnels de mon web component sur les ordinateurs de poche.

Le manque qui me semblait le plus gênant était de revenir en arrière d'une phrase dans un sonore d'une heure. Le lecteur peut interpréter certaines touches comme ← et →, mais aucun smartphone n'a de clavier avec des touches fléchées depuis la mort du dernier Blackberry à touches physiques. Reste le positionnement au doigt ~~levé~~ posé, et donc la navigation dite fine s'y révèle imprécise.
Améliorer ma time-line était indispensable.

Une time-line c'est ÇA :

N'oublions pas que mon web component est prévu pour être utilisé dans une page web, et qu'il a été conçu en design liquide, donc si on passe son smartphone de l'orientation portrait à paysage et que sa dimension n'est pas fixée, le visiteur gagne autant de largeur, donc de précision pour naviguer dans la time-line. Mais la prise en main me semblait toujours insuffisante.

Dans pratiquement tous les lecteurs audios, la time-line est à la fois un indicateur et un élément de contrôle auquel on s'attend pour tout média audio ou vidéo d'une certaine durée. Elle indique à la fois la position en cours de lecture, la partie préchargée immédiatement lisible sans avoir à attendre, et permet à l'auditeur de sauter à une position. Plus cette time-line est large, plus le positionnement au pointeur par l'utilisateur est précis. Plus le sonore est long, moins ce positionnement est précis.
Je ne saurais dater son apparition, mais il me semble qu'elle est apparue avec le premier Quicktime (1991) en tant qu'adaptation de la time-line des éditeurs de sons qui présentaient la forme d'onde du sonore en cours d'édition, et ceci depuis les années 1970s.

Avant de me remettre ~~au redesign~~ à la refactorisation de mon lecteur, et vu que moi-même je ne suis pas parfait, j'ai regardé ailleurs et essayé des applications natives sur smartphones. En me concentrant sur son comportement lors du passage d'une disposition portrait à paysage. Certains choix y sont surprenants, et pas uniquement sur les durées affichées (passée, restante ou totale).

Quatre exemples de time-line en natif

L'application Youtube l'agrandi aussi en passant en mode paysage. En mode portrait, elle utilise le maximum de largeur d'écran.

Mais pourquoi ai-je pris une vidéo d'Eugène Lawn ?

HenryMP, héritier d'un excellent player audio (Appollo sur Cyanogen OS), se montre encore moins aisé : si on décide de basculer l'écran du mode portrait au paysage.... la time-line n'est pas plus grande pour autant. Frustrant.

J'imagine que la logique y est plus d'écouter des singles d'environ 4 minutes et de mieux voir la pochette de l'album, pas forcément de naviguer dans un DJ-set de 2 heures ou dans une conférence au Collège de France

Note : Cette application n'est plus maintenue depuis 4 ans, elle est présentée ici pour l'exemple.

Podcast Addict, qui est une excellente application orientée podcast (merci Capitaine Évidence), a quelques manques dans sa prise en main pour naviguer. En gros, si l'émission n'est pas chapitrée ou n'a pas de liens explicatifs dans son texte descriptif, on pointe sur la time-line puis on utilise des boutons pour se positionner plus finement.

Dans la vue présentation d'un épisode, basculer en mode paysage étend la time-line.

Sauf que, petite inconsistance : sur la vue propre à un sonore, en mode paysage, la time-line est… plus courte. Oups.

Je termine ce tour avec une application très particulière, celle de Les Croissants, qui propose une matinale par modules, composée en fonction de vos centres d'intérêts.
(Manque de bol : La société Les Croissants a fermé la veille de la publication programmée de cet article. Pas d'bol.)

En haut, vous avez une vue sur l'ensemble de l'émission dans une time-line globale, et au milieu, chaque chapitre a sa propre barre de défilement, mais à la verticale, sur la gauche.

On a certes une redite de la time-line entre la vue totale (horizontale) et celle par chapitre, mais ce qui est nettement plus notable et bizarre est que la progression des time-lines des chapitres n'est pas constante, puisque la hauteur de cet élément est fixe, mais que la durée peut varier (entre 3mn et 7mn). Mais ces bizarreries sont plus une signature et non gênantes à l'usage.

On a vu quelques outils de consultation destinés au public, j'aimerais vous présenter un outil professionnel de lecture de média :

Le jog shuttle du Beta SP

Le magnétoscope Beta SP de Sony est avec sa cassette Betacam un engin de chantier de l'audiovisuel des années 1980s-2000s. Costaud, robuste, très cher et indispensable pour toute production de qualité. La première fois que j'ai pu en utiliser un, j'ai immédiatement adoré l'usage du bouton jog shuttle ! Oui, même en pleine frustrajoie.

Vous ne pouvez pas louper le jog shuttle : c'est ce gros bouton rond noir proéminent idéalement placé sous votre main droite sur le panneau inférieur.
Photo non créditée sur Pinterest

Dans le mode shuttle en pause ou pendant la lecture, vous pivotez le bouton rotatif, la bande défile alors vers l'avant ou l'arrière plus ou moins rapidement, entre le ralenti et l'accélération ×8 en fonction de l'angle de rotation. Relâchez, le bouton rotatif revient en position neutre.
Mais si vous cliquez sur le bouton, le ressort est désactivé, et le mode de fonctionnement passe en jog, où vous faites défiler les images en tournant le bouton. Comme si vous bougiez manuellement la bobine de la bande sur un bon vieux reel-to-reel ReVox, ou que vous caliez un disque vinyle (étant à Radio <FMR>, j'ai voulu être DJ). Ce qui permet un calage à l'image près, indispensable pour le monteur vidéo.

On a donc un outil de calage qui passe d'un clic d'un positionnement grossier au calage à l'image élémentaire. La prise en main est incroyablement intuitive une fois qu'elle vous a été montrée.

À 1m42s, une petite démo avec un lecteur XDCam portable, mais il s'agit d'un bouton combo (voir le paragraphe suivant). Pour 60€, je vous aurais intégré cette vidéo éclairante avec un vrai BetaSP. Et y'a celle-là montrant un autre point de vue.

À noter que certains magnétoscopes très haut de gamme des années 1990s avaient un combo bouton central shuttle rotatif et pourtour jog à ressort. Peut-être fut-il utile pour monter les Sept Premiers Bitomans.

Depuis, la génération Betacam est passée.
Au prix de la bande, les BetaSP sont devenus des pièces de musée, et on monte au clavier et au trackpad. Mais le jog shuttle est resté dans cette micro-culture industrielle pour ceux qui ont connu avant l'informatisation totale du banc de montage. Pas mal de monteurs vidéos, qui ont un jog shuttle wheel sur leur poste de montage. Les control knob prévus pour Windows 10 tels le Surface Dial s'en approchent mais n'ont pas le retour haptique avec ressort, si intuitif.

Et dans les logiciels ?
Il me semble qu'une version (bêta ?) de QuickTime Pro avait tenté à la fin des années 1990s d'ajouter dans un panneau de son interface une molette de défilement… qui ressemblait trop furieusement au jog-dial, une molette crantée cliquable que Sony incrustait absolument partout. Et quand je dis partout, ce jog-dial a été la signature des produits Sony de la fin des années 1990s : sur les baladeurs Mini-Discs (utile pour titrer un MD, mais dont l'usage bourrait de saletés l'intérieur de mon MZ-R35), le téléphone Z5 (celui de l'An 2000) ou encore les PDA Clié. Il me semble que les designers de Sony se soient retenus pour les télés et playstations.
Apple a retiré l'interface avant un procès prévisible, ou peut-être en souvenir de l'échec de la molette de volume du Quicktime 4 ?

Mais je m'égare dans mes rushes.
Alors l'idée d'un jog shuttle dial est super, mais non-intuitive pour le visiteur lambda d'un site à qui il faudrait lui expliquer le manuel, or, rappelons la règle d'or du design réussi :

S'il faut expliquer le fonctionnement d'une interface grand public
⇒ c'est que ton design est loupé
⇒ F.B.I. Fausse Bonne Idée.

Accessoirement, elle est aussi un poil lourd à écrire from scratch. Pas infaisable, juste lourd. Et prendrait de la place sur l'écran.

Maintenant qu'on a fait ce petit tour de l'État de l'Art pour se mettre en appétit, passons à l'action !

Supprimer les bords ronds

Un truc totalement idiot où j'ai pêché par coquetterie : j'ai mis des bords ronds au début et à la fin de la time-line. En fait, cela rend moins facile de viser le début d'un sonore (oui, les recherches avancées ont prouvé que statistiquement, nous cherchons plus souvent à revenir au début qu'à aller dans les 5 dernières secondes d'une émission d'une heure). Donc tant pis pour les bords ronds, on revient au bon vieux rectangle.

Je vais prendre exemple sur mon propre blog, avec une de mes émissions actuelles qui ne dure qu'une heure : Sur 320 pixels de large, le web component fait 291 pixels de large à cause de la mise en page.

La time-line fait 195 pixels de large, les bords ronds en bouffent 2×4 pixels.

Je me suis appliqué la Règle des Cinq Pourquois pour chercher la vraie raison de ma décision graphique. Alors, euuuuuh… les bords ronds sont moins agressifs, parce qu'il y a trop de rectangles, Steve Jobs a inventé les rectangles arrondis… Au final, j'avais mis ces bords ronds sans aucune raison valable.

Bon ben, on vire !

À 18 secondes par pixels pour un sonore d'une heure, cela faisait 2'27" rabotées par pure coquetterie, et non pas par design.

Parce que, oui, il faut se rappeler que le design n'est pas qu'une question de couleurs et de formes mais surtout de praticité pour tous. Faire du décor ne suffit pas et n'est pas du design.

Agrandir la time-line

Passer de la souris à la précision d'un pixel sur un écran de 52 cm de large (1920 px soit 96 dpi) à un écran tactile de 8 cm de large (1080 px soit 400 dpi, plus qu'un album de bd !) avec la précision d'un gros pouce… inutile de dire que sur smartphones, une telle précision peut entrainer autant de dégâts collatéraux qu'une guerre chirurgicale. Et cette imprécision devient de plus en plus problématique quand on a mis en ligne un podcast qui dure une heure (voire 5h30), rendant encore plus problématique un bête besoin comme celui de revenir d'une minute en arrière dans une interview.

Il était évident que garder la time-line contrainte entre les deux boutons ▸︎play/⏸︎pause et action n'était pas une super idée graphique : Je perdais environ 2×48 px en largeur disponible, ce qui n'est pas négligeable quand on a moins de 320 px de large.

Pour reprendre l'exemple de mon blog, la time-line fait 195 pixels de large soit 18 secondes par pixel pour un sonore d'une heure

Il m'a fallu jouer une fugue en CSS mineure pour que cette barre bascule en-dessous de ces boutons pour gagner en largeur. Comme je voulais aussi garder l'indication des longueurs de chapitres (les lignes noires discontinues), je considère qu'elles deviennent transparentes aux actions pointeurs en dessous d'une certaine largeur d'écran, pour éviter un appui malheureux dessus.
Oui, si c'est conditionné avec un breakpoint, c'est que j'ai utilisé une propriété CSS qui influe les interactions du curseur avec des éléments. Cette propriété qui tient de la magie vaudou mérite votre attention : pointer-events : none;

Retravaillée la time-line fait toute la largeur du web component, 291 pixels de large soit 12,4 secondes par pixel pour un sonore d'une heure.
Vous noterez aussi que les deux boutons ont perdu un poil de hauteur et que la place laissée au timecode dans la liste des chapitres est devenue élastique ce qui permet de gagner des lignes dès la première entrée.

Comme l'utilité d'une telle finesse est moins pressante sur de plus grandes largeurs, qui correspondent en général à des ordinateurs avec des dispositifs de pointages plus précis (le doigt occupant une fraction moins importante de l'écran, ou ayant un stylet voire la souris), la disposition entre les deux boutons revient au-delà d'une certaine largeur.

Deviner où l'on vise d'un coup d'œil

On le voit sur la capture au-dessus, j'ai fait apparaitre sous la time-line une indication pointilliste des chapitres. Elle existait depuis un an, mais uniquement dans les grandes largeurs. Celle-ci est désormais aussi visible sur les petites largeurs, mais il n'est pas dit que tous les utilisateurs de mon script vont penser à renseigner un manifeste de chapitrage au format WebVTT. On en reparlera dans un chapitre à part, j'ai beaucoup à dire sur le sujet ; si cela vous intéresse, vous pouvez déjà vous amuser avec mon éditeur en ligne.

Pour aider visuellement à sa navigation, j'ai ajouté une fonctionnalité qui permet d'afficher l'enveloppe du son. Il s'agit d'une option, disponible via l'attribut waveform="".

Pour des raisons évidentes de performances, l'image de l'enveloppe en question est pré-générée au moment de la compression du sonore en PÀD (prêt à diffuser). Afin de tester la fonction et de donner un exemple fonctionnel dans ma doc, j'ai profité d'une fonction méconnue de l'utilitaire en ligne de commande sox, véritable couteau suisse pour travailler du son avec le minimum de dépendances. Un script qu'on trouve souvent dans des chaines de publication audio industrialisées sur des serveurs de rendus.
Anecdote : j'ai utilisé cet outil en 2004 pour faire des messages de répondeurs personnalisé par prénoms et pour biper des ringback tones. Un script de 20 lignes permettait à des ingés son de gagner des journées de travail en supprimant des silences superflus, concaténant des sons et normalisant le rendu.
L'option pour générer ce graphique est spectrogram. Par rapport à la traditionnelle vue de la courbe, elle permet de mieux distinguer les voix et les musiques sur une très petite hauteur, ici 8 pixels de haut. C'est pas toujours vrai et c'est surtout un choix personnel, il est susceptible d'évoluer plus tard.

Comparaison entre une vue d'une forme d'onde (en haut, niveau sonore en ordonnée) et un spectrogramme (en bas, fréquence en ordonnée) de l'émission 🍺 Bière

Naviguer plus finement

Reprenons les problématiques de la navigation sur smartphone : L'écran est tout petit, et notre doigt est démesurément gros pour essayer de se placer précisément. Et donc nous avons toujours le problème de la navigation fine, quand on veut revenir de quelques secondes en arrière.

J'étais parti sur l'idée qu'un appui long sur ma time-line est une tentative pour se placer finement. Ben oui, ça m'arrivait plusieurs fois d'appuyer à un endroit du player, puis de bouger délicatement mon doigt en le faisant pivoter, tout en approchant de près mon smartphone et en tirant la langue afin de contrebalancer le manque de précision… ce qui me rendait totalement idiot dans le bus.

AHEM !
Une requête pour afficher la navigation alternative, nous disions.

L'idée étant évidemment de suivre l'analogie UX de la blague de l'interface : s'il faut l'expliquer à l'utilisateur, c'est que ton interface n'est pas bonne.

j'ai mis des boutons, juste pour voir si la requête en question marchait. Mais j'avais pas forcément idée de le garder. J'avais même réfléchi à zoomer la time-line avec des mouvements genre pinch-in/pinch-out (pincer/étendre), mais je me suis rendu compte que ce n'était ni intuitif, ni pratique, voire complètement frustrant sur iOS : le pinch-out à une certaine ampleur peut vous sortir du navigateur web pour aller vers un sélecteur d'applications (Un parti-pris d'Apple très con et totalement frustrant quand votre appli utilise le pinch, justement).
Et comme mon web component a aussi pour objectif d'être repris, hors de question de risquer une contradiction parce que le site hôte a déjà son usage du pinch-in/pinch-out.

Donc finalement, supposer qu'un appui long sur la time-line est une demande explicite de l'utilisateur vers plus de précision, me semble pas trop erroné.

Mettre des boutons ⏮ ◂◂◂ ◂◂ ▸︎▸︎ ▸︎▸︎▸︎ semblait pas trop pourri.

J'ai dit semblait, une fois de plus, je dis pas avoir raison.

La mauvaise surprise du temps

J'ai tenté de mettre une entrée de temps, utilisant un champ <input type="time">, yep, icelui : . Après tout, les smartphones ont en général un excellent sélecteur de date et d'heure.

Le sélecteur d'heure d'Android, extrait de l'excellent article sur <input type="time"> de Mozilla Developer Network.
Une chouette analogie aux vieilles horloges à aiguilles, compréhensible parce que des équipes de Google (comme Microsoft, Apple et Mozilla) ont investi des milliers d'heures sur ce problème à votre place.

Sauf qu'il y avait un os ! J'ai pris un sélecteur d'heure, faute d'avoir un sélecteur en HTML5 pour exprimer une durée. Ce qui veut dire que… l'heure peut afficher au format 12 heures avec une locale américaine ! Et impossible de le localiser de force avec un attribut comme lang="fr".

Tiens, si je règle un champ time à 0h1mn23s, dans Firefox avec l'interface paramétrée en Français, vous aurez :

bon là, vous m'comprenez si vous me lisez en Français

Et avec l'interface paramétrée en Anglais Américain (en-US), qui est l'interface par défaut pour beaucoup de monde :

Tempora mori, tempora mundis recorda comme dirait le roi de Loth,
ça veut pas du tout dire la même chose, et surtout pas une durée

En fait, il n'y a pas de règle uniforme du comportement basculant entre les affichages en 12 h ou 24 h : certains navigateurs se basent sur la langue de leur interface, d'autres celles du système d'exploitation (heureusement, le DOM expose au javascript une représentation unique au format 24 heures, idem pour l'envoi d'un formulaire à un serveur, sinon je serais devenu fou).

J'avais le même souci dans mon éditeur de chapitrage puisqu'il utilisait le même type de champ. Pour le résoudre, il suffirait d'écrire un polyfill d'affichage agissant sur un champ <input type="time"> caché… ouaip, ça craint.
Ben j'ai écrit une mécanique différente.

En résumé, pour un champ natif de durée, il manque :

soit un type de champ <input> pour gérer la durée, une décision à prendre au niveau du W3C ;
soit le respect de la propriété lang="" dans les contrôles, ce qui peut être implémenté par les navigateurs mais peut poser des soucis d'UX ;
soit la possibilité de styliser un champ <input type="time"> dans sa présentation et son interface pour basculer entre les modes 12 et 24 heures, une décision qui peut être testée par les navigateurs par une propriété CSS préfixée expérimentale avant standardisation.

Néanmoins, je n'étais pas satisfait de cette navigation alternative.

L'enfer des petits détails

La barre de navigation alternative apparaît quand on clique plus de 400 ms : au-delà, Chrome sur Android et surtout l'affreux iOS considèrent que l'utilisateur veut une autre fonction, genre sélectionner du texte. Alors qu'on a déjà désactivé la sélection de texte. Le pire étant iOS qui va lancer un sélecteur d'application qui n'a rien à voir.
À noter que pour les ordinateurs de bureau, il est possible de l'afficher en faisant un clic droit à la souris sur la time-line (la fonction normale est disponible en combinaison avec ⇧Shift).

Voilà où en était mon brouillon, que j'ai finalement gardé. Ici en faisant abstraction du champ input type="time" pour ne pas plus vous distraire avec…

Pour être le plus standard possible, j'ai créé des boutons ◂◂ et ▸︎▸︎, calqués sur les appuis de touches ← et → tels qu'interprétés dans mon web component (faisant des sauts de 5 secondes, durée paramétrable) , ainsi que ⏮ sur la touche ↖. Puis j'ai ajouté ◂◂◂ et ▸︎▸︎▸︎, qui font comme ◂◂ et ▸︎▸︎, mais répétés 4 fois.

J'ai tenté ce sélecteur, mais design liquide oblige, j'étais obligé de cacher certains boutons qui me semblaient moins utiles, d'un usage moins fréquent. notamment ◂◂, un choix décidé grâce à une technique scientifique de pifométrie, ce qui une fois de plus, vaut ce qu'il vaut et que je n'ai pas forcément eu raison.

Dans la plus petite largeur recommandée (320 px de large, soit un iPhone 5 en portrait), on a l'essentiel utilisable

Mais ces boutons étaient câblés sur l'événement click (clic de souris). Vous cliquez, l'avance se fera. Une fois. Ça serait cool de rajouter la répétition, non ? Tant que vous ne relâchez pas, l'action continue au même rythme.

Donc au final, j'ai dû écrire un gestionnaire d'appui-long/répétition pour 4 boutons, avec un mode de fonctionnement proche d'un clavier de bureau : Une première attente (400 ms) avant de commencer à répéter, puis répéter l'action sur des intervalles nettement plus courts (100 ms). Des durées paramétrables par le site, car je déteste les constantes magiques au milieu du code, et pour qu'un webmaster qui n'aime pas les réglages puisse faire mumuse avec, comme ça, il se sentira plus fort.
Ouarf.

Peut-être pouvait-on faire une accélération de l'avancée en fonction du temps qu'on appuie sur le bouton, mais je ne suis pas sûr qu'un tel système à accélération progressive soit pratique.

Bref…

In fine, j'ai travaillé les fonctionnalités sur mon lecteur audio pour qu'il soit aussi pratique à utiliser sur un ordinateur de bureau que sur smartphone.

Je ne garantis rien. Maintenant reste le plus difficile : en faire autant sur la navigation fine pour l'accessibilité.

En plus de la navigation fine, il faudrait aussi parler du chapitrage audio, mais le sujet est très vaste, il interviendra après qu'on ait parlé de Web Share...

Reconstruire son lecteur audio pour le web

Da Scritch — 2018-11-06T12:25:00+01:00

Ou comment j'ai bricolé longtemps les pages web pour mettre du son, les différents players que j'ai essayé, que j'ai écrit et la livraison du petit dernier.
Webdev

Cet article est dans la série consacrée au développement de la bibliothèque cpu-audio.js et documente les affres de ses versions 5 et 6.. Dans cette série :

Mettre de l'audio dans le web n'a pas été simple
Reconstruire son lecteur audio pour le web (sur la version 5)
Retravailler un lecteur web audio dans les petites largeurs
Le blues du Web Share (english version)
Deux couleurs bizarres en CSS
cpu-audio.js enfin en 7.0
Tout-terrain WebVTT pour de l'audio
Dichotomie entre podcast et web sur l'audience

TL;DR Trop Long; Vous ne lirez pas ?

La démo du player :

Si vous voyez ce texte, c'est que le lecteur ne s'est pas lancé, très probablement parce que vous ne lisez pas mon billet depuis mon blog
Sauter au milieu de ce sonore d'un simple lien, même en dehors de la page
Une autre démo avec les chapitres
Le repository github du player
Le site de démonstration du player, n'hésitez pas à tester le configurateur et l'édition de chapitres
et tout ça pour une émission radio

Et si on étendait ce tag ?

Mais revenons au moment où on a déclaré deux sources de sons, ce qui permettait le support par la totalité des navigateurs web supportant l'<audio>.
Ladite balise ne venait pas seule : Elle était accompagnée d'une API très riche, permettant de suivre l'état de chargement du fichier, de changer le volume sonore, de connaitre la position actuelle de lecture et même de changer la vitesse de restitution ! En fait, rien ne vous interdit de ne pas afficher l'interface native et de construire la votre derrière.

L'occasion était trop belle : je changeais d'émission radio en lançant CPU et je lançais plusieurs projets liés en parallèle. L'idée étant que les contenus produits pour l'émission radio servent comme cas d'usage pour les projets afférents. L'occasion d'explorer ce que l'on pouvait explorer en production et en ~~consommation~~ écoute d'émissions radio sur internet et de jouer avec les spécificités d'une émission radio par rapport à un pure player audio du web.

Un de mes projets était de reconstruire un player audio au look un poil passe-partout, partageable/réutilisable avec d'autres sites, pour proposer des idées comme une playlist partageable.

Pointer dans le temps

En fait, l'écriture de ce player était une évolution d'une autre bibliothèque de mon crû : j'interceptais déjà les liens d'une page pour lier vers un moment dans le sonore d'une page, ce qui est bigrement utile…

Un menu contextuel de Firefox, généré par ma bibliothèque timecodejs, permettant de récupérer une URL pointant sur le moment du sonore pointé par le menu contextuel.

…et prévu par un standard du W3C depuis 2009, les media fragments !

L'idée est simple : transposer dans le hash d'une url le principe de segmentation des paramètres query par un &, et utiliser les paires clé=valeurs, les valeurs étant séparées par des virgules clé=valeur,valeur. Le hash n'est interprété que par le logiciel client (le navigateur web), charge à lui d'optimiser finement la requête avec le serveur, en utilisant les requêtes partielles Content-Range, répondues par des HTTP 206 Partial Content.
Et, beauté de la dégradation élégante, si le hash n'est pas compris… il est simplement ignoré.

Il existe de multitudes de fragment de média possibles. Ainsi, si je veux afficher un bout de carré d'une grande image à partir des coordonnées (80,160) sur un carré de 80×80, je ferais un <img src="https://dascritch.net/post/2018/11/06/image.jpg#xywh=80,160,80,80" alt="" />.
Vous trouvez qu'il y a comme une similarité avec les sprites ? L'idée partait justement de là.
On retrouve des stratégies équivalentes pour les polices de caractère mais qui n'étaient pas décrites dans ce standard-là.

Soyons honnêtes : À ce jour, en natif, seules les vidéos sont considérées.
Et le standard n'a jamais été implémenté pour les sonores dans les pages, considérant que le chargement fragmenté via les requêtes Content-Range pouvait y palier. (Tu parles ! ça marche efficacement que pour les sonores encodés en CBR, sinon on tourne à la pifométrie, mais j'en causerais dans un autre billet).

Car oui, trop longtemps on a oublié que le web a été conçu pour lier entre eux des documents d'une manière pérenne, que le web sémantique va de pair avec l'espace d'adressage où est le document et qui existe à l'intérieur du document, et qu'on a la technologie pour lier à des chapitres (si on pense à utiliser le nommage id="", j'ai écrit un outil pour vous aider)…

Importance du web documentaire : les hyperliens autour de la page de garde de Wikipédia

…mais si ces technologies sont très bien implémentées pour du texte, voire des vues pour certaines PWA, il n'y avait à l'époque malheureusement aucune implémentation propre et standardisée dans les navigateurs pour lier un sonore ou une vidéo embarqué dans une page à un moment très précis via une URL. Ce qui pose de sacrés soucis, par exemple quand on veut pointer une phrase dans une émission de 4 heures. Oui, je fais parfois des émissions avec 4 heures de parlotte, et elles sont très très bien.

Il existe néanmoins des implémentations de la notation t=<secondes> sur des médias au sein d'une page sur des sites à très fort traffic :

Vimeo et Soundcloud l'utilisent dans la partie hashtag, comme je le fais (…#t=10) ;
Youtube et Peertube en sont très proches mais l'information temporelle est placée dans les paramètres de l'URL (…?t=10), charge aux serveurs de vous envoyer une page directement au bon repère, et qui impose d'intercepter les modifications d'URL plutôt que seulement ceux du hash (exemple dans les chapitres de cette vidéo de Ça Fait Écho).

À noter que plusieurs notations sont autorisées pour le timecode en valeur de t= : notamment le nombre de secondes, ou la notation SMPTE HH:MM:SS.FFF très utilisée dans le monde professionnel (avec des frames d'une durée d'un millième de secondes).

Bonus que j'ai ajouté dans ma petite bibliothèque : quand on quitte une page avec un tel sonore par inadvertance (lien, formulaire, chat qui saute sur Alt et F4), ben si je fais ←back, ou si la page s'ouvre avec exactement le même sonore, j'aimerais bien qu'il reprenne exactement là où je suis. Ça serait la moindre des choses, non ?

Voilà qui m'a écrit…

Mes règles de base :

être toujours au plus près des standards, pour ne plus revivre l'enfer d'avant leur respect, et avoir un code qui restera fonctionnel dans le temps ;
minimalisme de code, pas de bibliothèques/frameworks externes (JS ou CSS), si on s'appuie sur un framework, vous ne pourrez jamais virer cette béquille et elle vous posera des problèmes à l'avenir ;
si besoin de code externe, appliquer les polyfill les plus proches de ces mêmes standards ;
pouvoir le développer avec le moins d'outils tiers (genre Bower, Less, etc...). Tout au plus des linters et des compresseurs JS et CSS ;
par dégradation élégante, pouvoir fonctionner sur des vieux tromblons de plus de 2 ans au minimum ;
que le lecteur natif du navigateur web puisse fonctionner et s'afficher même si votre javascript est complètement planté, car si votre site de contenus ne présente aucun contenu sans javascript, c'est qu'il est sémantiquement mauvais ;
un design liquide, pour s'adapter à tous les styles et largeurs ;
assurer un minimum d'accessibilité ;
rappeler l'importance d'un bon web sémantique.

Le papa player

Alors tout ça, je l'ai braficotté dans mon coin dans une petite bibliothèque javascript. Elle faisait ça :

Le player “ondemiroir” dans deux résolutions

code javascript avec l'excellent framework vanilla js
en liquid reponsive web-design,
avec i18n (internationalization, baille ze ouéy excuse my french)
affichage de pochette
ajout de lien vers la page canonique du sonore
navigation au clavier dans le sonore
reprise à la volée si on a quitté le sonore (donc la page) inopinément au même endroit (très utile quand on lit la dernière émission dans la home du site CPU.pm, puis qu'on clique sur la page de l'émission)
partage sur des réseaux sociaux avec le moment en cours
avoir un contrôleur cloné pour l'entête fixé (qui apparait quand le lecteur principal n'est pas visible)

À l'usage, notre player est réellement devenu un outil très utile pour dérusher les émissions, et pas que pour moi, mais aussi pour les journalistes qui ont participé à l'émission.

Mais le code de génération est assez.. dégueu...
En plus, je voulais tenter un système de playlist centralisée (pour tous les podcasts de la radio), qui impliquait de charger la lib JS depuis un domaine précis. Très grosse erreur.

je voulais rafraichir mon projet avec les Web Components. En fait, je voulais le faire avec dès 2015, quand je lançais l'émission, sauf qu'à ce moment-là, l'ensemble Web Component n'est pas encore gravé dans le marbre et les implémentations parfois masquées dans les navigateurs.

Les WC étaient fermés de l'intérieur

J'ai jamais vu une discussion sur les WC qui n'est pas partie en couille
(@myagoo, in slack communautés-toulouse )

Bon, on va pas troller, on va y aller simplement :

L'idée des Web Components est dans l'air depuis 2012. Il a commencé par être implémenté dans Chrome avant que le standard soit correctement validé. Puis nous eûmes soit des implémentations avec leurs propres API et concepts (ReactJS, VueJS,…) , soit des polyfills plus ou moins proches des standards (Polymer,…)
Le choix d'un polyfill au plus proche des standards me semblait évident, et je voulais utiliser le génial Bosonic de mon camarade Raphael Rougeron.

Si je radiographiais le code source d'un Web Component, je verrais ça :

<template>
  <style>
    …
  </style>
  …
</template>

<script>
  class TonElement extends HTMLElement {
      constructor() {
      }
      …
  }
  window.customElements.define('ton-element', TonElement);
</script>

Un motif HTML, un stylage CSS et une classe javascript pour piloter le module.
Dans l'idée de départ, le tout était enregistré dans un document .html importé dans ta page via <link rel="import" href="https://dascritch.net/post/2018/11/06/webcomponent.html" />

Et dans ta page, tu l'appelles comme ça :

<ton-element>
</ton-element>

Le choix de nommage est assez malin car le standard impose dans le nom d'utiliser un -, afin de ne pas se marcher sur les pieds ultérieurement.

Les Web Components sont formidables

Et en quoi ils vont nous être bigrement utiles :

ils présentent un ensemble d'API totalement standardisées par le W3C, dans 10 ans, le code tournera encore ;
ils obligent à concevoir un design atomique : réfléchir non plus en terme d'aspect global d'une page comme on le fait pour un site, mais en briques élémentaires, indépendantes, donc réutilisables ailleurs ;
ils peuvent se passer des frameworks de rendus pour les intégrer ; fini la panique de mettre à jour bloated code, ranger ReactJS à côté de MooTools dans l'étagère du fond ;
il sont isolés du reste de la page avec le Shadow DOM, une API document fragment d'un DocumentRoot (comme une iframe) appelée shadowRoot. L'isolation peut être stricte, mais laisse la possibilité de discuter par des points d'entrée ;
ils n'ont plus besoin de CSS reset pour nettoyer les règles venant de la CSS du site, ou de filtrer des événements sur des tagNames. À noter que les variables CSS3 passent, on s'en servira ;
leur insertion est simple au possible, à condition que le développeur pense à la dégradation élégante ;
mais ils peuvent inserer des éléments déclarés dans leur code d'appel HTML, ce qui permet une dégradation élégante si le Web Component n'est pas fonctionnel ;
ils disposent d'une mécanique standard pour l'inclusion et la suppression d'une instance d'un Web Component dans une page, déjà cablée sur tout manipulation d'éléments, ce qui facilite la gestion mémoire sur les Single Page Application ;
comme la version de javascript imposée accepte les extensions de classes, on peut construire des héritages de web-elements.

En fait, un Web Component, vous vous en serviez sûrement des prototypes via <input type="date">, <input type="range">, le tandem <summary>/<details> ou encore <video controls> , car les implémentations natives de ces composants dans les navigateurs datent à peu près de cette période.

Dégradation élégante

Pour moi, il me semblait absolument évident que le script doit être capable de ne pas fonctionner sans bloquer l'accès au contenu publié. Il y a milles et unes raisons que cela arrive :

La bibliothèque ne se charge pas,
votre code est bugué,
le navigateur client n'a pas toute les fonctionnalités nécessaires,
le visiteur bloque volontairement tout javascript pour des raisons hygiéniques,
le web n'est pas parcouru que par des navigateurs webs connus et le Google-bot.

Il faut donc que le lecteur audio natif reste fonctionnel, mais qu'il soit facilement capturé et caché par le Web Component. Et ses propriétés d'invocations sont extrêmement intéressantes :

<cpu-audio>
  <audio controls>
  </audio>
</cpu-audio>

Sur un navigateur ancien, la balise du Web Component sera toujours interprétée, mais le navigateur ignorera sa signification sémantique. En fait, elle serait vue par un <div> que ce serait pareil. C'est un fonctionnement d'intégration par fallback qui a toujours été prôné par le W3C et qui est utilisé dans les exemples plus haut avec <object> et <audio>, et c'est ce qui permet de garder un minimum de support le temps que les navigateurs clients soient renouvelés.
La balise <audio> que j'y ai mis serait du coup intégrée normalement, et son interface graphique normalement affichée, invoquée via l'attribut controls.

Les précédentes opérations ont lieu sur un navigateur moderne, sauf que la classe TonElement liée à la balise sera invoquée via sa méthode constructor() ; méthode qui insère le shadowDom (l'interface graphique), lance les interactions avec cette interface, et retire l'attribut controls de la balise <audio> pour la cacher.

J'avais néanmoins besoin, même si les API Web Components n'étaient pas supportés, qu'un navigateur daté profite néanmoins de la fonctionnalité d'adressage dans le temps du sonore. Ce qui voulait dire avoir une vraie politique de développement en amélioration progressive et pour cela, il fallait isoler du code ce qui concerne purement cet adressage et la gestion de l'interface graphique. Bon, dans les faits, tout n'est pas proprement isolé, mais l'essentiel y est.

Brique-olons

Chrome avait une excellente démonstration du ShadowDOM v0 mais avait des petites craditudes derrières. Il y avait aussi la possibilité d'insérer des variables dynamiques dans la CSS et le HTML, mais l'implémentation jouait avec des rafraichissement continués en écrivant directement dans le .innerHTML, avec donc d'énormes soucis de performances. Mozilla avait sa propre implémentation, les X-Tags, qui n'étaient vraiment pas facile à prendre en main. Enfin bref, fallait implémenter de façon très expérimentale, des fois pas accessible par défaut, car on allait changer pas mal de paradigmes sur lesquels les navigateurs web étaient construits.

Puis virent les BONNES nouvelles : ShadowDOM v1 fut enfin finalisé. Chrome en fit une implémentation propre. Et l'équipe de Google proposa un polyfill, WebComponentsJS, qui était vraiment au plus proche du standard des Web Components, à se demander quel intérêt on a encore à utiliser le framework Polymer.
Bon en fait, WebComponentsJS n'est pas parfait, notamment il crée des javascript inline pour émuler les HTML import et les inclusions… une réponse extrêmement mauvaise en terme de sécurité car on doit alors réduire les Content Security Policies de son site, et pour moi, réduire les fonctions de sécurité est une ligne rouge.

Il fallait attendre patiemment les implémentations natives qui n'allaient pas tarder. Le navigateur multi-plateforme qui était apparemment le plus en retard était Firefox, l'implémentation native était là, activable par des paramètres cachés car pas encore considérée comme suffisamment solide. En fait, Mozilla attendait une stabilisation de l'API, dont leur implémentation était cachée jusqu'à Firefox 63 quand il était en version nightly.

Étonnement, Safari était assez vite prêt, Apple n'étant pas pressé de rendre le web aussi puissant que les applications natives.
Il reste le support de Edge, qui habituellement adapte bien plus vite les standards que Safari. Je tiens de source sûre que Microsoft le proposera pas pour la fin de l'année, car le support demande une refacto assez conséquente.

L'interface

Voici un exemple de l'interface en mode large :

Euh.... vous savez quoi ? Vaut mieux vous le montrer en vrai :

Pas de bol, votre navigateur ne supporte pas les Web Components

Mais voici une capture écran de ce que vous manquez :

On voit le panneau horizontal standard avec la pochette, le bouton lecture/pause, le titre qui renvoie à la page canonique, le temps écoulé, la timeline (où l'appui long entraine l'apparition du mode de navigation smartphone) et le bouton d'action.
Et le panneau optionnel de chapitrage.

Pour ceux qui ne peuvent l'afficher, ou pour les archivistes du XXIII^ème siècle, deux captures du player, une en largeur normale, et une autre dans une largeur de smartphone. Captures de début octobre 2018.

La puissance du chapitrage

Dans les fonctions qui sont hyper-pratiques et donc je suis fier, il y a le support des chapitres.

Normalement, il existe la possibilité de chapitrer un fichier mp3/mp4 MAIS chaque format audio a sa propre spécification et il n'est pas dit que si un sonore a deux sources différentes, qu'elles soient raccord sur les déclarations de chapitres, et donc d'avoir des données uniformes. De même, un des problèmes les plus récurrents est que celui qui a encodé le média ne pense pas toujours à vérifier que les métadonnées soient en début de fichier, car certains encodeurs partent dans l'idée que vous voulez faire du vrai stream, sans début identifiable, et donc le chapitre déclaré au moment où il apparait (c'est comme ça que les radios transposent les informations contextuelles RadioText du RDS dans leur stream mp3 sur le net).

Un sac de nœuds ? Non. Il se trouve qu'il existe un standard du W3C (dérivé des fichiers de sous-titres .srt , donc... issus du piratage, mais chut) : Les WebVTT. Et pour les exploiter, une API standard parfaitement supportée par les navigateurs peut prévenir quand on entre ou sort d'un de ces chapitres.
Il est probable que vous les ayez déjà vus à l'œuvre dans une vidéo… sauf qu'ils sont quasi jamais utilisés en audio, et donc sans interface utilisateur dans le navigateur… Jusqu'à maintenant.
Pour des raisons éditoriales, l'interface des chapitres est activée sur mon blog, pas sur le site de CPU.

De même, le player intègre désormais une fonction playlist dans une page : si une balise termine sa lecture, la lecture d'une suivante peut démarrer dans la foulée.

Ce que j'ai appris

Plein de méthodes du DOM que je ne connaissais pas, et qui m'ont facilité le travail. Une fois de plus, on ne relit jamais assez les standards du W3C, sachant qu'ils font actuellement plusieurs milliers de pages. Une de mes découvertes, par exemple, me permet de gérer le blocage des lectures de son automatiques introduits depuis Avril 2018, document.hasFocus() m'évite de lancer une lecture trop tôt et d'attendre que le visiteur a cliqué dans la vue de ma page.

Plein d'événements et autres subtilités sur des balises HTML que je croyais connaitre. Comme quoi, on ne relit jamais assez les documentations officielles.

Utiliser les variables CSS3 pour pouvoir customiser l'aspect du Web Component de l'extérieur sans avoir à bricoler le code ou mettre trop d'attributs HTML dans la balise d'appel.

Modifier du balisage sur les billets descriptifs de 95 émissions de CPU.
J'avais prévu de cacher la liste des chapitres si elle a été chargée et affichée par le lecteur. À la main, et plus d'une fois, pour finalement ne pas m'en servir de suite. Quand vous allez dans vos toilettes avec votre laptop, y'a comme un signe. J'ai tiré une croix pour les 390 Supplément-Week-End et tous les autres émissions archivées. Moralité : toujours déclarer des id="" par blocs reproductibles suffisamment tôt et s'y tenir, ce qui aurait permit d'automatiser ces modifs triviales.

Garder une séparation entre les sources HTML, feuilles de style et javascript.
L'implémentation de HTML Imports restera dans les limbes pour des raisons de sécurité. Heureusement, on peut faire sans, tout en gardant la possibilité de séparer le <template>, le <style> et le javascript : Pour cela, j'ai écrit un make.sh maison crade, certes, mais il fait le taf avec un minimum d'environnement, et je vous invite à participer, il est dans le repo de ce projet.

Avoir attendu 2018 pour développer la nouvelle version m'a permis de bénéficier de :

API enfin stabilisées et réellement standardisés ;
meilleur support de ces standards dans les navigateurs ;
par amélioration progressive, pouvoir toucher 50% d'audience ayant un navigateur à jour de moins de 6 mois (et avoir au moins deux navigateurs cibles multiplateformes) ;
n'utiliser aucun polyfill ;
modulariser pour avoir un fonctionnement possible sans le support des Web Components ;
usage des variables CSS3, ce qui permet de pouvoir personnaliser plus facilement le player ;
relevé deux bugs dans Firefox, 1476302 et 1476301 (yay !) ;
passer mes serveurs en HTTP2, mais sans le mode push, faute d'un support correct du mode HTTP 206 Partial content ou de pouvoir désactiver le push en fonction du type-mime ;
résoudre le problème posé par le blocage des autoplays sonores par Chrome (mars 2018) et Firefox (Octobre 2018).
étoffer la doc et proposer un outil de configuration live et d'édition des chapitres

Je me suis néanmoins planté

J'ai perdu un contributeur (désolé NerOcrO) car j'ai repris le projet ondemiroir-player de zéro à grands coups de copiés-collés et je l'ai surtout annoncé beaucoup trop tôt avant de pouvoir prendre des tiers. Cela a toujours été ma peur bleue quand j'ouvrais mon code, et le meilleur moyen est d'écrire suffisamment tôt une guideline des contributeurs pour que les règles soient posées d'entrée.

Il y a toujours ce souci insupportable qu'il est impossible d'essayer Safari sur iOS sans avoir un iPhone/iPad sous la main. Et d'expérience sur les interfaces, un émulateur peut être vraiment trompeur. J'en veux pour exemple le mode émulation d'appareils mobiles de Chrome à qui il manque des API telles que navigator.share. Alors payer pour un émulateur en ligne… ahem…

Et tout ça pour arriver trop vite, ayant quasi-terminé 6 mois avant de pouvoir lancer mon player :/ Les Web Components totalement fonctionnels sont arrivés dans Firefox 63 sorti officiellement le 23 Octobre, bien après Chrome et Safari, mais la version LTS (Long Term Support) actuelle est Firefox ESR 60 et Tails utilise une version encore plus vieille. Ce qui veut dire que Firefox ESR et Tails vont voir le nouveau lecteur dans sa version fallback un petit moment : pas avant juillet 2019.

Eh oui, le support à long terme est souvent synonyme de… long tail

Je terminerai par un tweet de @mariejulien (le gars des badges en tissu) lors de Paris Web

Question de @SkyNebula à #parisweb sur comment contribuer au libre quand on est designer, début de réponse "déjà tu peux voir si y'a un contributing md sur le repo…" 😅🤗

Vous le voyez toujours pas le problème ? Tout le monde n'utilise pas des outils de dev. Get over it. 😁

… ce qui m'a fait écrire le message d'accueil aux contributeurs extérieurs AUSSI pour les non-développeurs. Ne serait-ce pour les traductions, le graphisme, la doc, etc… Il faut que je complète encore pour expliquer comment faire sans avoir à installer d'outils via le site web de Github, notamment l'épineuse question des localisations (utiliser les .po ? un tableur ?).

Ce qui m'amène à…

L'avenir imaginé pour mon lecteur

Oui, je sais, il ne faut pas documenter le futur d'un produit. Néanmoins, voilà ce que j'aimerais faire :

avoir un vrai travail de design et d'accessibilité, et le documenter ;
résoudre le problème du positionnement fin en tactile sur smartphone : la barre de progression n'est bien qu'à la souris sur ordi, on compense la précision par le clavier. Aucun de ces dispositifs sont sur portable… j'ai prévu une interface avec des boutons en appui long sur la timeline (ou click droit à la souris), mais c'est pas encore ça ;
le support des règles CSS en fonction de la largeur d'un élément ; @element est prête pour moi, mais implémentée nulle part ;
plus de tests de non-régression ;
encore plus de tests ;
documenter encore plus ;
construire en même temps que la compilation des add-ons pour des CMS communs, notamment dotclear ;
créer des add-ons WebExtensions pour les navigateurs avec un ProtocolHandler custom pour basculer la lecture vers une application native (ex: VLC), et donc gérer les touches multimédias, ou les copier dans une clé USB à emporter ;
créer des fonctions décentralisées, sur le modèle (ou basées sur) mastodon :
- pouvoir faire des commentaires comme pour SoundCloud mais de façon décentralisée ;
- pouvoir créer des playlists et les partager de façon décentralisé. Par exemple, lier des émissions qui ont la même thématique comme « Tout est numérique » d'Olivier Tesquet sur France Inter, « Libre à vous» de l'April, le podcast « NoLimitSécu avec la mienne, et les annoter ;
générer des infos côté serveur comme
- un spectrogramme ;
- découper en MSE API ou MPEG-DASH (Dynamic Adaptive Streaming over HTTP), notamment pour sauter plus vite à des fragments (mais y'a des brevets dessus) puis les navigateurs Chrome et Safari se montrent très mauvais dans le chargement partiel d'un sonore via les requêtes Content-Range ;
- avoir un système de pige automatique des textes, pour l'accessibilité aux sourds et malentendants. Je remercie infiniment le travail des bénédictins de l'April, se faire transcrire par eux est un honneur. Accessoirement, cela aide aussi au référencement naturel (sifflote) ;
traduire ;
supporter les localisations RTL (Right To Left), notamment pour les langues arabes, hébreu,… ce qui signifie renverser les icones, la timeline et.... les touches fléchées du clavier, eh oui ;
supporter la vidéo aussi ;
rester sous les 100Ko.

« Mais pourquoi t'embêter ? y'a les apps natives maintenant ! »

Alors oui, malheureusement, la plupart des utilisateurs d'internet sont désormais clients d'applications mobiles…

mais pour moi, le Web n'est pas mort !
Il est ce que nous en ferons : du partage, de l'accès à tous et dans le <a href="https://dascritch.net/post/2018/11/06/"> tous les lier. Il peut même remplacer fortement ces applications, éviter la fragmentation des langages et des frameworks, et conforter ses missions premières via les hyperliens et la décentralisation,…
Qu'on puisse mettre un marque page à un endroit, partager ce lien et donc le contexte à ses amis, dans ses billets de blogs, et retrouver le contexte si la page est publique bien plus tard (à condition que le site existe et qu'il a maintenu son plan d'adressage).

C'est un peu ce que je fais inconsciemment avec ce petit bout de code, qui ne sert qu'à une chose : rendre les sonores plus navigables et plus partageables.

L'étape suivant a été de travailler dans les petites largeurs.

Mettre de l'audio dans le web n'a pas été simple

Da Scritch — 2018-11-06T12:24:00+01:00

…alors autant raconter ce qui m'a mené à écrire un lecteur audio pour une page web.
Webdev

Cet article est dans la série consacrée au développement de la bibliothèque cpu-audio.js et documente les affres de ses versions 5 et 6..

Dans cette série :

Mettre de l'audio dans le web n'a pas été simple
Reconstruire son lecteur audio pour le web
Retravailler un lecteur web audio dans les petites largeurs
Le blues du Web Share (english version)
Deux couleurs bizarres en CSS
cpu-audio.js enfin en 7.0
Tout-terrain WebVTT pour de l'audio
Dichotomie entre podcast et web sur l'audience

J'ai eu une chance incroyable

L'année où j'ai eu mon bac, en 1993, je suis entré dans une radio associative, Radio <FMR>, au moment où elle faisait encore une audience d'importance, supérieure aux 3%. On entendait cette radio de punks dans les bars, les friperies et les magasins de disques. Je pensais faire le désespoir de mes parents, et à mon grand désarroi, j'ai appris que mon père avait bricolé le premier bloc émetteur.
Au même moment sortait Netscape, le premier navigateur web construit par un opérateur commercial. J'ai touché aux deux le même automne, inutile de vous dire que mes passions furent partagées entre les deux, et que j'ai souvent croisé les deux : j'ai toujours cherché comment un message était transmit pour l'adapter au mieux du support, voire hacker les deux.

Les premières pages web de Radio <FMR> sont datées de 1996. Et les sons furent mis en ligne quelques mois plus tard. Dès 1999, on a eu la première diffusion stream de notre antenne, qui était… un piratage amical.

Mais pour les sons à écouter, au début, nous n'avions que Quicktime (1991), Window Media (1991), Real Player (1995) et WinAmp (1997).

Real player 8 plus, un joli bloatware lancé pour écouter un sonore de 15 secondes

Et encore… au début, ces logiciels ne s'intégraient pas dans le navigateur, il fallait télécharger les sonores complètement, puis lancer le bon logiciel pour les lire, en le devinant depuis l'extension du nom de fichier ou le type-mime déclaré par le serveur. Des fois, ces logiciels de lecture devaient charger des drivers d'imports complémentaires car le format était plus ésotérique que prévu.
Et quand ces logiciels furent inclus dans le navigateur, les plugins n'étaient pas forcément disponibles partout : les versions manquaient selon les systèmes d'exploitations ou l'API plugin exposée par les navigateurs, et les méthodes d'appels en HTML variaient entre Internet Explorer et Netscape, les autres navigateurs hésitaient entre les deux camps. Inutile de vous dire que y'avait de quoi s'arracher les cheveux en tant que dev et en tant que surfeur des internets. D'où les sites web optimisés exclusivement pour Windows 98 avec Internet Explorer.

Je ressors cette image insoutenable, j'espère qu'aucune tentative de suicide n'aura lieu cette fois-ci.

Là où je tresse des lauriers à… Flash !

En 1996, Macromedia eu le bon ton de faire évoluer son logiciel Flash de l'animation de CD-Rom à un plugin navigateur pour presque toutes les plateformes. le plugin Flash devint vite extrêmement populaire, il était même installé par défaut avec presque tous les navigateurs dès 1999. Et pour la fonction qui nous intéresse, sa version 6 en 2002 a apporté la faculté de lire des fichiers .mp3 via des adresses http://.

Malgré l'urticaire que pouvait déjà provoquer Flash chez certains, cette fonctionnalité devint importante pour ceux qui cherchaient à intégrer du son dans une page web car elle permettait de pouvoir intégrer en presque un seul snippet de code HTML un lecteur mp3 qui serait lisible de quasiment partout. Ce qui tombait bien car le mp3 était devenu un format ultra-populaire sur internet grâce au… piratage… ahem.
Rappelons que l'iPhone n'allait arriver qu'en 2007, et qu'à sa sortie, tout le monde était persuadé qu'Apple négociait et installerait Flash Lite.

Sauf que les premiers lecteurs de son en flash prêts-à−intégrer dans son site étaient particulièrement lourds avec plein d'effets graphiques, voire des bannières publicitaires.
Heureusement, gloire à toi, Dew, il a fait un player audio ultra-minimaliste, dewplayer (miroir).

Différentes configs du dewplayer, capturé d'un site archive (normal, mini, multi-sonore et rect)
Image zoomé × 2

Revoyons ses caractéristiques :

Un bouton start ▸︎, un pause ⏸︎, un stop ⏹︎
Une barre de temps, indiquant la progression de chargement et celle de lecture
Pas de titre
Pas de gestion de volume sonore ou de mute
Pas de gestion de vitesse de restitution
4 aspects différents possibles
Couleurs paramétrables
4121 octets

Tu cliques, il joue le sonore, et pis cé tou. Le génie est dans la simplicité.

Un lecteur flash avec la même inspiration minimaliste, les actions lecture ▸︎ et pause ⏸︎ confondus dans le même bouton.
Image zoomé × 2

Mais franchement, ce satané plugin Flash n'était qu'un pis-aller : un logiciel propriétaire lié à une boite au code source fermé, une sécurité pas au top dans son insertion dans les navigateurs, et les appels affreux en HTML en fonction du navigateur. Sur le site de ma précédente émission Supplément Week-End (2004-2014), j'avais écrit à grand coup de commentaires conditionnels un code HTML qui se voulait universel, marchant aussi bien avec MSIE (Microsoft Internet Explorer) que le reste :

<!--[if IE]>
  <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0">
<![endif]-->
<!--[if !IE]> <-->
  <object type="application/x-shockwave-flash" data="https://dascritch.net/post/2018/11/06//interface/player_mp3.swf">
<!--> <![endif]-->
    <param name="src" value="/interface/player_mp3.swf" />
    <param name="FlashVars" value="mp3=zou.mp3&loadingcolor=304b5f&bgcolor1=ffffff&bgcolor2=e6f4ff&buttoncolor=304b5f&buttonovercolor=000077&slidercolor1=6096BF&slidercolor2=304b5f&sliderovercolor=000077" />
    <param name="wmode" value="transparent" />
    … (fallback pour ceux qui gèrent pas)
</object>

Oui, assez gerbant.

Entre les crises de nerfs, les mises à jour différentes entre plateformes et l'arrogance de Macromedia puis d'Adobe, cette solution ne pouvait qu'être provisoire.

Hosanna, résonnent les <audio> au plus haut du W3C !

Enfin arriva en 2009 la balise <audio> dans des navigateurs web en support natif. Facile, bien plus facile, kawaii ♥♥♥ :

<audio src="https://dascritch.net/post/2018/11/06/zou.wav" controls>
   … (fallback pour ceux qui ne gèrent pas)
</audio>

Mais c'était trop facile : parmi les manques dans la description des balises <audio> et <video>, aucun format de média n'a été imposé par le W3C aux navigateurs web, ni même un support minimum.

Code code code codecs : entre libres et payants

Pourquoi le W3C et le WHATWG ont-ils laissé un tel flou ?
Il se trouve que nous connaissions déjà une situation similaire avec les balises <img> figées dans un status quo empirique : les formats de compression les meilleurs sont payants, ils pouvaient rançonner le web tout neuf. Et évidemment, certains ayants-droits ont un peu poussé leur stratégie du coucou pour essorer la poule aux œufs d'or. Coucous donc à MPEG-LA, Microsoft (VC1), Apple et bien d'autres.
Une situation qui va devenir crispante pour certains webmestres qui doivent se soucier de la légalité de leur site (ceux qui pensent à l'achat d'art, et à créditer correctement les logiciels), jonglant entre les implémentations universellement utilisables et non-payantes (libres), sans trop dupliquer le même sonore.

Car oui, si vous ne le savez pas, jusqu'en 2017 l'usage du format mp3 (MPEG 1 layer III) pouvait vous être facturé, étant sous le coup de plusieurs brevets. C'est toujours le cas pour tout ce qui relève du MPEG-4, et d'ailleurs, si vous achetez une caméra professionnelle, il est écrit dans la doc que l'usage est strictement familial et qu'il vous faut acquérir une licence auprès du MPEG-LA pour tout usage à destination publique et/ou professionnelle.

Si si : Extrait du manuel de la caméra professionnelle Sony PXW-Z190, page 119 (garanti sans trucage) :

Ce produit est accordé sous licence, sous le couvert de la licence de portefeuille de brevets AVC pour une utilisation privée et non commerciale d’un consommateur pour :
(i) encoder des vidéos conformément à la norme AVC (AVC vidéo) et/ou
(ii) décoder des vidéos AVC encodées par un client dans le cadre d’une activité personnelle et non commerciale et/ou obtenues auprès d’un vendeur de vidéos sous licence AVC vidéo.
Aucune licence n’est attribuée ou ne doit être destinée pour tout autre usage. il est possible d’obtenir des informations complémentaires auprès de MPEG LA, L.L.C. voir http://www.mpegla.com

Pour une caméra professionnelle vendue à 4000 €, ne pas pouvoir utiliser les images tournées avec, ça fait un peu mal. BTW si vous souhaitez m'en offrir une pour les captations vidéos, je ne vous retiens pas :D...

Le MPEG-LA n'est pas un organisme de recherche, mais la structure juridique facturant l'usage des brevets liés aux formats MPEG, mis dans un pot commun par plusieurs sociétés. Il propose un ensemble de formules de facturations, allant du volume horaire de diffusion TV (cable, satellite et hertzien), au nombre de puces de décodage produites et au nombre de vues d'une vidéo sur le web. Pour donner une idée, Mozilla aurait dû payer à l'époque 9 millions $ par mois pour que Firefox puisse lire du MPEG sur les systèmes d'exploitations qui ne paient pas une licence, c'est à dire Linux, *BSD et consorts. Avec une telle somme, on pourrait financer d'autres projets logiciels.

D'où l'union improbable entre certains développeurs de navigateurs (Mozilla et Google en premiers) pour la conception commune de codecs libres. La reprise du Ogg Vorbis, le Ogg Theora puis spécifiquement conçus pour le web comme WebM, voire des implémentations en n'utilisant que des parties libérées de brevets (comme OpenH264 sponsorisé par Cisco pour que Firefox puisse faire de la visioconférence) et bien d'autres, etc… Sauf que ces licences libres ne sont pas disponibles sur tous les navigateurs et et manquent cruellement d'implémentations hardware. Les politiques commerciales des fondeurs de puces pour smartphones sont à blâmer.
Comme aujourd'hui, on parle surtout de son et vue la puissance de calcul de nos smartphones, on se contentera d'engueuler un navigateur web pour mobiles qui refuse d'inclure les formats libres populaires : Safari.

Évidemment, une telle fragmentation n'a pas aidé à voir se dégager un format de référence sans risque juridique pour ceux qui font des sites web. Donc on en vient à proposer au moins 2 formats de sonores différents.
Pro tip : proposez votre sonore encodé en mp4 ou ogg ou webm, puis terminez par une source encodée en mp3 traditionnel pour compléter le support, comme suit :

<audio controls>
  <source src="https://dascritch.net/post/2018/11/06/zou.ogg" type="audio/ogg; codecs=vorbis" />
  <source src="https://dascritch.net/post/2018/11/06/zou.mp3" type="audio/mpeg" />
</audio>

Et là, on a pu s'amuser quand il y eu un support correct des streams. Notamment avec le HLS aka Http live Streaming d'Apple, mais là aussi, il ne fut pas le seul protocole de streaming et il n'était pas supporté partout, avec des concurrents aussi clivants. À ce jour, l'API standard Media Source Extension n'est toujours pas supporté par les iTrucs d'Apple, malgré sa standardisation par le W3C.

Et tous ces soucis sont aussi survenus pour avec WebAudio par effet de Ric Hochet.
l'API WebAudio est l'équivalent fonctionnel de la balise <canvas> pour le graphisme : une feuille blanche adressable d'où l'on peut créer ou manipuler n'importe quel son.

Et la suite explique pourquoi et comment j'ai étendu la balise <audio>.

En 20 lignes pas plus : Le focus sur le champ de recherche

Da Scritch — 2018-08-17T13:42:00+02:00

Tout est une question d'accessibilité, donc de praticité de votre site web : moins y'a de clics, mieux c'est.
Webdev

Le site de mon émission CPU me demande parfois bien du temps pour résoudre des problèmes. Des problèmes d'interactions, des problèmes d'aspects ou d'accessibilité. Et pas uniquement parce que je fais ça sur mon temps de loisir, mais aussi parce qu'il vient après l'objectif de publication hebdo de mon émission, laquelle émission demande énormément de temps de préparation. Alors certes, je pourrais d'autant plus déléguer que je publie le source du thème Dotclear modifié, mais je fais aussi mes sites web pour acquérir de l'expérience, voire pour expérimenter.

Le problème dont je vais vous parler aujourd'hui, j'étais persuadé que j'allais le résoudre avec des déclarations HTML et du stylage CSS. Cela me semblait évident.

Et en fait, non.

Vous êtes ici

Dans le site de CPU, comme pour la plupart des sites à contenus, comporte 3 grandes régions fonctionnelles :

Il y a un layout de présentation générale, qui se veut minimaliste ;
une partie centrale de contenu, qui est l'intérêt de votre passage sur mon site, normalement ;) ;
et une partie secondaire de navigation censée permettre au visiteur de farfouiller dans le site si icelui l'intéresse (on peut toujours rêver).

Les 3 zones, dans une résolution confortable de bureau.

Cette partie secondaire se présente en sidebar si la largeur du navigateur le permet, sinon, elle est tout en bas de page, parce que je suis un fanatique du liquid responsive web-design. Peut-être que cette partie de navigation secondaire est trop présente et qu'il faille alléger son contenu, mais le débat n'est pas là.

La partie layout comporte un entête du site, un bandeau horizontal dont la hauteur est limité au logo de l'émission, et qui reste fixe en scrollant (merci display : sticky). Et comporte aussi une ligne de navigation rapide en 5 segments qui chapeaute le contenu et la navigation secondaire, laquelle disparait normalement en défilant.

Le header, la navigation rapide, et un exemple de contenu précédé de sa navigation contextuelle

La problématique

Ce qui m'intéresse, c'est mon lien Chercher, qui est un lien interne à la page et doit renvoyer sur le champ de recherche texte, lequel est situé dans la navigation secondaire. Et ce que je veux, c'est qu'en cliquant dessus, on voit le champ de recherche et qu'il aie le focus, pour qu'on n'aie plus qu'à rentrer des mots clés.

Je veux ça : Le champ de recherche visible, avec le focus.

Seulement, quand on cible un élément avec une ancre dans un lien, suivre celui-ci est censé faire ne sorte que l'élément entre dans la partie visible du viewport, et autant que possible, les navigateurs le mettront en haut à gauche. Et c'est pas le cas à cause de notre entête sticky qui cache le champ.

Du coup, on ne voit pas le champ texte. C'est ballot.

Note pour les experts : Cela aurait mérité de regarder comment se comporte la méthode Element.ScrollIntoView() et la toute nouvelle API IntersectionObserver.

Le laboratoire de Dexter

Donc, je me suis dit, tentons en appliquant une marge sur l'élément, pour qu'il sorte de sous le header.

#q { […] margin-top : 100px;; }

Sauf que : 1, c'est moche, le bouton OK se déforme, et 2, c'est inutile car le navigateur place l'élément sur le coin haut-gauche de son bord. excluant la marge.

du coup, le navigateur fera en sorte que le border soit collé en haut à gauche, mettant margin hors limites.

Donc, je me suis dit, appliquons les translations… pour voir…

#q { […] transform : translateY(200px); }

Ha ben oui, j'ai vu : ça fait effectivement le job, mais il faut alors appliquer tout un bazar pour décaler l'ensemble des autres éléments. On commence à entrer dans des crâderies qui feraient dégainer l'Inspecteur Dirty Hacky. Et il aurait raison tellement que ça pue.
Et puis, même si j'y serais arrivé, il faudrait toute la patience d'un vrai spécialiste CSS pour tout me remettre d'équerre. Donc, FBI : Fausse Bonne Idée.

Il existe une autre méthode, celle d'utiliser le pseudo-element :before, et du coup de lui appliquer une translation. Alors oui, cela marche, mais là aussi, j'ai un problème : le code n'a rien d'élégant à mes yeux.

Il y a un ensemble de propriétés CSS, scroll-snap points, qui semblaient intéressante, mais absolument pas pour ce que je voulais. L'idée est plus de faire une sorte de pagination et toucher le nirvâna du smooth-scrolling natif, ou, comme dans la démo du lien, faire des diapositives pour une présentation.
Note pour les experts, encore : le standard est encore en état de brouillon mais sa couverture commence à être correcte pour envisager de remplacer Reveal.JS EDIT : Cela a été fait par l'immense Nicolas Hoffmann. Je suis confus.

Le truc

Le truc n'est pas de cibler l'ancre de l'<input>, mais de son propre <label>, lequel a un padding-top confortable. Parce que vous avez été propre, et que vous avez positionné l'attribut for= pour lier le label à son champ, ce qui permet qu'en cliquant sur ce label, le champ prenne le focus clavier.

<form […]> <label for="q" id="search">Chercher avec un mot</label> <fieldset> <input type="search" id="q" name="q" /> <button type="submit">ok</button> </fieldset> </form>

Le problème, c'est qu'aucun navigateur ne songe à passer le focus au champ <input> quand vous ciblez son <label>, ce qui est un comble en manière d'accessibilité.

En fait, j'ai même remarqué que Firefox ne donnait même pas le focus quand on ciblait directement <input>, et j'en suis resté stupéfait J'ai ouvert un rapport bugzilla où vous trouverez un test-case.

Du coup, j'ai dû écrire un petit snippet javascript de ce qui pourrait bien être un polyfill pour une accessibilité évidente et mobile first.



function focus_on_label_moves_to_input() {
    let focused_on = document.getElementById(location.hash.substr(1));
    if  (focused_on === null) {
        return;
    }
    let focus_for = focused_on.getAttribute('for');
    if (focus_for === null) {
        return;
    }
    let new_target = document.getElementById(focus_for);
    if (new_target === null) {
        return;
    }
    new_target.focus();
}

window.addEventListener('hashchange', focus_on_label_moves_to_input);

Sous le capot

L'événement hashchange a lieu si vous changez la partie après le # dans l'adresse d'une page, donc sur une modification du fragment identifier. J'ai déjà fait joujou avec pour cibler un temps précis

Pour l'événement lancé, inutile de se référer à un objet event, la propriété location.hash vous donnera la partie hash (ou fragment) de votre URL, auquel on soustrait le premier caractère, forcément un # avec un .substr(1).

On va chercher l'élément cible du label, on voit s'il a un for="" avec la méthode .getAttribute('for').

À chaque étape où on frise l'incertitude, on vérifie qu'on a bien un objet et pas rien (null), sinon on return proprement, pour laisser la fonction suivante gérer l'événement. Je vous déconseille fortement de tout cacher derrière un try { } catch (e) { } : une telle structure doit rester exceptionnelle, sinon vous aurez vite d'immonde plats de spaghettis.

À la fin, on crée un événement focus en invoquant simplement la méthode .focus() de l'élément DOM du champ de recherche, parce que construire un trigger d'un focus, j'avais grave la flemme : il était 3h30 passées.

Moralité : ça fait le taf et le code n'est pas affreux.

C'était tout ce que je voulais. C'était si compliqué que ça ?

Bonus : le code est suffisament générique pour servir pour tout champ de formulaire : login, entrée de commentaire, formulaire d'adresse ou fishing de carte-bleue.

CPU lit le Bulletin de Santé d'Internet par Mozilla

Da Scritch — 2017-02-22T06:04:00+01:00

Dernier volet sur trois. Avec le sommaire complet vers les sonores découpés. Allez-y, vous pouvez reprendre pour une diffusion !
Radio

Ci-inclus l'émission release Ex0048 du programme CPU, diffusé le Jeudi 16/2 à 11h. Plus d'infos sur le site de l'émission.

Si vous suivez notre émission via un lecteur de flux et que celui-ci est encore lié à ce blog, je vous recommande de basculer votre abonnement vers le site de l'émission.
C'est gratuit, sans pub, ni spyware.

Durant nos 3 précédentes émissions, nous avons lu par chapitres la version 0.1 du Bulletin de Santé d'Internet, dossier passionnant écrit, traduit et édité par la Mozilla Foundation. Nous remercions amplement les salariés et bénévoles qui nous ont permis d'adapter leur précieux travail. Il nous a semblé important de le faire, même si nous avions déjà ouvert ou couvert plusieurs thématiques. Parce que le travail de cette communauté à l'échelle mondiale donnera toujours un éclairage très différent sur les sujets tels que nous aurions pu les traiter.

Découpage par chapitres

Texte en anglais	Texte en français	Version sonore
How do we measure Internet health?	Comment mesurer l'état de santé d'Internet ?	sonore
Open innovation / Innovation ouverte
How open is it ?	C'est ouvert ?	sonore
People powered phones within range	Déploiement d’un réseau mobile communautaire	sonore
Your selfie at the Eiffel Tower	Votre selfie devant la tour Eiffel	sonore
Digital inclusion / Inclusion numérique
Who is welcome online ?	Qui est le bienvenu en ligne ?	sonore
Inside an Internet shutdown	Vivre une coupure d'accès à Internet	sonore
When the Internet doesn’t speak your language	Lorsqu'Internet parle une autre langue	sonore
Decentralization / Décentralisation
Who controls the Internet ?	Qui contrôle Internet ?	sonore
Building a better blockchain	Construire une meilleure chaîne de blocs	sonore
Giving artists control of their music	Redonner aux artistes le contrôle de leur musique	sonore
Privacy and security / Vie privée et sécurité
Is it safe and secure ?	Est-ce sûr ?	sonore
Dutch pranksters turn surveillance into art	De la surveillance à la création artistique	sonore
Let’s Encrypt: Making the Web safer	Un Web plus sûr avec Let's Encrypt	sonore
Web literacy / Éducation à Internet
Who can succeed online ?	Qui peut réussir en ligne ?	sonore
Teaching encryption in Harlem	Enseigner le chiffrement à Harlem	sonore
Why don't more women code ?	Pourquoi coder n'attire pas plus de femmes ?	sonore

Chacune des rubriques a été découpée sans les parties musicales ou identification à notre programme. Les sonores présentés ci-dessus sont donc redistribués en licence Creative Commons, Share Alike, By Mozilla. Texte adapté et lu par l'équipe de CPU : Gael Cérez, Virginie Vandeville et DaScritch, avec les moyens techniques de Radio <FMR>

CPU Ex0046 Bonjour à toi, enfant du Futur Immédiat, comment va internet ?

Da Scritch — 2017-02-06T06:24:00+01:00

Ce texte est en introduction d'une série de trois émissions reprenant le Bulletin de Santé d'Internet v0.1 par la Mozilla Foundation.
Radio

Ceci est une partie du script de la release Ex0046 du programme CPU, diffusé le Jeudi 2/2 à 11h. Plus d'infos sur le site de l'émission.

Bonjour à toi, enfant du Futur Immédiat, et bonne année 2017, même si nous avons un peu de retard....
Nous t'avions promis de ne plus trop parler de politique... mais la promesse ne tenait que pour le domaine national. Car cette année, la plus grande puissance informatique et économique a intronisé comme président un DRH de télé-réalité. On ne va pas se priver de faire un jour un sujet sur les trolleurs.

Parallèlement, la Mozilla Foundation vient de terminer une mue qui a durée une année où sa sa communauté fut invitée à faire des choix. Un nouveau logo, mais surtout une mission revisitée : plutôt que vouloir mettre du web partout, jusqu'à écrire un OS de télé connectée, Mozilla va s'intéresser désormais à défendre des valeurs qui ont construit internet : le respect, l'échange, la neutralité, l'ouverture.

Soyez rassurés, ils font toujours Firefox...

Après avoir dévoilé son nouveau logo à la mi-Janvier, Mozilla Foundation vient de publier un bulletin de santé d'Internet, une initiative au code ouvert et libre visant à documenter et à analyser l’état de santé d’Internet en combinant des études provenant de multiples sources.
Nous, la rédaction de l'émission CPU, avons souhaité adapter radiophonique les 5 chapitres de ce rapport, car ce travail formidable est éclairant sur l'état technique, commercial, culturel et politique de notre planète.

Le Bulletin de santé d'internet 2017, version 0.1, est publié par Mozilla sous licence Creative Commons, avec attribution et partage dans les memes conditions.
À l'exception des parties musicales, cette émission est distribuée avec la même licence.
Cette émission est l'adaptation du texte original. Les vues et opinions exprimées dans notre programme sont de notre responsabilité et ne sont pas approuvées par Mozilla.

Firefox, l'invisible

Da Scritch — 2017-01-12T06:26:00+01:00

Est-ce que le navigateur Firefox n'aurait pas une audience sous-estimée ? Pourquoi ? Et si certains se contentaient de chiffres d'audience biaisés ?
Webdev

Mon discours sera un peu long. Il n'est pas étayé de chiffres, mais si quelqu'un veut étayer mon hypothèse, je lui donne les éléments qui lui permettrait de faire l'analyse. Seule condition, il faut les logs serveurs d'un site qui a une audience significative.

Parlons de la publicité sur le web

C'est un fait, la publicité est devenue incontrôlable, au point que même l'IAB, l'association des publicitaires sur internet, reconnait que ces abus sont devenus dangereux pour leur secteur économique :

La publicité est devenue trop distractive entre les animations, les couleurs criardes, le son voire la vidéo. Apparaissant des fois en plein milieu du contenu alors qu'on déroule un article, elle donne plus envie de fuir que de persévérer ;
Elle a pris ses aises avec le support et se substitue au contenu du site, avec des encarts en pop-over, pop-under, des vidéos en pre-roll… ;
Les publicités sont extrêmement lourdes à charger et à jouer. On frise parfois le délire avec des spots vidéos en HD pas optimisées, des polices de caractères dépassant la dizaine de Mo, un contenu 600 fois plus lourd que le reste de la page, impactant la réactivité du navigateur, les performances de l'ordinateur et l'autonomie de la batterie. Une machine qui peut faire tourner un FPS sans sourciller devient brusquement un veau en allant lire un article d'un quotidien ;
Le javascript des encarts est souvent de mauvaise qualité et peut faire planter la page hôte ;
Elles sont très indiscrètes, profilant le plus possible le visiteur, souvent au mépris des lois Européennes. Pourquoi les quotidiens français veulent connaître ma position géographique ? Sans compter une multitude de trackers posés par des réseaux sociaux, des régies publicitaires et autres ;
Les publicités posées s'affichent souvent avec retard, entrainant le phénomène de reflow d'une page. Outre leur poids, certaines régies travaillent avec un système d'enchères sur l'audience acquise, dans le but de vendre au plus cher l'écran du visiteur en fonction des intérêts qu'il a manifestés. Résultat : une pénalisation de la lecture par le délai d'attente, créant un effet de clignotement/déplacement de la mise en page ;
Elles sont devenues un vecteur d'attaque très prisé pour les virus et autres logiciels malicieux, et même indirectement les autres utilisateurs du réseau ! Le malvertising joue sur le fait que des sites réputés servent du code extérieur sans aucun contrôle, et même les experts sécurités peuvent se retrouver vecteurs d'infection malgré eux

Il ne faut donc pas s'étonner de la part importante de personnes qui surfent sur internet avec un bloqueur de publicités, pas uniquement pour avoir un ordinateur plus réactif, ni pour protéger un minimum sa vie privée, mais carrément pour se protéger les logiciels malveillants !

Un exemple de taxe à la performance dû aux publicités et outils de tracking sur un article du journal Guardian, relevé par Paul Irish dans un article où il liste les éléments forçant un repaint

Et c'est ainsi que naquirent les filtreurs de pubs

Illustration : Christophe Andrieu

Sur internet, il ne suffit pas d'apposer un petit sticker Pas de pubs, merci sur sa boîte aux lettres… une page web part d'un document HTML, de là, votre navigateur va charger ses assets (images, style, scripts,…), et dans ces derniers sont présents les éléments publicitaires. Il faut donc trier pour pouvoir les retirer.

À noter que le choix de ne pas charger/afficher des pubs est légale en Europe, mais réprimandable aux États-Unis. C'est même une des bases du fameux procès Betamax qui avait opposé studios de productions et fabricants de magnétoscopes, qui furent ravivées 30 ans après avec TiVo, l'enregistreur numérique capable de sauter les pubs.

D'abord, il y eu les filtrages écrit à la main par des utilisateurs développeurs… Soit en définissant localement certains noms de domaines dans /etc/hosts, soit en injectant spécifiquement des règles dans les navigateurs.

Puis arrivèrent les premières extensions de navigateurs, afin de permettre à d'autres utilisateurs de profiter de la fonctionnalité.

Puis une industrie se construisit, avec les filtreurs de publicités qui en ont fait un business model, comme Ad Block Plus, et dont le comportement est clairement prédateur, avec un chantage d'extorsion envers les régies publicitaires et les annonceurs.

Mais maintenant, avec Firefox (et tout récemment Brave), des navigateurs précablent des fonctions de filtrage et le signal Do Not Track, le jeu change car il implique une décision par défaut d'utilisateurs d'un logiciel.

Or, justement, je veux faire le parallèle avec une autre tendance, qui me semble contemporaine : la perception de la chute d'audience des pages web vues via le navigateur Firefox.

Apple a sa culture insulaire et a oublié le web

Cette chute d'audience n'a pas été commentée pour Safari, alors qu'Apple a lui aussi largement favorisé le blocage des publicités.
Et pour cause : sur l'audience des ordinateurs purs, Safari n'a jamais dépassé les 10%. Par contre, dans le domaine des tablettes et des smartphones, Apple est dans une position de force, et donc Safari en monopole dans son écosystème. Car le fabricant Apple refuse totalement qu'un autre moteur de rendu que Safari puisse être installé sur les appareils de sa marque. Je rappelle que les apps Chrome pour iOS et Firefox pour iOS ne sont que des recarrossages du moteur de Safari, et qu'ils en ont les mêmes limitations techniques.

La position d'Apple est encore plus extrémiste que celle que s'autorisait Microsoft il y a 15 ans et qui lui a pourtant valut des procès pour abus de position dominante..

Et comme l'époque ou MSIE régnait sans partage, Safari est un navigateur indigent, une catastrophe : Il lui manque plein d'API du W3C, de fonctions javascript, de propriétés DOM ou SVG qui sont déjà implémentées dans Microsoft Edge. Un comble !

Apple a certes remis une équipe de développement sur son navigateur pour iOS9, mais le retard reste titanesque.
Mais est-ce que le constructeur est motivé à avoir un navigateur web dans les canons actuels ? Car la firme de Cupertino fait principalement sa marge via la vente d'applications natives sur son App Store. Avoir la possibilité de faire des applications à partir du navigateur web en single page application ou en progressive web app n'est absolument pas dans l'intérêt de la firme à la Pomme. Par une culture forte de la marque (et la qualité du matériel, il faut bien l'avouer), ses consommateurs sont bien peu enclins d'aller voir ailleurs. Il reste donc très difficile de faire une application web universelle qui puisse se comparer avec les applications natives.

D'un autre côté, sous prétexte de protection de ses usagers, Apple a autorisé les bloqueurs de publicité à être installés comme extension de Safari mobile. Ce qui fait réduire mécaniquement le nombre d'utilisateurs de Safari mobile dans les rapports d'audiences des sites. La situation n'est pas pour déplaire à Apple, puisqu'il entretient l'illusion que les utilisateurs préféreront toujours avoir une application native plutôt que passer par un navigateur web, et que Safari Mobile n'a strictement aucune concurrence face à qui se mesurer.
Alors que les statistiques montrent que les applications installées sont très vites boudées.

Et puis, la publicité dans les pages web, Apple avait tenté de s'y aventurer en rachetant plusieurs régisseurs d'encarts et en construisant iAd. Mais ils n'ont pu faire jeu égal avec un mastodonte qui regroupe réseau publicitaire, outils d'analyse de trafic, profilage et surtout un écosystème mobile concurrent.

En faisant rejeter la pub par ses afficionados, Apple attaque via le porte-monnaie le Maître de l'Univers Android…

L'écosystème global de Google

Source : shortblacktechie.com

Google édite un navigateur, Chrome.
Il a gagné la bataille des features, il a gagné la bataille de la vitesse avec son moteur javascript V8, il a gagné le cœur des développeurs avec son mode développeur F12. Puis Google a attiré les développeurs avec d'autres technologies, notamment AngularJS (même dépassé, l'attrait existe toujours), Dart (abandonné), Polymer (qui sert de polyfill aux web components mais avec moins de respect au standard que Bosonic les dernières fois que je les aient comparés) et Go (un langage principalement serveur)…

Personnellement, je n'ai absolument rien contre : Google est un acteur très important qui fait énormément de R&D, contribue énormément aux standards en respectant les règles, libère très souvent publiquement les sources et ses technologies web,… et moi même, je suis un grand fan de nombres d'entre elles.
Google est un des rares contributeurs du web à continuellement le faire avancer, tout comme la Mozilla Foundation.

Mais trop de développeurs oublient de tester leurs sites ailleurs que sur Chrome. Certains développeurs livrent encore des propriétés dans leur version expérimentales préfixées -webkit- sans avoir vérifié que celles-ci étaient retirées de Chrome depuis plus de 2 ans. Pire que tout, j'ai vu récemment un développeur essayer sa création sur Opera pour se donner une bonne conscience… sauf qu'Opera a abandonné son propre moteur et utilise le Blink qui motorise Chrome. Bref, un coup dans l'eau.

La plupart de ces développeurs tiers me sortent le fait que Chrome représente actuellement plus de 60% de la fréquentation de leurs sites, selon leurs chiffres d'audience.
Et, forcément, si leur site très riche en javascript se montre moins utilisable avec d'autres navigateurs, leur prophétie est auto-réalisatrice.

Mais reprenons les chiffres de fréquentation. Si Google Chrome a effectivement une place de leader, j'ai un doute : celui que Google Analytics sous-évalue les parts de marchés de Firefox.

Et étonnement, les deux font exactement le travail qui leur a été confié en toute bonne foi.

The mission

Par défaut, Firefox demande désormais que le trafic de son utilisateur ne soit plus pris en compte, entres autres via le signal Do Not Track, et dans les dernières versions via une bibliothèque qui bloque par défaut les trackers et les malwares en se basant sur la liste maintenue par uBlock Origin. D'ailleurs, en accédant aux paramètres des add-ons, c'est la deuxième suggestion proposée, après un thème graphique, et il démarre sans redémarrer l'application.

Google tente à l'inverse de tracer au mieux les usages de son navigateur, les liant au plus vite nativement avec les identités de ses utilisateurs. Avoir Chrome qui ne remonte pas par défaut son trafic vers Google Analytics est contre-productif pour Google, surtout que leur source principale de revenus est leur régie publicitaire. (Et je ne parle pas du fait qu'il n'est pas possible d'empêcher un tracker d'audience faire son travail dans une application native)

Voilà pourquoi j'en suis venu à la conclusion que la position dominante de Chrome dans le statistiques d'usage me semble un poil sur-évaluée, et Google n'est évidemment pas bien pressé de corriger les chiffres qui sont en sa faveur.

Bref, j'abandonne l'audience-turfing

J'ai (enfin) viré Google Analytics de mon blog.

Depuis plusieurs mois, voyant une certaine dissymétrie entre les visites de Firefox relevées dans mes logs apache et ce qu'il me rapporte, ses chiffres ne me semblaient plus assez exacts. Ils me rappelle le flou des chiffres de la Alexa Toolbar à ses hautes heures il y a une décennie, laquelle ne comptabilisait que le trafic des utilisateurs anglophones sous Windows...
Analyser quels sont les sujets qui intéressent le plus les gens qui viennent me lire, c'était grisant il y a 10 ans, mais comme je ne fais pas une activité commerciale de mon blog, il y a peu d'intérêt (sinon le bonus supposé d'indexation dans le moteur de recherche Google)

Alors certes, je gardais Google Analytics pour faire des démonstrations de traçage publicitaire aux Brown Bag Lunch vie privée et des cryptoparties,… Mais finalement, je faisais rarement ces démonstrations.

De plus, les rapports de Google Analytics sont de plus en plus encombrés par les spam-referrer, au point d'avoir des résultats de moins en moins précis.

Je déconne à peine : dans mes statistiques par langue de navigateur, j'ai 20% de pollution avec des entrées qui ne sont clairement pas au format IETF. Le tableau a été édité pour mieux voir les déchets.

Comment vérifier cette intuition

Sur cette idée que Firefox (et sûrement aussi Brave et Safari) sont sous-estimés par les outils d'analyse de trafic, j'ai regardé mes logs de serveur web, mais l'audience de mon site est beaucoup trop typé et anecdotique pour être une mesure concluante.

Si vous comptez vérifier de votre côté, sachez qu'il va falloir pas mal travailler dans le filtrage des données de vos logs :

Il faudrait un site qui enregistre selon plusieurs outils de mesures (Piwik et Google Analytics), au moins 500 visites quotidiennes.
Filtrez les IP des administrateurs (et donc la votre, on compte pas, c'est tricher)
À partir des logs du serveur web, isoler les visites qui semblent réelles : les chargement de pages canoniques (donc écartez les miroirs, les repompeurs et les lecteurs de flux rss), accédées par le verbe GET, accompagnées du chargement d'assets statiques (CSS, js, webfonts, svg, images) et dynamiques (si vous chargez des éléments en asynchrone, par exemple lors de DOMContentLoaded).
Écartez les user-agent qui annoncent clairement un bot ou un crawler (on ne sait jamais, si un vous a échappé).
À partir du user-agent, comptabiliser chaque navigateur
Et de là, vous aurez des métriques à comparer.

Si en termes de proportion, la différence est flagrante, vous saurez quoi penser des chiffres analytics.

Si j'avais des recommandations

Apple relance timidement le développement de Safari, qui reste le navigateur moderne le plus en retard. Il faut l'encourager dans cette voie en refaisant un procès pour abus de position dominante. Si vous êtes propriétaire de votre ordinateur, vous avez le droit d'installer n'importe quel logiciel. Et vous êtes bien propriétaire de votre smartphone, non ? Forcer Apple à accepter que ses clients puissent avoir le choix d'un autre navigateur web, indépendamment des moteurs de rendus vieillissants webkit. Qu'enfin nous puissions construire des web-apps complètes qui tournent aussi sur iPhone. Songez que Firefox sur Android est capable d'incrustation 3D sur une image de caméra.

Ensuite, La publicité est très utile pour les contenus gratuits, mais elle est devenue un vrai fléau. Il faut libérer de la dictature de la publicité certains sites, en s'y abonnant. Oui, reconnaissez la valeur de ce que vous utilisez gratuitement. Abonnez-vous à la Presse Libre pour mutualiser des abonnements (Ou laissez La Moustache vous hypnotiser), soutenez Wikipédia, et donnez aux projets open-source. Le navigateur Brave propose de filtrer les publicités, et en contrepartie de centraliser des abonnements. Si vous utilisez régulièrement un service, reconnaissez-en le prix. (et je ne dis pas ça pour mon compte Flattr : il n'a connu des versements que quatre mois).

Et enfin, n'utilisez pas le même navigateur que tout le monde. Sinon, nous allons revenir vers les mêmes travers que l'époque où MSIE avait gagné une guerre : une monoculture et la perte d'interopérabilité du web. Ça serait dommage.

Alors ? Stop ou encore ?

Soutenons le web que nous voulons.

CPU Ex0045 Bonjour à toi, Enfant du Futur immédiat : Sans les yeux

Da Scritch — 2016-12-09T06:45:00+01:00

Une émission qui a été très éprouvante à cause du chat dans la gorge. Et n'ayant pu enregistrer un reportage sur un utilisateur de synthèse vocale, j'ai téléchargé Pico, le moteur de la synthèse vocale d'Android, pour lire mon texte à ma place. Le programme a été intégralement pigé par Stéphane Deschamps sur la page de l'émission, milles mercis à lui.
Radio

Ceci est une partie du script de la release Ex0045 du programme CPU, diffusé le Jeudi 8/12 à 11h. Plus d'infos sur le site de l'émission.

Bonjour à toi, enfant du futur immédiat, toi qui n'a peut-être pas eu la chance de découvrir la clarté quand tu as ouvert tes yeux sur le monde.

De nos sens, celui qui semble le plus essentiel à la majorité des humains, est la vue. La vision permet de percevoir notre environnement lointain, même au-delà de notre atmosphère. C'est notre sens le plus exact, au sens qu'un événement distant observé est précisément orienté et à peu près placé dans l'espace.
Perdre ou manquer l'usage de ses yeux pose un sacré handicap pour percevoir le monde, plus que la perte de la sensation du goût sucré ou de l'ironie.

Alors oui, récemment, nous avons fait une émission sur les couleurs. Aujourd'hui, pas de couleurs, ni de noir et blanc. Rien. Zilch. Nada. Pendant une heure , tu n'auras que du son, de la radio pure.

L'ingéniosité de notre cerveau l'amène à développer les autres sens pour compenser l'absence de la vue. Les aveugles peuvent être des super-héros. Non, je ne pense pas forcément à Daredevil, rien n'est moins sexy que ~~Matt Damon~~ Ben Affleck obligé de cachetonner sur grand écran dans un nanar histoire de payer ses impôts... Bon, allez, je reconnais que la série actuelle m'a tapé dans l'œil, mais revenons à nos non-voyants.

Le pouvoir le plus intéressant que développent par la force des choses les personnes malvoyantes est dans la concentration : les technologies assistives qu'on leur a créé sont imparfaites pour donner une vision globale d'un écran, ils avancent donc à tâtons (désolé) pour découvrir chaque élément affiché. Leur compréhension de l'ensemble passe par leur capacité à construire une image mentale de l'environnement.

Comme la moitié du chemin était fait par les utilisateurs improprement dits déficients, les technologies pouvaient leur proposer des alternatives viables : l'écran à aiguilles Braille et la synthèse vocale.
Mais alors il n'y a pas de vision globale ou géométrique, il fallait que ces interfaces dictent une priorisation des contenus aux programmes qui étaient d'abord prévus pour une interface graphique.

Et croyez-moi que devoir repenser une interface graphique en terme de priorisation plutôt qu'en esthétique n'est pas simple. Pourtant, il y a un réel gain à faire ce travail : il permet de se poser et de songer à l'essentiel et à être clairement explicite, jusque dans les termes utilisés.

Enfant du futur immédiat, les concepteurs d'interface travaillent souvent dans le noir, jusqu'à ce qu'ils réfléchissent à ne pas voir le résultat, mais à songer à le rendre accessible. Car oui, le paradoxe est qu'il ne faut jamais perdre de vue que le handicap peut aussi être une chance pour tous. On ne voit bien qu'avec le cœur. L'essentiel est invisible pour les yeux…*

* « Le petit prince », Antoine de Saint-Exupéry

Ressuscitez le bouton du milieu !

Da Scritch — 2016-12-06T12:32:00+01:00

Je dois être vieux, j'aime bien les détails, les outils qui sont finalisés avec amour, et quand mes instruments jouent parfaitement leur partition. J'ai la même attente du bouton du milieu de ma souris. Or, il est sacrément important, ce bougre de centriste : il ouvre le lien dans une nouvelle tab !
Webdev

Il y a très longtemps que je voulais écrire ce billet.
Je me le réservais pour les 24 Jours de Web, devenus #Nowwwel.

Il raconte une situation qui me gêne.
Elle me démange, me gratte, me met dans la même situation d'inconfort qui m'a poussé à écrire ma série « Dirty Hacky » : j'ai la forte impression qu'elle est crade, qu'elle heurte profondément mes convictions religieuses qui me font vénérer la Très Sainte W3C, WhatWG au plus haut des validateurs.

Cette situation est l'objet d'une intense frustration personnelle, car, dans ma jeunesse professionnelle et laborieuse du déchiffrement des Saintes Écritures, j'ai conçu quelques back-offices et que je remarque que nombre d'interfaces se voulant aussi primordiales pour les entreprises présentent ce qui est pour moi un défaut, une économie qui montre un certain irrespect du client.

Mais avant que je parle de ce clic du milieu…

Parlons de la souris

Oui, oui, le mulot !

Il fut une époque où la souris avait deux boutons, et qu'un troisième niveau de fonction était accessible en appuyant sur les deux à la fois.

L'iconique souris de l'Amiga. Forever

Alors arriva le troisième bouton.

La souris du Xerox Alto.... qui date d'avant la précédente. C'est à cause d'elle que X Window demandait par défaut une souris 3 boutons

Que l'on remplaça par une molette de défilement vertical, mais le bouton se cachait dedans : on pouvait cliquer sur la molette.

Got this. Elle a 10 ans. Oui, c'est une Microsoft.

À quoi servaient ces boutons ?

Oui, parce qu'un jour, quand nous n'aurons plus que des interfaces tactiles et même plus de clavier physique, il faudra bien se souvenir de l'intérêt d'une souris…)

Sans souris, les environnements fenêtrés auraient été bien plus difficiles à mettre en place. Pas impossible, mais très difficiles.
Si le bouton gauche a toujours eu une fonction d'action directe (appuyer sur un bouton, suivre un lien), le bouton droit faisait ouvrir un menu contextuel à l'objet qui était pointé par la souris. Le bouton du milieu, dans l'environnement X Window a eu une fonction plus ou moins dérivée de l'Alto, encore une fois, celle de copier : Copier le texte qui a été surligné au bouton gauche, ou, dans le cas des navigateurs, le clic du milieu ouvre le lien dans une nouvelle fenêtre, puis dans un nouvel onglet.

(Et un jour, je vous parlerais des boutons 4 à 7, de la molette de défilement horizontal et de l'indication d'élévation de la souris Logitech Cyberman).

~~Du côté de chez snob, chez les riches~~ Dans l'environnement Macintosh, les souris n'avaient qu'un seul bouton, gauche. En chef de projet tyrannique et gaucher, Steve Jobs avait décrété que la politique du Bouton Unique était suffisante. Mais ses ingénieurs et bien des développeurs d'utilitaires en avaient décidé autrement dans une dissidence polie et fonctionnelle, et les utilitaires rentrèrent dans le système sans que la hiérarchie ne fut tenue au courant. Les boutons droits et central sont accessibles et même fonctionnels, c'est plus simple en branchant une souris de PC.

je dois le confesser, j'utilise des outils de GAFAM

J'en connais plein qui vont me railler, me jeter la pierre, prononcer publiquement mon anathème, mais mieux vaut connaître son ennemi pour mieux l'affronter.
J'utilise tous les jours les outils Google Drive et Amazon Web Services. Parce que c'est mon travail, parce que j'ai pas pu faire un choix, et aussi, il faut le reconnaître, parce qu'ils sont pratiques.

Je trouve leur interface terriblement limitée, j'ai même l'impression d'être bridé dans ma productivité parce que je sais que mon navigateur peut faire des choses formidables, mais que les interfaces de ces deux géants du web ne sont absolument pas capables de le gérer.

Exemple numéro 1 : la console AWS

J'ai la chance d'avoir avec mes collègues une flotte conséquente de serveurs à administrer, EC2 dans le jargon Amazon Web Services. Or, quand je gère via l'interface d'AWS, Il m'est impossible d'ouvrir de dérouler plus d'une instance à la fois. Des fois, j'aimerais justement utiliser le clic du milieu pour ouvrir plusieurs onglets afin de comparer/grouper les serveurs… sauf que… Eh ben non, le clic du milieu sur les liens ne marche pas !
Et ce manque se retrouve dans pratiquement tous les outils de l'univers AWS.

Autre surprise, tant que vous êtes dans la console EC2, si vous regardez les détails d'un de vos serveurs, les devices qui y sont montés ont des liens qui sont des… faux liens : ils sont interceptés par le code JS, et donc ne peuvent être compris par un clic du milieu, ni être partagés aux collègues via la messagerie interne.

Il a l'aspect, le balisage d'un lien, mais non, c'est un faux-nez !

Exemple numéro 2 : Google drive

Je consomme aussi énormément Google Drive, où l'on retrouve toute une suite bureautique, mais aussi ce qui ressemble très fortement à un navigateur de fichiers. Et comme dans mon équipe, nous créons énormément de fichiers, nous les classons par sous-répertoires. Et plus d'une fois, j'aimerais ouvrir chaque sous-répertoire dans un onglet différent, ou transmettre dans via messagerie un sous-répertoire particulier à un collègue.

Que nenni !
Toutes les entrées sont des <span> dans des <div>, dont le fonctionnement ressemble très fortement à des liens, mais dont la gestion est purement javascript. Il est donc impossible d'utiliser le clic du milieu pour ouvrir vers de nouveaux onglets, et le fonctionnement du bouton droit est émulé pour avoir une fonction équivalente à Copier l'URL du lien.

Ici aussi, aussi bien le menu à gauche que les sous-répertoires ne sont pas des liens

Le Dernier Empereur de L'Empire du Clic du Milieu

Certes, à l'heure des interfaces tactiles, le bouton du milieu est vu par une curiosité ou est totalement inconnu de la plupart des macophiles. Mais, à la différence du comportement de survol du pointer, le :hover devenu infâme à cause d'usages catastrophiques, le bouton du milieu a été jusqu'ici plutôt constant car son usage était moins flagrant, donc moins prioritaire à bidouiller/braficoter par des donneurs d'ordres trop enthousiastes.

Et il faut reconnaître que les interfaces tactiles nous ont fait nous concentrer sur l'essentiel et la praticité immédiate.
L'adjectif immédiat fut à la fois sain, mais aussi porteur de risque.

Qui dit professionnel dit interaction avec une foule d'outils et d'utilisateurs, du novice au power user, qui tous en feront une consommation industrielle, 8 heures par jour, 39 payées 35 par semaine, et qui chercheront toujours à en améliorer leur pratique afin de grappiller de précieuses minutes pour fumer plus longtemps en se gelant les miches dehors. Je ne dois donc pas être le seul à m'attendre à profiter de mon usage avancé de mon navigateur web sur ces outils supposés industriels.

Très sincèrement, mes considérations de power-user semblent intéresser surtout qu'une minorité de personnes.
Sauf que l'absence de gestion du clic du milieu dans certains sites révèle un symptôme : nous faisons l'impasse sur de réelles problématiques d'accessibilité et d'utilisabilité. Et ces questions deviennent vite crispantes dans une situation de productique. Et justement, il se trouve que AWS et les Google Tools sont marketés comme des outils de production professionnels.

Sauf qu'au lieu d'avoir des vrais liens, on y trouve des aspects de liens posés sur des <div>, donnant lieu à des frustrations pile poil au moment de faire cette livraison ultra-urgente.

Mais comment sommes-nous en venus là ?

Nous sommes passés du Web document au Web applicatif

Cette révolution a réellement éclaté avec l'arrivée de G-Mail. Pour la première fois, nous avions le concept de XHR (qu'on appelait alors AJAX, nous étions innocents et faisions encore du XML et pas du JSON) et de Single Page Application ou page persistante, qui n'a pas besoin d'être rechargée pour toutes les fonctions.

Et avec notre enthousiasme le plus communicatif, nous nous sommes tous mis à fond dans la manipulation des arbres DOM, des objets générés par le document HTML via le javascript au point que nous essayons maintenant de ne plus jamais arriver à la situation où une page web complète doit être rechargée durant la navigation sur un site.

Dans son article « Checkboxes that kill your product », Alex Limi supposait que seulement 2% des utilisateurs ont JS désactivé. Non seulement il avait raison, mais ce pourcentage a sûrement baissé depuis. Sauf que…

Sauf que l'on oublie que le point d'accès d'un site internet peut être n'importe quel endroit. Et en soi, il n'y a meilleure méthode pour se rendre compte des risques qu'en désactivant Javascript.
Nous avons oublié le principe d'un accès aléatoire. Ce que j'appelle un accès aléatoire, c'est que n'importe quelle position de votre application doit pouvoir être reprise à un point arbitraire. Songez que l'ordinateur peut tomber à court de batterie, ou la connectivité perdue, ou encore la session de navigation partagée entre plusieurs ordinateurs, et que votre application web doit pouvoir reprendre depuis ce point, comme si elle avait été suspendue.
Je ne demande pas à ce que nous puissions nous passer totalement de javascript, mais qu'il y aie cette réflexion du point d'entrée aléatoire, et donc de réfléchir à nouveau nos applications en termes d'URL.

En soi, que nous puissions encore utiliser une navigation standard doit garantir que votre site fonctionne, même si votre javascript part en panique. Pourquoi ? Parce qu'en cliquant sur un lien, la page sera entièrement rechargée et donc votre applicatif javascript redémarré. Vous gagnez en solution de redressement.

La culture du document web échappe à la nouvelle génération

Il n'y a qu'à voir un applicatif AngularJS à nu : c'est un template. Un canevas, un modèle à trous. On expose une composante de source directement au lieu de le ranger à part !
Super.

En 2010, j'avais été chargé d'intervenir sur une application web pour la Google TV, alors en pleine hype. À l'époque, on réfléchissait encore aux boîtiers set-top box posés ~~sur~~ sous votre dalle immense comme des PC complets avec une interface graphique foisonnante et avec une télécommande... aussi complexe.

La télécommande de la Google TV présentée par Sony. Recto, verso. Sans trucages.

Nos ChromeCast actuelles se pilotent au smartphone, ce qui résout bien des problématiques et a épuré interface, boutons et points noirs. Mais revenons à il y a 6 ans et notre engin pré-Biactol :
La Google TV consistait en un OS Android sertie d'une interface purement web (plus Flash) embarquée dans des téléviseurs haut-de-gamme et avec un app-store dédié.

Je m'attendais donc à ce que le vocabulaire HTML soit correctement géré. Première mauvaise surprise : la documentation officielle de Google TV recommandait d'éviter la balise <a href="https://dascritch.net/post/2016/12/06/"> pour un <div class="tv-link" href="https://dascritch.net/post/2016/12/06/">. La raison invoquée était assez oiseuse : le changement de couleur des liens déjà visités.

« what the fuuuu ??? » marmonnèrent mes yeux exorbités par une nuit où le café ne suffisait plus.

Plutôt que d'inclure dans son framework d'application TV une règle CSS qui fasse le job, Google poussait à une balise HTML bricolée, fermant par là-même la porte à un portage simple des applications GoogleTV au Grand Internet.

Et la situation est encore plus démentielle dans la plupart des frameworks modernes, tel dans AngularJS avec la directive ng-href="https://dascritch.net/post/2016/12/06/". Si la raison originelle était de ne pas casser de lien après la build, son usage est vite devenu n'importe quoi et a même pénalisé nombre de sites dans leur indexation.

Nous avons abandonné les standards pour cause de Hype Driven Development en oubliant les problèmes qu'ils résolvaient.

Parait que je ne suis pas seul (à râler)

Maxime Thirouin, développeur d'applications web doué et loin d'être allergique aux dernières nouveautés javascript, a professé lors du dernier DotJS qu'une page web doit pouvoir être consulté sans forcément avoir javascript activé. Une position qui me plaît. Mais est-elle trop conservatrice ? Suis-je un vieux croûton qui râle que c'était mieux à vents ? (prout)

Récemment, j'ai conçu une web-app en page persistante avec un JS assez… complexe. Comme il ne peut être utilisé qu'avec du javascript, j'avais commencé quick & dirty avec des boutons et une gestion de navigation par des variables internes. J'ai décidé de ré-écrire sa navigation afin de remplacer tous les <button> et <div> par des liens <a href="https://dascritch.net/..."> internes aux événements interceptés.

Et bien vous savez quoi ? J'ai gagné sur deux points :

en accessibilité, puisque les <div> étaient remplacés par de vrais liens et l'historique navigateur redevint fonctionnel sans avoir à le ré-écrire
en fonctionnalité, puisque les liens profonds dans mon application devenaient partageables.

Typiquement le genre de détails que je suis le seul à remarquer, mais ce détail a été aperçu par un autre, et il m'a dit que c'était diablement pratique d'y avoir songé.

Songez-y : supporter le clic du milieu peut être utile à d'autres.

Moralité : Laissez le navigateur fonctionner, ne tentez pas de recréer la roue ; en 25 ans, ils auront pensé à bien plus de choses que vous.

CPU Ex0040 Bonjour à toi, Enfant du Futur immédiat : le web Proustien

Da Scritch — 2016-10-28T05:58:00+02:00

Ahlalalala, c'était tellement mieux quand j'éditais du HTML que je vérifiais sur IBrowse et ue je sortais de mon Amiga en disquettes pour l'amener à un pc qui avait le ftp....
Radio

Ceci est une partie du script de la release Ex0040 du programme CPU, diffusé le Jeudi 27/10 à 11h. Plus d'infos sur le site de l'émission.

Bonjour à toi, Enfant du Futur Immédiat, toi qui ne comprends pas ce crissement aigu qu'on entend dans le générique de toute émission causant d'internet sur les grands médias.

Il fut un temps où les sites webs étaient façonnés par de vaillants expérimentateurs héroïques. Et pour cause : les navigateurs web n'en faisaient qu'à leur tête, ignorant le W3C qui n'était qu'un obscur comité aux normalisations pénibles. Il fallait innover le plus possible pour occuper le terrain avec des technologies que les constructeurs pourraient breveter : les <layer>s chez Netscape, le vml chez Microsoft.

Construire un site web passait aussi par la quête d'un hébergeur (TA TA TA TAAAAAA jingle de zelda) parce que s'auto-héberger était extrêmement compliqué et même impensable avec le débit des modems.

Étonnement, à côté des universitaires, d'amateurs éclairés et des entreprises qui construisaient leur présence sur la toile pour y faire genre que on est super novateurs.... On y trouvait une faune non-négligeable d'artistes multimédias qui expérimentaient une nouvelle manière de créer, de vivre une installation artistique et de la diffuser.

Sauf que les technologies web étaient jeunes, lacunaires dans plusieurs domaines, ce qui a poussé à l'utilisation de Real Player, Quicktime, Java et Flash, des technologies principalement prévues pour les CD Rom interactifs et adaptées… tant bien que mal pour le web. De nos jour, ces pièces rapportées sont désormais abandonnées, le HTML a très fortement évolué.
Et bien évidemment tout ce qui est purement matériel est définitivement obsolète.

Enfant du Futur Immédiat, pour cette release, nous voulions reparler de cette époque des pionniers. Il se trouve qu'en Décembre nous fêterons les 35 ans de notre radio hôte, et que son site web a la vingtaine. Pour l'occasion, notre programme fait partie d'une performance. Nous nous sommes installés dans un espace culturel, le Lieu Commun, qui à l'occasion du festival Printemps de Septembre, a mis en place une exposition Bleu Bleu, qui est un hommage à l'atmosphère artistique underground de la ville de Toulouse dans les années 1990s. Présentement, nous utilisons une reconstitution d'un studio radio associatif des années 1990s tel que nous, à Radio <FMR>, avions pu utiliser à cette époque hautement héroïque.
À ce moment-là, les lignes de diffusion étaient analogiques et surtout sans retard, les jingles étaient sur cassette, les tables de mixages avaient leurs parasites et bruits de masses et si les platines CD étaient autostartées, on les démarrait souvent à coup de pied (et j'exagère à peine).

Bref, pour moi, cette heure-ci s'annonce certes pénible mais surtout une vraie madeleine de Proust.

À peu près autant que le petit milliers de flyers de soirées de cette fin de millénaire que je conserve précieusement. Des créations numériques qu'on apportait chez l'imprimeur sur disquettes, sur cartouches SyQuest, sur CD gravés, à chaque fois pour se rendre compte qu'on est pas exactement au bon format pour l'imprimeur, ou qu'il n'a pas le bon lecteur de documents. Vous le saviez, vous qu'un Zip 100Mo formaté sur Mac est illisible sur Windows ?

Ben figurez-vous qu'à l'époque, un site web c'était pareil : on le construisait chez soi, et on l'amenait sur disquettes chez le pote qui avait l'accès pour le placer sur le serveur. Une semaine après, on se rendait compte que cela ne passait pas du tout chez la voisine d'à côté.
Archaïque, hein ? Eh ben ça prouve définitivement que je ne suis absolument pas pressé de revenir à cette époque, malgré tous les bons souvenirs que j'ai pu y avoir !

Là, tu dois te demander pourquoi nous parlons de choses vieilles et limites utilisables. Figure-toi qu'il y a plusieurs enseignements à en tirer :

Toutes les difficultés de maintenance du retro-computing et retro-gaming, thèmes sur lesquels nous reviendrons plus d'une fois au cours de cette année ;
Ensuite, ce qu'était le web avant les standards ;
Ce que les standards proposent aussi, c'est de garantir qu'un site restera fonctionnel, mais qu'il perdra son contexte dans les décennies à venir ;
Et enfin, ce que défricher une technologie innovante de communication veut dire.

Bref, il a des choses à apprendre : celles que l'on est en train de perdre irrémédiablement. Oui, comme la municipalité de Toulouse a gommé d'une couleur rose tarte les superbes graf muraux d'artistes désormais courus internationalement (Fafi, Miss Van, Kat, Tilt et toute la Truskool), ou encore les excellentes chroniques artistiques de Greg Lamazières sur Télé Toulouse. Alors nous avons vécu des choses formidables, mais c'est à nous de créer les prochaines, sinon nous stagnerons dans une nostalgie stérile.

Enfant du Futur Immédiat, certes, des technologies disparaissent et les contenus qui vont avec, c'est la vie,... Mais plutôt que te faire le coup du « c'était mieux avant », on veut plutôt te raconter de belles histoires qui te donne aussi envie d'expérimenter, et de mieux apprécier ce qui est créé de nos jours.

Souvenirs de Paris Web 2016

Da Scritch — 2016-10-04T06:30:00+02:00

Paris Web te rappelle une chose fondamentale : c'est beau d'avoir des valeurs communes et l'amitié avec. Célébrons nos compétences !
Sortons

Si vous êtes sur un ordi de bureau, cliquez la première image, puis clic à droite (désolé, le script a 10 ans, faut que je le remettre d'équerre)

Mon premier Paris Web (2013) fut au Palais Broignart. Depuis, c'est chez un autre Grand Dieu que je respecte…

La rituelle soirée des orateurs, où se font des confidences très indiscrètes. Ce sont les premiers amis de 5 minutes que je revois, déjà le cœur qui bondit. Et là aussi, j'ai eu la surprise de voir combien notre émission CPU pouvait susciter d'émotions.

Et puis le lendemain, prendre son accréditation, découvrir la fresque en hommage à Mœbius (que tu nous manques...), parler avec d'autres amis, faire de nouvelles rencontres.

Je passe sur le fait que la licorne est toujours très joyeuse, pour confirmer que ce t-shirt est une référence à « Everything is a remix ».

Puis c'est parti pour les premières conférences

Encore une fois, le sujet de la vie privée montre qu'il prend dans les conférences techniques une vraie importance, vectrice de valeurs aussi importantes que l'accessibilité qui est la signature de Paris Web.

Sans conteste, l'adorable petite release d'Agnès Hasseer était la star de l'événement. Ça gazouillait et réagissait aux présentations, mettant quelques sourires

Eh oui, qu'on ne me dise pas que je suis seul à ne pas être en costard cravate lors de ce genre d'événement. C'est même plutôt l'inverse… Quant aux goodies, mention spéciale à celui d'Elie qui m'a bien fait rire

(insérer ici un trou noir)

Sur la dernière photo, je suis super heureux de retrouver Tim Carry, qui m'a convaincu de devenir développeur web professionnellement en 2007, c'était sur un commentaire chez Boulet, et il l'a amèrement regretté depuis. Une petite pause (jetons un voile pudique sur les soirées), et on enchaîne sur ce qui se passe sans enregistrements vidéos...

Les ateliers du Samedi

Oui, j'ai adoré l'atelier éducation animé par Coding School. Et comme vous pouvez le voir sur plusieurs portables, les stickers du bouquin de Laurel (on en reparle prochainement) !

Le samedi soir sur les rotules, tout le monde est bien content que cela se termine, mais on est déjà au regret de se quitter.

Si vous cherchez d'autres photos, je vous renvoie sur le pool flickr. Je n'aurai qu'un mot : hâte d'y revenir au plus vite. Comme pour Sud Web.

Bonjour à toi, enfant du futur immédiat : Journalisme de données

Da Scritch — 2015-11-13T13:50:00+01:00

Des données en très gros volume, des feuilles de calculs et des formules, des générateurs de graphiques et des interactions pour les lecteurs.
Webdev

Ceci est une partie du script de la release Ex0009 du programme CPU, diffusé Jeudi 12 à 11h. Plus d'infos sur le site de l'émission.

Bonjour à toi, enfant du futur immédiat, toi qui nous écouteras parce que tu te dis que tu écoutes un programme d'information, alors qu'en fait pas du tout : nous faisons un programme d'informatique. Nuance. Et à ne pas confondre avec un programme informatique. Nous, on se télécharge dans ton oreille.

Aujourd'hui, nous allons parler d'information, (comme quoi...) , et de journalisme dans une branche assez spécialisée mais actuellement très en vogue : Le datajournaliste. Pour ceux qui furent attentifs à la release de la semaine dernière, oui, c'est un mot valise, qui associe un mot français à un mot anglais, mais là n'est pas la question M. Elkabbach !

Le datajournalisme, n'est pas que l'alliance entre le Word qui édite les articles et l'Excel qui manipule des données dans le même Office. Non, le datajournalisme est une nouvelle manière de mettre en scène l'information, de façon moins textuelle et plus globale.

Globale au sens qu'au lieu de prendre des témoignages épisodiques par micro-trottoirs et best-of des lieux communs les plus affligeants, le datajournalisme fait une vraie analyse statistique, voire même parfois une anonymisation de données englobant une population complète. On est bien au-delà du ressenti au doigt mouillé, avec une précision manométrique des courants.

Avant, le datajournalisme consistait surtout à représenter l'information autrement qu'avec des mots. Ainsi apparurent dans la presse les cartes, camemberts et autres chartes. Les sources de données sont forcément des sources de référence, fiable, ou sinon de terrain. Ainsi, les informations statistiques publiques ou de grandes compagnies sont considérées comme de référence, alors que les informations qui sont recueillies par des volontaires, par des lecteurs, etc.. doivent passer par une étape de modération afin de s'enquérir de sa fiabilité.

D'une manière assez amusante, le datajournalisme est une discipline assez ancienne, qui est apparu dès que s'est montré le besoin d'afficher des cartes, ou de monter des proportions entre nombres. Comme le disait Napoléon à ses généraux dans sa war-room, tout en planquant sa bouteille de fine (Napoléon, of course) dans son veston, Une dataviz vaux mieux que qu'un rapport de 100000 signes.

Si vous lisez aussi les textes des chroniques et les références de nos émissions sur notre site web cpu.pm, vous avez peut-être remarqué que nous tentons d'éviter de lier vers la Wikipédia, afin de mener des recherches d'articles de référence par notre chef. Or, il se trouve que l'article journalisme de données de l'encyclopédie collaborative fait référence à une carte établie en 1854, des quartiers miséreux de Londres, avec un point noir devant chaque foyer comptant un décès dû au choléra. Avec l'indication des pompes à eau publique, cette carte montrait directement la corrélation entre les victimes de l'épidémie et les fontaines à eau publiques. Durant cette même décennie, en 1858, on a une représentation en camemberts indiquant les proportions entre les différentes causes de décès des soldats de Sa Majestée.
Un siècle plus tard, lors des élections présidentielles américaines de 1952, la chaine CBS réalise un coup de maître en estimant la victoire d'Eseinhower à partir de projections faites sur ordinateur. Alors attention, projection non pas graphique, mais lue par un speaker à partir d'une sortie papier d'imprimante.

Mais si ces métiers sont désormais passés de l'illustration au crayon et à la plume à celle produite par infographie et aux templates graphiques alimentés des feuilles de calculs ; nous avions toujours des présentations surtout statiques.

Le datajournalisme, c'est aussi la présentation de données d'une manière interactive. ce sont les pages webs dynamiques côté navigateur qui en montrent vraiment l'importance. De Flash aux technologies HTML5 comme le tri de données dans les tableaux dynamiques, puis le graphisme vectoriel en SVG, aux représentations en 3D avec WebGL. Et je n'oublie pas le présentateur TV qui se met sur un fond vert et fait mine de toucher une incrustation OpenGL, ou qui touche un gigantesque écran graphique, histoire de montrer que sa chaîne TV a mis plus de moyens blingbling que ses concurrentes, et que donc les informations se voient mieux sur le canal 3D. Chaussez vos lunettes.

Mais au-delà du talent d'écriture, de présentation et de mise en forme des données, il faut désormais aussi être un réel développeur front-end, c'est à dire un spécialiste des navigateurs web. Si des bibliothèques javascript facilitent la transformation graphique de données, tel l'excellent D3.js, il faut néanmoins s'y connaître un minimum en programmation et aussi en design et en accessibilité pour en faire une présentation attrayante, informative, fonctionnelle et compréhensible.

Et donc, il n'est pas étonnant de voir des développeurs étroitement associés, soit dans le quotidien britannique The Guardian, soit en France avec le regretté site OWNI.
Il y a donc parfois autant de développement logiciel dans un dossier en datajournalisme qu'en investigation de fond.
L'énorme différence est la pluridisciplinarité de l'exercice.

Désormais, il y a aussi l'open-data, et l'application (enfin !) de la loi n° 78-753 du 17 juillet 1978 instituant le libre accès des citoyens aux données produites par l'Administration.
...
Oui, 1978, et on ne parle d'open-data que maintenant... un tel délai démontre le retard de l'administration à répondre.
Ce qui permet de vérifier, mais aussi de faire apparaître certains sujets qui n'apparaissaient pas jusque là. Les détails qui ressortent comme quand on joue sur une photo en jouant les contrastes, les couleurs, en zoomant ou en la tordant.
Arrêtez de jouez Les Experts Miami™ dans le fond pendant que j'explique, ça me déconcentre.

Mais de là, il y a aussi le problème de l'information qui est déformée pour correspondre à une conclusion espérée. Même dans le datajournalisme, il n'est pas impossible de fausser les faits, puisque très peu de personnes regardent derrière les graphs les données d'origine. En modifiant les unités par exemple, ou même, méthode connue depuis les débuts des instituts de sondages, en ayant une question qui n'est pas totalement neutre.
À l'inverse, le datajournalisme peut réfuter un discours mensonger ou erroné. Mais il devient alors d'autant plus critique d'avoir des sources au-delà de toute critique. Forcément, fact-checking amène inspection d'autant plus inquisitrice.

Enfant du Futur Immédiat, de même qu'il faut apprendre à lire et contextualiser comment est reporté un fait d'actualité, il t'est tout aussi important d'apprendre à lire un graphique. Croise tes sources, une personne bien informée vaut mieux qu'une aux infos biaisées.

micro @HalluFMR #37 : Conférence, avec Nathalie Rosenberg et Frank Taillandier

Da Scritch — 2015-06-03T18:30:00+02:00

Bonjour, je pose deux jours de vacances, je paie mon billet de train, les nuits d'hôtel et mon inscription à cette conférence professionnelle. Avec mes propres sous
Radio

Chronique lue en direct dans l'Hallucinarium FMR du 03/06/2015.
Réalisation : Eugène Lawn.

Bonjour à toi enfant du futur immédiat, toi qui nous écouteras dans quelques secondes.

Dans le monde de l'informatique, les professionnels un poil consciencieux et qui n'ont pas un poil dans la main, ont une fâcheuse manie : passer leur temps libre à faire de la veille technologique. Ce qui veut dire qu'au lieu de dormir du sommeil du juste, ils apprennent de nouvelles techniques, ils vont faire des ateliers comme des coding dojo, ils vont boire un pot après leurs heures de boulot avec d'autres collègues parfois employés par leurs concurrents et même ils se paient deux jours off pour aller dans une autre ville à un cycle de conférences.

Car la veille technologique est indispensable, surtout dans le secteur du web : on est passé dans les années 1990 du webmestre qui savait tout faire (jusqu'à la réparation de la photocopieuse) à une multitude de métiers très spécifiques alliant design, UX, développement côté client, côté serveur, API, bases de données, etc...). Et que ces évolutions, il faut les suivre très régulièrement pour garder le niveau. Comme l'écrit l'un des concernés, être développeur, c'est bien plus que 9h-18h. Et pourtant, il existe des dispositifs de formation, mais sont-ils adaptés ?

Ben oui, on parle de DIF, un fond de formation pour les salariés, mais quid des étudiants, quid des travailleurs indépendants ? ou même ceux qui veulent changer de métier ?

Alors pourquoi des gens préfèrent griller une partie de leurs loisirs pour en apprendre plus sur leur travail ? Est-ce qu'il s'y amusent ? Mais alors, est-ce qu'il font un vrai travail ?
Je profite que Sud Web a eu lieu le week-end dernier pour parler de ce symposium annuel des professionnels du web.

Aujourd'hui, je reçois deux co-fondateurs de Sud Web, co-fondateurs des Apéro Web Toulouse :
Nathalie Rosenberg, designeuse de site, référence accessibilité, lady gaga du web à paillettes et maître cappello entre les balises HTML.
Et Frank Taillandier, facilitateur agile, spécialiste en décodage de demandes client pour les équipes techniques et surtout faux hipster mais vrai jogger.

Nathalie et Frank, bonjour

(Partie interview, exclusivement dans le sonore)
- Quand a eu lieue la première conférence technique de professionnels du web ?
- Dans les cycles des conférences pro, il y a Paris Web, Kiwi Party à Strasbourg, Mix It à Lyon. Qu'est-ce qui différencie Sud Web ?
- Le ton desdites conférences, c'est une spécificité des métiers du web : on se balance des balles en mousse, on n'a pas peur de rire. Une telle décontraction est-elle due à la rapidité fulgurante de ses technologies ?
- Pourquoi Sud Web change de ville organisatrice chaque année ?
- Est-ce que l'on paie les orateurs ?
- Pourtant c'est cher ? Alors pourquoi des professionnels paient aussi cher alors qu'il existe des tutos sur youtube ?
- Et d'ailleurs, pourquoi proposer gratuitement les vidéos après coup ?
- Il y a-t-il en coulisse une concurrence entre les orateurs ?
- Les jeunes veulent apprendre de la technique, les confirmés veulent surtout du sens et du retour sur leur métier. Comment concilier les deux publics ?
- il y a deux ans, un participant qui découvrait le milieu du web m'a dit « je n'ai jamais autant appris sur moi-même »
- À chaque Sud Web, il y a un moment exutoire, où pendant une heure, le public prend la parole et s'y exprime. Malgré la consigne, un twit a échappé vendredi dernier, je le lis : « Chaque fois que je me sens illégitime à une tâche, je me répète trois fois David Douillet a été ministre »
- L'an dernier, pour l'édition à Toulouse, il y a eu un excellent cours de dessin, de prise de note en croquis avec Eva Lotta Lamm. Cette année à Montpellier, ce fut un cours de pixel art avec Lucile Patron. On parle de contrainte graphique, d'expression de l'idée... avec un papier et un crayon, n'est-ce pas paradoxal pour une conférence de professionnels du web ?
- Il y a eu aussi Laetitia Phan, psychologue clinicienne qui parlait de hacker son cerveau. La culture générale et la compréhension d'autrui, n'est-ce pas ce qui manque à la plupart des formations du web ?
- J'ai asticoté l'an dernier un des orateurs en rappelant que nous sommes les 1% de privilégiés qui investissent leur week-end pour enrichir leur savoir-faire. Est-ce que le manque de motivation général à progresser est désespérant ou une chance pour ceux qui s'y mettent ?

Enfant du futur immédiat, lors de ce genre de conférences, j'y ai vu des technologies incroyablement futuristes, une réelle envie de faire progresser la société notamment par l'intégration du handicap, beaucoup de sourires, des angoisses éclater et aussitôt calmées...

Oui, je fais parti de ces privilégiés qui se permettent d'aller à ce genre de conférences, mais ce qui caractérise tout le monde, c'est la banane , le réconfort et l'envie d'expérimenter. C'est comme un free hug géant, mais où tu auras discuté la moitié de la journée des spécifications W3C et donc monté en skills et en level, comme disent les djeuns sur leurs meuporg.

Et ceux qui ont participé au Sud Web de ce week-end se retrouvent demain soir, l'occasion de voir si participer à ce genre de conférence n'est que du personal branling ou un réel plus professionnel.

Bonus : Le jeu en pixel art de Nolife

micro @HalluFMR #31 : Vidéo

Da Scritch — 2015-04-29T18:57:00+02:00

On met la vidéo en ligne où ? Comme d'habitude ? Sur Youtube ? Ben joyeux anniversaire, alors ! Ah tiens, c'est aussi celui de Dailymotion…
Radio

Chronique lue en direct dans l'Hallucinarium FMR du 29/04/2015.
Avec Eugène Lawn, Marie Janote et Perrine Juan. Réalisation : Philippe Pitet.

Bonjour à toi, enfant du futur immédiat, toi qui nous écouteras dans quelques secondes, le temps que le ⏳ player bufferise, etc...

Cette semaine, nous fêtons les 10 ans d'un des sites internet des plus importants en termes de fréquentation, débit, contributions et autres défis. Oui, Youtube a 10 ans, et a fait changer la face des internets.

Le site d'information Ars Technica a sorti à ce sujet un long article, très documenté et riche d'informations, que je me permet aujourd'hui de vous inciter à le lire. Bon, je sais, il est en Anglais, mais les traducteurs courent maintenant les rues, surtout les traducteurs automatiques, donc, enfant du futur immédiat, tu n'as aucune excuse.

Comme je suis infiniment bon et patient, on arrête de pouffer de rire derrière, vous me coupez mon effet, je vous fait un très rapide résumé dudit papier, un papier ainsi dénommé alors qu'il ne sort que sur un site web, m'enfin bon, vous m'avez compris…

En gros : Youtube a été créé par deux étudiants. Au moment où Google les a achetés pour 1,6 Md $, montant record qui a abasourdi tout le monde, ils n'avaient que 3 mois de trésorerie devant eux et une facture de bande passante astronomique.
Actuellement, Youtube est le 3^ème site le plus fréquenté au Monde… et perd toujours de l'argent !

Alors du coup, ma chronique sera en complément de cet article. Oui, je suis lourd dans les hyperliens…

Avant Youtube un site était devenu populaire en proposant des vidéos consultables dans le navigateur web, à savoir le site iTunes d'Apple. Effectivement, une page y propose toujours une foison de bandes annonces de films, principalement des super-productions américaines. Le showcase idéal pour sa technologie Quicktime™. Hélas, le plugin Quicktime™ n'était pas disponible sur toutes les plateformes. Ni Linux, ni téléphones portables, ni TV, ni consoles.
Mais étant un canal de diffusion mondial, les annonces de gros blockbusters entraînaient un pic de trafic très conséquent. Pour y remédier, Apple faisait déjà appel à un CDN (un Content Delivery Network), appelé Akamai. La prestation de cette entreprise consiste à rapprocher le contenu au plus près de la demande, surtout si le contenu est très populaire et d'un volume conséquent. Ce qui permet donc d'éviter que les serveurs d'Apple tombent, puisqu'Akamai fait en sorte d'avoir ses proxy au plus près des FAI grands-publics.

Youtube a amené beaucoup de questions :

comment gérer la publicité, la rentabilité au cout de transfert des vidéos,
comment gérer le coût de traitement des vidéos et de leur diffusion
comment gérer les problèmes de droits, quand on cite des films, des séries ou qu'on met de la musique

Ce que l'on oublie aussi, c'est que même si on hurle maintenant sur la mainmise de Google et son omniprésence, Google a aussi tout fait pour que Youtube soit présent partout. Youtube n'était pas lié à un vendeur de matériels ou de logiciels, Google n'avait aucune raison de ne pas être présent sur une plateforme, donc Youtube est sur Linux, BSD, consoles, téléphones, etc…
Et par la suite, devant le succès de ceux qui font des œuvres originales pour ce site, à savoir les youtubeurs, le site s'est entiché de devenir producteur et financeur de productions de ces amateurs, allant jusqu'à construire de vrais studios de productions audiovisuelles.

Youtube a vraiment transformé la consommation du web en facilitant l'envoi, la diffusion et la consultation de vidéos pour tous :

Les clips vidéos ne sont plus du tout diffusés sur MTV (hi hi hi), on les retrouve et on les lit désormais sur Youtube. Quand Radio France a des soucis de négociations avec les sociétés d'ayant-droits pour son service d'écoute à la demande RF8, Radio France a téléchargé tous les morceaux incunables de sa discothèque vers Youtube, qui a déjà négocié avec force fasse auxdits ayants-droits ayant mal audité Radio France, écoutez l'indifférence…
Et quand Free a tenté le bras de force contre Google, la dégradation de la qualité de transfert n'a pas basculé les clients de ce FAI vers les concurrents comme Dailymotion, Facebook vidéo ou autres... ils ont pris leur mal en patience ou déjoué la limite (avec un VPN). Juqu'à ce que finalement, Free face copain-copain avec Google dans sa Freebox 4K. En apparence…

Une bien amère leçon pour Dailymotion, surtout que ce site a été créé quasi en même temps que Youtube. Dailymotion a même été pionnière sur l'usage d'un player vidéo en HTML5 pur, c'est à dire en se débarrassant de l'encombrant plugin Flash. Sauf que comme la rentabilité publicitaire était la plus forte, alors que celle-ci importe finalement peu pour Youtube, DailyMotion qui aurait pu avoir l'avantage technique, est revenu en arrière, et s'est donc tiré une balle dans le pied.

Mais là où Youtube accepte n'importe quelle vidéo en entrée, quitte à le filtrer plus tard en cas de violation de droits, un autre fait le pari de n'y avoir aucune publicité : Vimeo essaie justement d'attirer les productions originales, et notamment les showcases de producteurs et créateurs, en proposant des comptes premium pour un hébergement en très haute qualité. L'idée de Vimeo face à Youtube, c'est de travailler sur le player intégrable dans une autre page web, pas d'attirer vers son site. Et donc de chercher la rentabilité non pas par la publicité envoyée aux internautes, mais par les créateurs qui sont prêts à payer pour héberger leurs vidéos.

Car oui, Youtube a créé un vrai mouvement de fond : les youtubeurs. Qu'ils soient Joueur du Grenier, ce démissionnaire obsédé de Pouhiou, ou des groupes de reprise comme Postmodern Jukebox ou des vidéastes amateurs qui avaient enfin de quoi diffuser leurs productions autrement qu'en se passant des DVD gravés.
Youtube est hélas dans une balance permanente entre le respect du droit d'auteur et la censure abusée par pseudo violation de copyright. Et il arrive souvent que des productions originales se retrouvent dépubliées sauvagement.
Une situation bien embarrassante, mais d'un autre coté, les youtubeurs sont aussi heureux d'avoir une vraie source de revenus. En recevant une partie des revenus publicitaires générés par leurs vidéos, Youtube est devenu une vraie alternative de financement, à côté du crowdfunding ou des accès payants.
Mais lassé de la présence des publicités, tu auras envie au bout d'un moment de payer pour les faire disparaître. Oui, Youtube va passer à un modèle freemium. Inutile de parier que la conversion sera intéressante pour les comptes où elle se fait, et que malheureusement, certains céderont aux sirènes et feront du contenu incitant au clic. Enrichissant pour eux, moins pour les autres…

Enfant du futur immédiat. La prochaine fois que tu iras voir une vidéo de chatons, un youtubeur ~~comme Cyprien~~ (euh non, surtout pas lui) ou un clip vidéo des Pomplamoose, il est très probable que tu le fasses sur Youtube. Or, si nous râlons de l'omniprésence de Youtube et des dangers associés à son monopole, il est peut-être temps de revenir à l'auto-hébergement pour réduire son importance : le traitement et la diffusion de vidéos par le web n'est plus aussi coûteux qu'avant.

Eh oui, cette chute des coûts, nous le devons aussi à Youtube !

Eh mais ... On sera en direct au Fablab Festival et le week-end suivant au THSF !

Brand new podcast

Da Scritch — 2014-09-30T07:20:00+02:00

Ça y est, les sonores @HalluFMR arrivent !
Radio

Oui, le Supplément Week-End est terminé, mais au même horaire, Ultimatom, Dusport et tous leurs comparses vous attendent pour leur émission Cross/Over. Toujours le Samedi de 12 à 14h, sur Radio <FMR>.

Et de mon côté, ce parano foutraque d'Eugène Lawn m'a demandé d'animer une petite rubrique dans son 17/19 du Mercredi, aka L'Hallucinarium. Occasion trop belle pour parler aux masses des enjeux du numérique, oui, mais attention : avec un ton pédant.

Je viens enfin de recevoir les sonores, pour 3 des 4 premières émissions. Profitez :

Rebecca purple (3/09)
Le dilemme Apple (10/09)
Loi de Lutte contre le terrorisme (17/09), sonore à venir
Les prix IgNobel (24/09)

Mes rubriques restent en licence Creative Commons, permettant par exemple à Jukast de proposer prochainement ma rubrique pour réveiller des gens au hasard sur Facebook.

Un petit poil de code

(et là, normalement, je largue tout le monde, mouahahaha)

Pour être définitivement honnête, il existe une multitude d'outils et de services en ligne qui gèrent très bien les podcast. Mais dans l'immédiat, je préfère en garder la gestion, et donc héberger les sonores et faire le code qui va avec.

Pour mes amis, Thomas, Olivier, etc... voici un petit script qui à partir du raw.wav me fait les deux fichiers nécessaires prêts-à-diffuser. Sachant que le format ogg vorbis est préféré au mp3 quand on reprend une archive en radio. J'ai déjà écrit sur les encodeurs Franhoffer, la connerie ambiante sur le MP3, sachant qu'on en retrouve beaucoup d'héritages dans la famille AAC, là où le ogg vorbis est prévu pour un bitrate variable et n'a pas été conçu par une équipe de sourds.

MP3 est le format le plus utilisé, mais non libre, Ogg Vorbis est mon format de préférence en html5 et passe sur pratiquement tous les navigateurs modernes, excepté Safari.

#!/bin/bash

NUMERO="4"
DDTMMTYY="24-09-14"
DDSMMSYY="24/09/2014"
SUJET="Les prix IgNobel"
YEAR="2014"
TRIGGER="AtHalluFMR"
EMISSION="Da Scritch @HalluFMR"
COPYRIGHT="DaScritch & co pour Radio FMR"
SITE="http://dascritch.net"
PADWAV="pad.wav"
oggenc -o "$NUMERO-$TRIGGER($DDTMMTYY).ogg" -t "$EMISSION: $SUJET ($DDSMMSYY)" -d "$DDSMMSYY" -N "$NUMERO" -a "$COPYRIGHT" -G "radio" -l "$SITE" -c "$SUJET" -q 6 $PADWAV
lame -b 128 --tt "$EMISSION ($DDSMMSYY)" --tn $NUMERO --ta "$COPYRIGHT" --tl "$SITE" --ty $YEAR --tg 20 $PADWAV "podcast/$NUMERO-$TRIGGER($DDTMMTYY).mp3" --tc "$SUJET"

Vous retrouverez sur github le snippet de template qui me sert à inclure les podcast dans mon thème dotclear, mais qui doit être accompagné d'une extension spécifique au langage de template.

Je l'ai écrit un peu trop vite, il manque notamment une regex pour automatiser le passage de DDTMMTYY à DDSMMSYY . Pardon, de (\d{2})\-(\d{2})\-(\d{2}) à $1/$2/20$3, et une sortie qui me donne le code HTML à mettre en entête de billet, j'irais nettement plus vite.

Mais là, ce soir, j'ai la flemme : y'a Castle à la tv.

Timecodehash : Lier vers un moment d'un sonore

Da Scritch — 2014-09-03T10:04:00+02:00

Un petit javascript autonome qui va plaire aux podcasteurs, aux musiciens et aux médias. Enfin, s'ils acceptent de jouer le jeu du web et des hypertextes.
Webdev

J'avais précédemment écrit une petite bibliothèque javascript qui permet de voir les ancres d'une page web, ceci à fins de faire des liens sur le bon chapitre (s'il est indexé) dans un très long article. J'ai ensuite monté Anchors Reveal en add-on pour Firefox, qui se montre redoutablement efficace.

Or, depuis le temps que je monte et héberge le Supplément Week-End — l'un des plus vieux podcast francophone qui s'arrête cette semaine — je regrettais qu'il manque un dispositif équivalent pour un sonore ou une vidéo embarquée dans une page distante. Un truc aussi simple qu'un <a href="page#element">…

Il existe néanmoins la possibilité de chapitrer dans certains formats containers, comme le mp4. Mais cette possibilité est très rarement implémentée et le problème reste entier dans le contexte d'une page web.
Ici, une piste marqueur dans le logiciel d'édition Audacity.

Tiens, encore ce matin, dans un e-mail, je voulais pointer la séance des lightning talks du dernier Paris Web les passages de David Rousset et David Catuhe, ben Vimeo ne propose pas de pouvoir pointer à un point temporel précis.

Et comme que des fois, on enchaîne beaucoup d'interviewes dans une émission qui dure deux heures. Et qu'on ne veut pointer que sur une seule à partir d'une autre page. Ouais, il me manquait de pouvoir faire ça :

0:26:20 : David Tsang-Hin Sun et Joseph Saint-Pierre pour le Campus Fab, fablab de l'Université Paul Sabatier
0:56:35 : Laurent Guerby pour Tetaneutral et co-organisateur du TSHF
1:17:41 : Philippe pour le Tetalab, co-organisateur du THSF et pour le badge programmable à souder
1:25:28 : Julien Peccoud pour le collectif Cortecs

Dont acte :

Chaînon manquant

Je me suis lancé dans l'écriture d'une petite bibliothèque javascript, à appeler à partir des pages qui seront appelées. L'idée est qu'il suffit de simplement insérer l'appel, et tout se fera tout seul :

<script src="…/timecodehash.js"></script>
Rappel : ne liez jamais ce genre de ressource extérieure à votre site ! Copiez la lib chez vous, elle est GPL !

Le code est du pur javascript, parfum vanilla. Vous n'aurez donc besoin d'aucune autre bibliothèque ~~ou framework~~ tel que jQuery. À une unique exception, à savoir si vous voulez vérifier les tests, le développement a été commencé en TDD. J'ai craqué car il fallait des promesses à QUnit. Oui, je suis faible.

J'ai aussi tenté d'avoir une syntaxe d'URL la plus propre possible, qu'elle n'interfère pas avec les standards et que les ancres soient relativement transparentes. J'ai fait l'impasse sur un fallback, donc en cas de plantage javascript, il ne se passera rien.

Autre chose sur le développement : j'étais aussi en déploiement continu sur mon propre blog. Donc vous ne l'aviez pas vu passé, mais il y tourne depuis le podcast du THSF 2014.

Il y a un standard

Mon script utilise strictement les API de base. Non seulement les éléments natifs sont gérés, mais tout polyfill, script, add-ons ou plugins (ben oui) qui peuvent les prendre en charge sont du coup aussi compatibles.

Il y a peut-être une petite vérification à faire, car oui, il existe encore des vieux tromblons à travers notre vaste mode, que votre serveur web supporte bien les requêtes HTTP Content-range et réponde bien par le status code 206 Partial content. Le chargement par morceaux de ressources n'est d'ailleurs pas toujours supportés par certains reverse-proxy.

Grâce à Thomas Parisot, qui fait moult tours de magie javascript à la BBC, j'ai redécouvert le standard media fragment. Oui, je l'avais lue à une époque et je l'avais stupidement oubliée.
Il permet d'adresser et de n'utiliser qu'une partie d'une ressource média, du type image, audio ou vidéo. Mais il manquait la gestion du lien vers la page où cette ressource est embarquée. C'est pour ça que j'ai construit ce petit bout de code.

Dans les faits, à son implémentation, j'ai parfois une invalidation de cache. Je tente donc d'abord de forcer le lecteur à se positionner au timecode demandé et en cas d'échec, je tente avec la syntaxe que j'utilisais jusqu'ici, à savoir en changeant la propriété element.currentTime.

Comme ces manipulations risquent de lever une erreur, j'ai utilisé non sans honte un try { … } catch(e) { … }. Oui, je sais que cette structure est l'œuvre de Satan, qu'elle n'est pas Bien™ du tout et que ce démon tue les performances, mais je vous fais remarquer qu'on risque pas la dizaine d'appels par seconde pour cette fonction, donc le besoin avoir des perfs de F1 n'est pas ici un facteur de décision.

Autoplay, la sale manie

Rien n'est plus insupportable que les sons/vidéos qui se lancent toutes seules, sans demander d'autorisation. Pourtant ... si vous venez d'une autre page, j'ai considéré que mettre le sonore à une position précise équivalait à une lecture automatique.

Je me demande si c'est raisonnable…

Enfin, là, ça ne marche pas à cause d'un souci d'événement. Assez pénible.

La syntaxe

Elle est très simple : l'URL de la page, suivi du hash de l'élément multimédia (au aucun pour le premier), d'un séparateur (par défaut &t=) et le timecode, exprimé en secondes (123), deux-points séparateur (00:02:03) ou unités (2m3s)

Ce qui donne ceci :

<a href="http://dascritch.net/post/2014/05/31/Suppl%C3%A9ment-Week-End%2C-samedi-31-Mai-2014#&t=2m3s">…

Remerciements et TODO list

En plus de Thomas Parisot et des débuggueurs Loïc Gerbaud et Benoît Salles, il me faut aussi remercier l'équipe éditrice de Touchalize, à savoir Phonitive et son créateur Guillaume Lemoine, pour m'avoir prêté de l'équipement afin de faire différents tests. Ce qui m'a permis de vérifier qu'effectivement Safari est vraiment ~~bugué à la moelle~~ capricieux au possible.

Tout n'est pas terminé : il manque encore le support des éléments AV non indexés (je rappelle que c'est pas franchement l'idéal), et des chapitrages déjà existants.

Cadeau !

Petit bonus propre à Firefox : le menu contextuel sur l'élément (clic droit ou appui prolongé sur l'élément média) permet de récupérer le lien vers la position en cours de lecture. Mais comme on n'a plus le droit de modifier le presse-papier comme on veut pour d'évidentes raisons de sécurité, vous aurez alors l'interface roots d'un bon vieux alert() des familles.

Formulaire de contact ou mailto: ?

Da Scritch — 2014-08-19T09:40:00+02:00

Qu'aviez-vous prévu pour que les visiteurs de votre site puisse prendre contact avec vous ? Un formulaire Facebook ? Ou une pop-in d'assistante virtuelle à balconnet pigeonnant ?
Webdev

Source : Demco.fr

Durant mon activité de développeur indépendant (et en tant que salarié aussi), on m'a régulièrement demandé de mettre en place un formulaire de contact sur un site web. Ce que j'ai toujours fait sans rechigner.
Il faut que j'avoue qu'il n'y a rien de sorcier derrière : demander au visiteur de laisser un message, une adresse de contact, et envoyer le tout par e-mail.

Personnellement, si un formulaire de contact est du Porcinet — l'enfance de lard, bandes d'incultes — j'ai préféré utiliser la solution primitive d'un lien mailto: pour mon blog et mon site pro. Ce n'est pas par flemme, vous en comprendrez les raisons quand vous arriverez à la [TL;DR] conclusion.

Ce billet est mon hommage personnel à So-Use!, société toulousaine spécialisée dans l'UX, qui vient malheureusement de clore son activité.
Bonus :

(Firefox) Bug 1055950 - Form with mailto: action is wrongly escaping spaces chars

Ce que dit le standard

J'aimerais rappeler un point tellement important qu'il en est évident, mailto: est une URL normalisée dans la RFC 2368 et acceptée partout.

Merci ~~Capitaine Évidence~~ Captain Obvious !

Quand vous écrivez <a href="mailto:contact@example.com">, vous utilisez une notation URL raccourcie, qui s'écrit de manière développée comme suit : mailto:?to=contact@example.com

Oui, cela ressemble très fortement à une requête GET de formulaire. Étonnant, non ? Et justement, parmi les paramètres sur lesquels vous pouvez compter :

?subject=… permet d'ajouter un titre qui reste éditable par l'utilisateur,
?body=… permet de définir un template de corps de message,
?cc=… permet d'ajouter d'autres destinataires en copie carbone,

Ce sont les plus utiles dans votre affaire.

Pour votre info, vous en avez un exemple sur l'icône sociale Envoyer par e-mail,
posé plus haut sur cette page.

Alors certes, cette RFC comporte des limitations, notamment sur les caractères en 8 bits et l'unicode, mais dans les faits même ces exceptions sont implémentées partout.
Bien souvent, les demandes clients spécifiques pour un formulaire de contact venaient de l'ignorance de ces possibilités. Comme quoi, on ne relit jamais assez les standards.

Maintenant, comparons les deux possibilités :

Anatomie visuelle d'un formulaire de contact

Le formulaire, usage avancé

Le traitement côté serveur permet des petits bonus, notamment de stocker le message dans la base de données et d'être accessible directement en backoffice. De là, on peut le lier à une commande, à un ticket interne voire y accoler différents métriques comme le temps de réponse à la demande client ou le taux de satisfaction. Il peut aussi être ventilé sur plusieurs e-mails d'un coup, voire (ça, c'est ma fonction préférée sur mon application dagence) de constituer un digest quotidien afin de ne pas encombrer votre e-mail.
De telles fonctions sont aussi envisageables avec mailto: mais construire une passerelle de réception d'e-mail est autrement plus compliquée.

Si votre service web n'est pas un véritable intranet ou un backoffice industriel, vous pouvez le faire via un service tiers comme Formsite, le bien conçu Wufoo ou même un bête formulaire Google Drive.

Exemple de reporting de formulaires de contacts par Wufoo.
N'oubliez pas que ces services sont souvent basés hors Europe. Donc si les données récoltées sont exploitées commercialement à votre insu, vous en êtes juridiquement responsable, ce qui peut faire très mal.

Attention car si vous constituez une base de données à partir des e-mails, vous devez vous mettre en conformité en faisant une déclaration CNIL, en ajoutant des déclarations légales, un formulaire de rectification/désinscription sur votre site et bien sûr en ajoutant une checkbox à votre formulaire :

Je ne souhaite pas être démarché commercialement

Si vous devez le faire, c'est que votre site manipule suffisamment de données privées et vous l'avez normalement prévu.

Le formulaire, côté pragmatique

Maintenant, regardons à l'usage ce que donne un formulaire de contact :

D'abord, sur le champ e-mail, qu'est-ce qui vous assure que votre interlocuteur donne son e-mail réel ? ou qu'il n'a pas fait une faute de frappe ? Comparée à l'envoi standard d'un e-mail, ce champ est une saisie inutile.

L'espace <textarea> ne va-t-il pas frustrer votre interlocuteur ? Notamment sur les dimensions, puisqu'elles sont fixées par design. Ceci dit, depuis 4 ans, la question se pose moins puisque tous les navigateurs proposent de redimensionner à la volée un tel champ. Encore faut-il comprendre à quoi sert cette poignée, et ensuite que le graphiste n'aie pas supprimé cette fonctionnalité qui casse tout son design.

Le champ texte est simple. Il manque l'édition riche qui peut parfois être utile par exemple pour insérer un lien, et la possibilité de joindre des documents, notamment image, pdf ou vcard. C'est bête, mais vous imaginez mal combien une vcard est pratique en prospection commerciale.

À court terme, le formulaire va commencer à se faire repérer par des spammeurs, et vous commencerez à avoir des messages indésirables, et un bruit de fond non négligeable. Soit vous avez l'énergie et les moyens pour construire des services de filtrage sur votre serveur (je l'ai fait pour des clients de dagence et c'est vraiment épuisant), ou vous vous basez sur des services tiers genre Askimet avec les risques très importants de faux-positifs/faux-négatifs. Soit vous comptez sur l'installation économique d'un test de Turing, un captcha donc, qui sera tout sauf une incitation à vous laisser un message. Et encore, j'ai pas parlé des machines de Voight-Kampff…
Qui plus est, côté script serveur, il existe une multitude de possibilité d'attaques, de détournement du service d'envoi. Combien savent qu'il faut vraiment protéger la commande PHP sendmail() ? Et d'ailleurs pas qu'en PHP, car j'ai vu ce genre de vulnérabilité en Ruby.

Les gens aiment avoir une trace dans leur client e-mail ce qui est normal puisqu'un compte e-mail tient la trace de votre correspondance. Souvent nous profitons des systèmes de tris par discussion, par date, par mots-clés, par étiquettes. Un formulaire de contact est en dehors de cette correspondance. Sauf si le script côté serveur vous renvoie le message envoyé à votre adresse.
Mais ce genre de rappels est souvent exploité par des spammeurs. Oui, encore. Il faut dire que c'est facile : on automatise l'envoi d'un message, mais c'est le serveur exploité qui va se faire bannir et l'entreprise qui le loue va voir sa réputation descendre en flèche. Ce n'est pas un scénario de science-fiction, je l'ai vu chez un client moins de 3 mois après la mise en place du formulaire.

Au final, si vous ne prenez pas proprement en compte le risque de spam, votre site web pourrait être marqué comme spammeur par des serveurs d'e-mail, bloqué par des antivirus, se prendre une mauvaise réputation et vous ne recevrez plus du tout de demande de contacts.
Une fois qu'on se retrouve dans une telle situation, en général suite à une négligence qu'on a laissé traîner très longtemps, il en est difficile d'en sortir.

Le lien `mailto:`, côté pragmatique

On ne va pas reparler de la mécanique d'envoi d'un e-mail : en usage depuis 40 ans, le système est parfaitement maîtrisé, on peut donc lui faire confiance.

Hélas, depuis le début des années 1980s, l'e-mail est encombré de spams. Et depuis 15 ans, il existe des robots spiders qui ne font qu'une chose : récolter le plus d'adresses e-mail possibles pour spammer plus. La précaution élémentaire est de ne pas donner une adresse e-mail liée à une personne, mais de créer un compte ou un alias jetable.
Néanmoins, on peut se reposer tranquillement sur la cascade de filtres bayésien et autres qui seront en place entre votre interlocuteur, son FAI, votre FAI et dans votre client e-mail. Et avec l'avantage que tout est déjà configuré, fonctionnel et d'un coût quasi-nul.

Je répète : sauf pour un site personnel, n'exposez jamais en mailto: une adresse e-mail nominative. Une entreprise, collectivité ou association doit songer qu'une demande de contact peut être reprise par une toute autre personne qu'actuellement. Rien n'est immuable : comme tout corps vivant, ces entités morales sont destinées à changer pour rester en vie. Et au coût actuel d'un alias e-mail chez Gandi, pourquoi s'en priver ?

Un lien e-mail a un avantage énorme, difficilement quantifiable : contrairement à un formulaire web, il est forcément adapté au mieux suivant le type d'appareil qui accède à votre site : mobile, tablette braille, tout est forcément pris en compte au mieux.
Et avec les fonctionnalités manquantes, notamment texte enrichi ou ajout de pièces jointes, voire même une gestion automatisée de la signature électronique.

Le client de-mail natif sera forcément plus fonctionnel que n'importe quelle recréation en page web. Sauf si vous avez les moyens de payer des dizaines de spécialistes comme Google, Yahoo ou Microsoft.

Mais si votre visiteur n'a pas de compte e-mail sur cette machine, par exemple au travail, dans un web-café ou sur une machine qu'il ne peut juger de confiance, oui cela peut être frustrant.
Et il ne peut facilement employer une autre adresse e-mail, par exemple une adresse personnelle, un compte jetable ou celui d'une entreprise en cours de création, nous aurons le même souci.

Un lien vers une adresse e-mail demande le minimum de technologie, inutile d'avoir un script côté serveur. Le protocole mailto: marche vraiment partout. Et en cas d'absence, il peut même s'enregistrer par une application tierce, et d'ailleurs, gmail le fait.

Côté réception, un e-mail peut tout à fait entrer dans un flux de gestion, et un compte e-mail en Imap peut parfaitement être partagé entre plusieurs personnes. À vraie dire, je suis très surpris du nombre de gens qui utilisent quotidiennement un client e-mail comme Thunderbird ou Microsoft Outlook sans se rendre compte qu'ils pourraient se faciliter la vie en paramétrant un tri automatique et pallier à l'absence d'un outil de gestion documentaire tiers.
Là aussi, il vaut mieux se reposer sur l'existant, c'est nettement plus économique et fiable, même s'il faut passer deux heures à lire la documentation.

Message envoyé

Le formulaire de contact pose d'innombrables questions d'interface, de sécurité et d'utilisabilité. Celles-ci sont toutes répondues avec la solution la plus standard, la plus simple, le bête lien mailto:.

La seule utilité réelle du formulaire est l'absence d'e-mail direct, ce qui veut dire qu'il répond à une non-question.

Si vous devez vous poser la question, et que nous ne construisez pas une importante solution d'e-commerce, ne vous embêtez plus : les réponses les plus simples sont souvent les plus pertinentes.

Travaux d'été

Da Scritch — 2014-07-08T14:23:00+02:00

Profitons de ce temps superbement maussade pour refaire son site “pro”, et vous inonder à la rentrée avec plein de nouveaux articles techniques. Ça m'oblige à m'ouvrir, à apprendre de nouvelles langues et si visse pas sème, part à Belloume comme disais je ne sais plus qui…
Webdev

C'est comme ça.
Ça vous démange pendant un bail, mais vous êtes intimidés ou peu motivé. Et d'un coup, vous avez envie de refaire ce câblage électrique qui a eu chaud, de couper ce lierre en petites bûchettes, de refaire cette tuyauterie qui donnait des signes de faiblesses et de ressouder ces prises bourrées de faux-contacts à force de manips.

Moi, repeignant mon plafond et m'accrochant au pinceau. Selfie de 2006.

Ben c'est un peu ce qui m'arrive cet été.

Je refais mon site corporate

Le design actuel de dascritch.com date de 2011. Oui, il était déjà en responsive web design, mais de nouveaux éléments méritaient d'y être intégrés, notamment mes conférences et plus de textes explicatifs.
Et aussi d'être un poil plus habillé, même si les css ne sont toujours pas mon fort.

La différence, c'est que j'ai voulu le faire sur un serveur statique. L'actuel (backup de la page web) fonctionne sur dAgence, et utilise son moteur de pages, de sous-images et de news grâce à l'extension de feeds. Le code front est quasi-intégralement statique. Difficile de faire un code plus lisible à intégrer :

<section id="rea"> <h3>Quelques réalisations récentes :</h3> <T:Pages limit="5"> <article> <a href="https://dascritch.net/post/2014/07/08/{{T:PageText name="lien"}}"><img src="https://dascritch.net/post/2014/07/08/{{T:PageImage format="realisat"}}" alt="{{T:PageTitle}}"></a> <div> <h4>{{T:PageTitle}}</h4> {{T:PageText}} </div> </article> </T:Pages> </section>

Seulement, dAgence est en fin de vie, son code n'a pas bougé depuis 2 ans. Avec Nicolas Guilhou, j'y ai mis beaucoup de cœur, de travail et j'aurais beaucoup à écrire sur ce qu'on y a fait, mais je n'ai ni l'envie de le continuer, ni de l'ouvrir. Ce dernier point à cause d'un client qui m'a dégoûte et aussi la qualité de mon propre code en 2007.

J'ai alors pris une décision bizarre : Je me suis rendu compte que pratiquement personne n'a vu de code de ma part. Je suis très timide et j'ai pas eu l'occasion de travailler sur des projets open-sourcés. J'ai donc décidé d'utiliser mon github pour cette refactorisation. Accessoirement, cela facilite mon boulot quand je suis entre plusieurs machines.

Mais pourquoi faire simple ?

J'ai donc inversé le concept : le backend est statique, le frontend puisera ses données.

J'ai tenté une version AngularJS + Bootstrap volontairement pas codex, je l'avoue ;), une autre en ReactsJS + Foundation + Sass stupidement bloquée pour les raisons ci-dessous. Finalement, je suis reparti sur mon squelette, j'ai intégré le TinyTypo de la fabuleuse Romy “Tétue” Duhem-Verdière. J'en viens à la même conclusion que Paul Rouget et Maxime Thirouin : des fois, on va nettement plus vite sans s'encombrer de frameworks-couteau-suisse.

Et maintenant, ça marche comme je le voulais en MSIE9. Oui oui. Merci IE Net Renderer

Bon, par contre, le design RWD liquide avec 5 breakpoints de largeurs différents, je doute que ça soit une solution viable à terme ^^;

Je voulais faire des requêtes cross-sites, mais les mesures de sécurité prophylactiques (CSP + CORS) que je loue tant me posent des soucis en développement local ou en hébergement github.io. J'en ai donc profité pour écrire un parser pour récupérer mes derniers articles. Et plutôt que le faire en Javascript, en PHP ou même avec des regex via le shell, j'ai tenté de le faire en python pour sortir de ma zone de confort. Oui, le code est crade, mais il coupe la moutarde.

Normalement, je devrais déployer cette nouvelle version avant la fin du mois. Vous pouvez toujours commenter en bas ou ouvrir un ticket bug/suggestion sur github

Le truc rageant, c'est que quand tu termines ton site, tu tombes sur jsonresume.
Ah ben flute.

Le faux calme

Vous verrez moins d'articles techniques publiés cet été. Des articles comme les bug reports, la licence JSON, la balise <img />, les floating labels, les boutons de partage sociaux et d'autres peuvent demander de la recherche. J'ai décidé de prendre le temps là-dessus pour gaver vos listes d'articles à lire en urgence.

J'en profite aussi pour essayer différents projets qui justement vont me servir à écrire ces articles. Certains projets sont déjà consultables sur github pendant leur construction :

Une bibliothèque javascript pour faire des ancres timecode dans les pages web incluant sonore ou vidéo, par exemple un podcast
Un jeu de programmation robotique sur une idée et avec Fabien Tregan,
Un addon Firefox pour les auteurs utilisant dotclear
Bricoler un peu pour me forcer à apprendre Dart, Python (c'est déjà parti), Ruby, Rust et Go
Écrire des composants web-components avec la fantabuleuse bibliothèque Bosonic de Maître Raphaël Rougeron & associates
Ré-implémenter en js, php, ruby et python avec tests uniformes le système de numéro de commande de dagence
Améliorer encore le thème de mon blog
Parler des implémentations des systèmes de login sur les sites webs, et du faux conflit UX/Sécurité
Reprendre après son long hiatus ma Psychanalyse du Clavier
Disséquer la navigation documentaire
Comparer BBCode-like et Wysiwyg HTML (je sais qu'il est très attendu, ce dossier)
IPv6 sans pleurer

Ça va m'occuper.

À l'heure Californienne : Google I/O 14

Da Scritch — 2014-06-26T09:43:00+02:00

Hier, c'était la conférence Google IO, à destination des développeurs. Petit compte rendu du stream de San Francisco pris à Toulouse avec le TAUG en Extended™.
Gizmo

That's how we sell gizmos in California, USA

Nous nous étions préparés, solidement documentés, chauds comme la braise ce soir-là chez Epitech.
L'événement Google I/O à destination de sa communauté de développeurs s'ouvrait sur une gigantesque machine infernale. L'horloge à boules donnait le décompte avant d'envoyer dans le décor une grosse de bowling.

Note : 18 minutes de mire, et pas de son avant 3 minutes après le début. On a eu pareil.

Mais en soit, rien de franchement phénoménal ne devait y être annoncé pour le Grand Public : On était là pour parler surtout technique et gizmos qui vont avec. Si vous ne comprenez rien de rien à HTML5, que vous n'êtes pas prêts à apprendre à coder une appli Android (avec Androsium), vous risquez d'être perdus à la lecture de ce compte-rendu.

Moi, je m'en fous, j'étais là pour ~~troll~~ twitter, goûter aux pizzas et démontrer KDE Connect :

RT @sim_previdente: Petite démo de KDE Connect avec @dascritch et @_PolyAd ! #magique #io14 pic.twitter.com/FxuPPt1Ws2 #ioextended_tlse
— Xavier Mouton-Dubosc (@dascritch) June 25, 2014

D'abord un nouveau style d'interface pour la prochaine version d'Android. Désormais, les boutons du bas seront ◁ □ ◯.
Oui, moi aussi, ça m'a choqué : il manque × pour que Sony soit heureux de leur faire un procès.

Google continue dans son optique connectée avec sa gamme Google Wear. Après les Google Glass, les Google Watch, et notamment une montre avec un écran rond, preuve des avancées de Sharp dans la production de dalles non carrées.
Cela reste un gadget coûteux, très coûteux. Les applications proposées comme la biométrie n'en valent pas forcément le prix, et pouvoir consulter la recette de cuisine avec sa montre ne passera pas le test pratique quand vous aurez les doigts plein de farine. Et il faut toujours recharger toutes les 24 heures, n'en parlez pas à Jack Bauer.

Trouble-fêtes

Deux interruptions dans le public par des “anti google”, ou plutôt des personnes qui posent la question du rôle social de Google et de son slogan Don't do evil. n'ont pas apprécié l'acquisition de Boston Dynamics. Je dirais qu'ils ont raison : on parle du rachat d'une entreprise qui construit des dispositifs militaires, des engins de guerre. Faute d'une communication claire sur son avenir moral, Google fait peur.

#io14 #ioextended_tlse "Voice enabled" par défaut. ne dites plus « OK Google » mais « Hello NSA » Soyez poli, quoi , bordel ! merde !
— Xavier Mouton-Dubosc (@dascritch) June 25, 2014

La privatisation des API système continue

Et je me demande de plus en plus ce qu'il va rester dans l'Android Open Source Platform. Apple aussi avait ouvert l'iOS et MacOSX, mais maintenant, vous ne trouverez pratiquement plus grand chose concernant les versions modernes.

Pour me faire l'Avocat du Diable (but he doesn't do evil), je plaiderais que ce mouvement est logique. Il est dû aux péchés originaux de la plateforme Android : impossible de pouvoir facilement faire migrer la majorité l'écosystème à la dernière release de l'OS, contrairement à Apple. Les appareils sont souvent encombrés de surcouches constructeurs (Samsung en tête), opérateurs (hein Orange et SFR), et maintenant applicatives (Facebook).

Donc une partie des API importantes ne sont plus dans les parties open-source d'Android, mais dans des applications Google, le framework Google Play Services, actuellement déployé sur 93% des terminaux. Couplage fort en vue, moins d'expérimentations intéressantes ? Là où une app comme Focal fait bien mieux que la plupart des applications d'appareil photo par défaut, ben ce choix alternatif risque de disparaître. Résultat, si vous installez une ROM alternative comme CyanogenMod pour libérer votre gizmo, il est plus que probable que vous installerez rapidement Google Play et les applications Google de base.

Fail.

La conquête du prochain milliard de devices

Un milliard d'appareils tournant sous Android actuellement en fonction (je ne compte pas les tablettes no-name qui calent vos commodes).

Le prochain milliard, tout le secteur le sait, il sera dans les pays en voie de développement.
Google l'a donc clairement annoncé hier qu'il y lancera un smartphone à 100 $. Par là-même, il tente donc de chasser sur les terres promises à Firefox OS et Tizen. Non, sans rire, Microsoft ne peut proposer de Windows Phone décent dans ce prix-là, et l'activité feature phone de Nokia va donc péricliter.

Des pays où les téléphones à double carte SIM y sont très populaires. Forcément, Google va donc proposer le double compte Google sur les appareils, ce qui amène enfin la possibilité de différencier sa vie privée de son activité professionnelle. Effet de bord très bienvenu.

Le retour de la Google TV

4^ème lancement.
Va-t-il enfin voler ?
A-t-il une chance de commencer sérieusement en France ?
Ce segment de la conférence avance, un panneau annonce une vingtaine de partenaires industriels, et dans le lot on notera 2 FAI Français !
Bouygues Télécom et SFR trouveront là le moyen de sortir rapidement une box triple-play puissante, puisque les actuelles avaient été ridiculisées par la Freebox Revolution, et ceci malgré un investissement conséquent. BouygTel encombré d'une interface flash très vieillissante, SFR d'un manque d'applications tierces. C'est encore plus drôle quand on sait que la Freebox Revolution était annoncée officiellement quelques mois après les premières Google TV, et, selon certaines rumeurs parisiennes, devaient même embarquer la Google TV.

Oui, mais la première Google TV était très mal conçue : Basé sur le navigateur Chrome en plein écran, il accusait déjà deux ans de retard par rapport au navigateur qu'on pouvait installer sur son PC. Y développer une belle interface était si pénible qu'on arrivait à un résultat bien plus probant en Flash.

SFR/Numéricable et Bouygues Tel se préparent une très belle nique à Free (ils n'attendaient que ça), faisant valoir de plus leur meilleure connectivité vers les services de Google.
Et Google lui-même va enfin pouvoir s'installer ans le pays qui a inventé le triple-play ADSL et où ni Google TV, ni AppleTV n'ont jamais pu s'implanter, s'assurant un parc d'abonnés plus que conséquent.

#io14 #ioextended_tlse Mantenant, vous pourrez dire « OK Google, skip this ad » si pratique sur la TNT
— Xavier Mouton-Dubosc (@dascritch) June 25, 2014

Coding in the cloud

La démonstration de l'offre d'hébergement de services par Google avait du mal à démarrer, effet Bolnadi oblige, mais elle valait l'attente.

Écrire du code dans n'importe quel langage à partir de son navigateur ? Oui on peut, on a des IDE complètes, souvent basées sur l'excellent éditeur Ace de Cloud9 , comme par exemple chez GitHub.

Éditer, compiler, déployer ? plus rarement.

Éditer, compiler, texter, déployer mais aussi faire du débug dans une console, toujours dans votre navigateur web, en posant des breakpoint ? Et ben là, ils ont fait hier la démonstration et nous étions bluffés.

Mais pas pour tout le monde car à Toulouse, la tireuse à biaires venait d'ouvrir. Ou le foot ?

Bière vs breackpoint et cloud programming #ioExtended_tlse pic.twitter.com/UD94uuRpVN
— Maxime Warnier (@maxdow) June 25, 2014

@maxdow @dascritch Certains ont essayé de résister mais pas longtemps hein 😀 pic.twitter.com/NrMdTU79PK
— Simon Prévidente (@sim_previdente) June 25, 2014

#ioextended_tlse this one is for @nitot and @mozilla_fr @MozillaZineFr pic.twitter.com/Rl6qDAb4yN
— Xavier Mouton-Dubosc (@dascritch) June 25, 2014

Le HTML5 en force

Et à un point qui est surprenant : Android suit la voie inverse d'iOS. Au sens qu'au lancement d'iOS, aucune application n'était installable donc tout devait être fait en HTML5. Android lui, était prévu pour installer des applications d'entrée, mais en concevoir les vues, l'aspect de l'interface, tourne au cauchemar car il faut prévoir un code spécifique pour pratiquement chaque dimension d'écran existante. Mais, par les joies du Responsive Web Design, en intégrant une page html directement dans votre application, ce que l'on appelle une WebView.
Dans les annonces d'hier, Android pousse de plus en plus vers HTML5 et pas que dans WebView.

Énormément d'API montent dans le navigateur web, mais aussi l'arrivée en force des web-components. En résumé : Polymer va ainsi proposer les éléments d'interface du système Android transposés en HTML5 et en web-components. Ce sujet mérite un article complet, donc je le traiterai de manière approfondie la semaine prochaine.

Depuis 6 ans, des gens très futés tentaient de faire des interface à la iPhone en HTML. La raison est que l'interface utilisateur a été énormément travaillée par des graphistes et des ergonomes et qu'elle possède sa propre logique. Mais jamais Apple n'avait proposé d'implémentation officielle de ses guidelines UI, et bien souvent, ces implémentations sont complètement foireuses, je pense notamment aux extensions “mobile” Wordpress pénibles et peu lisibles au final.

Google va donc proposer son interface Android en web-components standards, et en plus via Polymer, donc non limité à Chrome, mais compatible Firefox, Opera, Safari et même MSIE9.
C'est très important car cela sonne enfin le glas des frameworks css monolithiques à la Foundation et surtout (kooff koooffff) Bootstrap. Nous allons donc très sérieusement y gagner en professionnalisme et en qualité d'interface pour nos applications web. Et Google offre aussi par là-même un moyen efficace de faire tester son univers mobile à tous les utilisateurs du web. C'est aussi une ouverture publique d'une partie du code-source.

new polymer demos are cool http://t.co/Zid5ko0ion http://t.co/9B2qUl3Ifx http://t.co/IWIVdyMlNv except for keyboard or assistive tech users
— Steve Faulkner (@stevefaulkner) June 25, 2014

Petit bémol pointé par Steve Faulkner dans son twit : il y a encore des efforts à faire en terme d'accessibilité, ce qui est plutôt primordial dans le web.

Et sur place

Outre la retransmission de foot qui n'a intéressé qu'une demi-douzaine de masos, les boissons, pizzas, charcuteries et fromages fins, une douzaine de startups ont pu présenter leurs activités comme Unitag, Androsium (de circonstance) et le très prometteur Jukast.

On a eu droit à de belles démos technologiques, mais c'est une fois de plus le bac-à-sable interactif de Science Animation qui a attiré ces grands enfant de devs hardcores. Internet des Objets, mais bien sûr ;)

La blague de la soirée

Les participants de la soirée IO Extended à Epitech Toulouse pouvaient gagner des goodies sur un concours de bits. Euh pardon de retweets.

J'ai stratégiquement axé mon sujet sur le chiffre des 93 millions de selfies par jour dans le monde fait avec un gizmo android.

One more selfie bite the dust #ioextended_tlse pic.twitter.com/xp7rqZuuWl
— Xavier Mouton-Dubosc (@dascritch) June 25, 2014

Que j'ai gagné… d'une courte tête face à Lisbé, sur une immonde faute d'anglais. J'étais mortifié quand je m'en suis rendu compte 30mn trop tard.

@dascritch #ioextended_tlse JulienKT David et Xavier sur la même photo. Stylé les gars.
— Julien Del Rio (@JulienDelRio) June 25, 2014

“@dascritch # #ioextended_tlse roooonnroooooon >^.^< pic.twitter.com/FJ6NA0YCsV” thanks to @BeMyAppFR and @intel france
— Julien Del Rio (@JulienDelRio) June 25, 2014

Et pas ~~peu~~ fier en brandissant mon Galaxy Tab 3 tout bô qui d'ailleurs, n'est pas vraiment le mien, c'est un outil de développement HTML5 fourni par Intel. Avantage : j'ai un numéro de helpdesk aux US. Hello IT ?
N'empêche… une prise électrique américaine ^^, mes toilettes Toto vont se sentir moins seules sur mon transfo 110V/60Hz de salle de bain.

Milles mercis à tous !

Merci à tous !! #io14 #ioExtended_tlse @EPITECHToulouse pic.twitter.com/Dha11Zx6cG
— ToulouseAndroidUG (@ToulouseAUG) June 25, 2014

À Intel et BeMyApp France pour le superbe cadeau, au Toulouse Android UG, as usual à l'Epitech Toulouse pour leur accueil et surtout à Julien Del Rio qui était dans la salle de conférence à San Francisco et qui visiblement n'arrêtait pas de pouffer de mes blagues twittées sous les regards intrigués de ses voisins américains.