An english translation is available.
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. (enfin, la 6.1, car j'ai dû modifier l'icône dont il est question).

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

Je continue le tour des coulisses du webcomponent cpu-audio.js. Et aujourd'hui, on va parler de ce qu'il y a derrière son bouton

Je vous remets le player, dans la dernière version de dev. Sinon, ⇓ sautez ⇓ directement ⇓ au chapitre suivant ⇓

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.

Ouais, le sonore date un peu, mais c'est pour illustrer et de toutes façons, je ne fais pas mieux en radio depuis.

The switch

L'interface normale du lecteur ci-dessus

Ce bouton (à droite de l'interface normale) bascule l'interface de lecture, vers une interface de partage. À noter qu'il est possible de cacher ce bouton et rendre l'interface d'action inaccessible via l'attribut hide="actions", ce qui peut se comprendre, par exemple si le site a déjà sa propre interface de partage.

Une fois le bouton cliqué, on se retrouve sur le panneau d'actions qui prend toute la largeur du panneau principal du web component :

Vue en pleine largeur. Pas de panique si vous ne voyez pas exactement ça : c'est le sujet de l'article.

Ce panneau propose différentes actions comme la possibilité de charger directement le sonore (en fonction du format qui est supporté par le navigateur, parce qu'il reste des vieux tromblons comme Safari), et aussi celui de partager le sonore par e-mail, sur twitter et sur facebook à des amis en renvoyant vers l'URL canonique de la page du sonore. À cause des limitations imposées pour les partages sur les réseaux sociaux sus-mentionnés, seul le partage par e-mail permet en l'état de profiter du media fragment pour pointer exactement au même moment.
De gauche à droite :

  • reprise de la cover pour revenir à l'interface de base,
  • partager sur Twitter (lien simple),
  • partager sur Facebook (lien simple),
  • partager par e-mail (lien mailto:),
  • télécharger le sonore (en fonction du codec accepté par le navigateur),
  • annuler, revenir à l'interface normale.

Comme le web component est en interface liquide et en mobile first, l'interface est simplifiée sur les petites largeurs : la cover disparaît, et les textes aussi.

Oui, alors, si vous avez des remarques sur le design des icônes, rien ne vous empêche de proposer mieux. Je suis programmeur, pas Picasso.

URL canonique voulant dire que si par exemple vous partagez l'émission qui est en une du site cpu.pm, vu que c'est la dernière émission diffusée, elle y disparaîtra à l'émission suivante, donc il vaut mieux directement renvoyer vers la page de l'émission. Et ne faites pas ceux qui ne connaissent pas, vous devriez utiliser le tag. Oui, même si, comme moi, vous ne doublez pas un site prévu pour desktop avec un m. pour mobile parce que ça fait trop perdre de temps.

Si l'URL canonique de ce sonore n'est pas celle de la page où est intégré le player, l'attribut canonical="" est là pour ça.

The wish

Il existe déjà sur les navigateurs des plateformes mobiles un menu de partage de lien vers les réseaux sociaux. Je l'avais déjà fait remarquer dans le billet où je parlais de la réapparition des boutons de partage sur mon blog. C'était y'a 5 ans, et si le design général des navigateurs a changé, cette interface hyper pratique est toujours là.

Ici, dans Firefox Android en 2014, et ça déchirait déjà pas mal, renvoyant sur les applications natives correspondantes.

C'est cool, sauf que, bien souvent le navigateur va reprendre le titre de la page, lequel est bien souvent encombrée d'éléments inutiles genre glyphes de séparation, titre du site en plus de la page, description in extenso pour du SEO à la papa bourrée de mots-clés mot-clé keyword key word terme important , etc… Ce qui laisse le boulot à l'utilisateur de nettoyer et de remettre en forme.

The witch

Arrivent les bonnes fées des standards du web : Le W3C a introduit navigator.share() aka WebShare, une fonction qui standardise l'action et permet de proposer un texte descriptif un poil plus long.

Cette fonction présente plusieurs avantages :

  • être standard (théoriquement, on verra plus loin) ;
  • ne pas oublier un service de l'utilisateur (au lieu de rester sur le diptyque facebook/twitter) ;
  • utiliser un contrôle natif de l'OS beaucoup plus pratique sur les smartphones ;
  • envoyer directement le lien à l'application native installée dans son interface idoine ;
  • ne pas pister les utilisateurs par les réseaux sociaux en proposant les boutons enrichis (avantage partagé si vous utilisez les liens HTML classiques) ;
  • ne pas pister les utilisateurs par le site web en devinant quels services de partage l'utilisateur emploie ;
  • ne pas encombrer l'écran du smartphone avec trouzemillions de services.

L'appel est hyper simple.
Ça fait même hyper plaisir d'avoir quelque chose d'aussi simple et correctement pensé, au lieu de devoir faire appel à un constructeur de classe, à des paramètres instanciés par un autre constructeur pour un objet spécifique, et d'envoyer via un diffuseur d'événement.

♫ Dans une page… ♬ dans une page web *, ♫ servie en h… ♬ servie en https://, sur une action utilisateur (genre ), lancer :

navigator.share({
            'title': document.title,
            'text': document.querySelector('meta[name="description"]').content,
            'url': window.location.href
        });

* Honte à moi, oui, j'ai bien chanté ce paragraphe sur l'air du Cake d'Amour dans « Peau d'Âne » de Jacques Demy. Et maintenant, vous l'avez dans votre tête, votre journée sera foutue. Plaintes en commentaires ↓, merci

Si votre site est déjà bien conçu, vous n'avez quasi plus de boulot à faire. Si votre site est conçu comme un cochon, il va déjà falloir apprendre à ne plus oublier les balises <meta... descriptives.
D'ailleurs, on pourra aussi partager des fichiers avec le niveau 2 de ce standard et une API pour tester l'envoi (navigator.canShare()).
C'est génial !

The twist

Sauf que :

Seulement Chrome sur Android et Safari sur le tout dernier iOS
Les chiffres de support par CanIUse.com relevés à l'écriture de ce billet.
  • Cette API n'existe pas sur ordinateurs de bureau (excepté Safari Mac) ;
  • Elle est aussi indisponible sur Chrome Desktop, même en mode responsive (qui n'est pas un vrai émulateur mobile, et n'est pas toujours fiable pour tester réellement) ;
  • Cette API n'est pour l'instant supportée que par Chrome sur Android et iOS (eh !) ;
  • Sur iOS , chaque application devait prévoir sa propre liste de partage, il y a donc souvent des oublis faute de registre commun au système. C'est enfin arrangé depuis la dernière version d'iOS avec, devinez quoi ? Le support expérimental de navigator.share !
  • Il n'est pas possible pour un service en ligne accédé via le navigateur de s'inscrire, tant que l'API Web Share Target n'est implémentée nulle part (et si elle l'est, il sera impératif de demander l'autorisation à l'utilisateur par une interface de validation, afin d'éviter le spam).

Devant la volatilité des réseaux sociaux, et surtout l'arrivée des ruches décentralisées où un habitant est supposé pouvoir migrer facilement vers un autre service, il est vraiment dommage de Web Share soit si peu considéré depuis 3 ans, et cantonné que sur une plateforme. Il y a pourtant sûrement le moyen de créer une WebExtension qui fasse le taf pour les ordinateurs de bureaux.

Alors, on m'a souvent demandé la possibilité de rajouter dans le lecteur une option de partage vers un site particulier. Ben oui, j'avais mis que Facebook et Twitter, beaucoup me reprochent de ne pas avoir mis Diaspora*, VKontakte, Mastodon, etc.social.random() dans l'interface d'action de mon player.
Sauf que, évidemment, plus on en met dans un espace délimité, plus les boutons de chaque site sont petits et les services sont serrés sur une banquette large comme un écran de smartphone. Et quoique l'on fasse, impossible de couvrir toutes les solutions de partage, même pour les sites spécialisés, ne serait-ce que pour une raison évidente : Chaque jour naissent de nouveaux sites.

Et du coup, je ressors du même billet précédent cette image à l'humour douteux. .

À revoir cette illustration, on remarque immédiatement que nombre de ces services sociaux ont disparu dans les 10 ans. Et qu'un tel foisonnement rend la page totalement illisible.

The tweet

Donc si je met pas les services dans le code du composant, peut-être pourrais-je créer une API pour que l'intégrateur puisse en rajouter ?

­— HIN ! HIN ! F.B.I. Fausse Bonne Idée !
— Hein ? Quoi ? Encore ?
­— Ben oui, je ne m'en lasse pas.

Car cette possibilité induirait un autre problème : elle laisse le travail à la charge de celui qui intègrera le composant sur son site, ce qui induit le prérequis qu'il s'y connaisse en javascript et qu'il lise la doc de mon API. Je vous connais bande de petits coquinous : même avec un RTFM, vous ne le faites jamais.
Et évidemment, invariablement, l'opérateur du site oubliera d'autres sites de partage.

Cela induisait aussi d'inclure des paramètres par l'intégrateur qui pouvaient poser soucis :

  • intégrer une couleur en l'injectant via l'attribut style="background-color" ;
  • intégrer un logo monochrome en SVG, et on est obligé d'être monochrome à cause de l'inversion de couleur au :hover et :focus, sans compter le pari que l'image soit ajustée aux contraintes de mon canvas et que l'intégrateur n'aura pas mis de js embarqué quelconque ;
  • intégrer un motif d'URL où renvoyer pour le service ciblé, à condition qu'une telle URL existe.

Oui, je pense à vous, les sites de partages sur réseaux sociaux qui n'ont pas de possibilité d'enregistrer par un lien simple. Souvent par volonté d'obliger leurs utilisateurs de passer par une appli mobile native bourrée de traceurs publicitaires.

Ben alors, on fait rien ?

Je ne sais quoi vous dire…

Pour l'instant, je fais une feature detection, qui fait que les boutons vers facebook, twitter et e-mail sont remplacés par un bouton unique lançant la fonction navigator.share(). Une solution qui n'apparait uniquement que sur Chrome Android et Safari.

Le panneau d'actions, avec le bouton unique lançant navigator.share()
Capture d'écran sur Safari Mac par Hadrien Lanneau. La fonction ouvre un menu contextuel à la position de la souris.

Et pour les autres, oui, construire une WebExtension polyfill serait une bonne idée (dans une version plus générique et sans jQuery que web-share-api de C. Zuber). À condition que les sites de partage participent au mouvement sans vouloir y embarquer du script analytics de traçage publicitaire.

Personnellement, je pense que la meilleure interface possible pour inscrire un site de partage en plus dans son navigateur est de reprendre ce qui existe déjà pour ajouter un moteur de recherche. Parce que cette interface est propre, elle est explicite, elle est standardisée, et les évolutions à y faire apporter ne sont pas énormes.

Pour la réalisation, à vous de tenter, je ne crois pas que cela soit hyper-compliqué, et ça sera toujours mieux à long terme qu'un antique script à la AddThis.

Et en attendant, soutenez les initiatives pour ajouter WebShare dans :

Ce billet fut un poil long là aussi, et j'ai causé de code, de standard et d'implémentation, mais je pense que cela le valait, surtout que ce problème ne s'applique pas, loin de là, uniquement à mon cpu-audio.js. Prochain épisode, on va plutôt parler de CSS, et là aussi, on parlera standard et implémentations pour… des couleurs bizaaaaaaaarres !
Si le titre vous fait peur, c'est que je tiens sûrement le titre d'un film d'horreur, et donc je me dois de sortir la réplique qui tue :

Prochaine épisode : Des couleurs impossibles