Ces derniers mois, plusieurs demandes ont été formulées au sein de divers groupes Discourse pour améliorer l’analyse des courriels entrants. Exprimées sous forme de scénarios utilisateurs, ces demandes peuvent être globalement classées en trois catégories :
- « Je souhaite pouvoir utiliser les mêmes fonctionnalités HTML lors d’une réponse par courriel que celles dont je dispose lors d’une publication sur le site web. »
- « Je souhaite pouvoir consulter et rechercher les messages de notre liste de diffusion. »
- « Je souhaite que le contenu créé par courriel, que ce soit via la réponse par courriel ou l’importation en masse, soit systématiquement bien mis en forme et analysé avec précision. »
Je vous fournirai ci-dessous des exemples concrets de ces demandes, mais pour l’instant, l’essentiel à retenir est que chacune de ces trois demandes « différentes » vise en réalité le même objectif fondamental : une analyse plus précise des courriels entrants.
Il y a quelques mois, j’avais contacté @sam par courriel pour lui proposer d’activer l’utilisation par Discourse de l’API d’analyse de courriels commerciale proposée par notre entreprise. Sam a suggéré de créer un sujet exploratoire ici afin d’expliquer les avantages que l’intégration de notre API offrirait par rapport à la solution d’analyse de courriels entrants existante de Discourse, ainsi que la manière dont notre API pourrait être intégrée sous forme de plugin.
Je traiterai ces deux sujets en détail, en commençant par l’état actuel de la solution d’analyse de courriels de Discourse. Et pour les personnes qui n’ont pas passé les dernières années à réfléchir à l’analyse des courriels, j’inclurai également un contexte général sur le problème.
Ce sujet est assez long, mais n’hésitez pas à naviguer librement. Voici ce qui sera abordé :
- L’état actuel de l’analyse des courriels dans Discourse
- Les avantages d’une meilleure analyse des courriels
- Personas des parties prenantes
- L’API d’analyse de courriels FWD:Everyone
A. Suppression des signatures et des réponses
B. Normalisation du balisage HTML
C. Prise en charge des langues
D. Mise en forme avec CSS - Intégration proposée
- Tests de l’API
L’état actuel de l’analyse des courriels dans Discourse
Discourse dispose déjà d’une fonctionnalité de réponse par courriel qui transforme les réponses des utilisateurs en nouveaux messages de forum au sein d’un sujet. Cette fonctionnalité fonctionne comme suit :
- Un utilisateur reçoit une notification par courriel contenant un nouveau message sur un sujet du forum qu’il suit.
- L’utilisateur répond à ce courriel.
- Cette réponse par courriel est transformée en un nouveau message dans le sujet du forum concerné.
Conceptuellement, il s’agit d’une fonctionnalité inestimable ; c’est le flux de travail préféré de nombreuses personnes et un atout indispensable pour de nombreuses communautés basées sur des listes de diffusion qui envisagent de migrer vers Discourse.
Le hic, c’est que lorsque ces réponses par courriel sont transformées en messages de forum, elles sont souvent rendues avec une mise en forme manquante ou incorrecte, voire avec du texte manquant. Cela pose un problème profond, pour des raisons que j’explorerai ci-dessous.
Les problèmes courants incluent :
- Des puces qui ne s’affichent pas correctement
- Des sauts de ligne manquants entre les textes
- Des sauts de ligne excessifs entre les textes
- Le texte écrit par l’utilisateur entièrement supprimé
Et quand je dis que ces problèmes sont courants, je ne veux pas dire qu’ils surviennent occasionnellement lors de l’envoi de courriels dans des langues étrangères à l’aide de clients de messagerie obscurs. Je veux dire qu’ils surviennent fréquemment lors de l’envoi de messages de base par réponse par courriel depuis Gmail et Outlook en anglais.
Voici deux exemples réels d’utilisateurs se plaignant de ces problèmes, tous deux provenant de la liste de diffusion [Python-Dev] :
https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-5
https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-36
(Prettyfwd utilise l’API d’analyse de courriels FWD:Everyone.)
Bien que je n’aie pas essayé d’importer du contenu à partir de listes de diffusion existantes avec Discourse, je peux affirmer par expérience que, quelle que soit le taux d’erreur de la réponse par courriel, le taux d’erreur lors du rendu de fils de discussion complets sera au moins d’un ordre de grandeur supérieur. Cela est dû à la complexité accrue lors de la suppression des signatures et des réponses, de la prise en compte des réponses inline, de la gestion de balisage profondément imbriqué, etc.
Comme exemple concret, ce retour d’expérience sur la migration de Mailman vers Discourse, rédigé par Tanya Lattner (présidente de la fondation LLVM), fait allusion à ces problèmes dans la section des préoccupations techniques :
J’ai posé la question, et il s’avère que la chose spécifique qui les contrarie est le pourcentage élevé de courriels dont le contenu manque en raison d’une truncation prématurée. Comme les discussions et la documentation préexistantes des 19 dernières années de l’archive de la liste de diffusion sont inestimables, ils estiment qu’ils ne pourront pas mettre fin à l’utilisation de Mailman tant que ce problème n’aura pas été entièrement résolu.
Alors, comment savoir si l’état actuel de l’analyse des courriels dans Discourse est « suffisant » ? Je proposerais ce test en trois parties :
- Les utilisateurs doivent avoir pleinement confiance que, s’ils utilisent la fonctionnalité de réponse par courriel, leur contenu sera analysé avec précision et aura l’air aussi bien que s’ils l’avaient publié via l’interface web.
- Les administrateurs de forum doivent avoir confiance que, s’ils autorisent la réponse par courriel, cela ne créera pas de travail supplémentaire ni de plaintes.
- Les employés de Discourse doivent avoir suffisamment confiance dans la fonctionnalité pour la promouvoir activement comme un moyen de participation de premier plan.
Sauf si nous pouvons affirmer avec une entière confiance que chacune de ces conditions est remplie, même si la réponse par courriel existe en tant que fonctionnalité, la grande majorité des avantages potentiels ne seront jamais réalisés.
C’est ce qui se passe actuellement.
Autrement dit, je qualifierais le code d’analyse de courriels existant de solution 80-20, mais dans un contexte où une solution 80-20 n’a pas vraiment de sens ; le problème est que même si, par exemple, 80 % des courriels sont analysés correctement, vous n’obtiendrez probablement même pas 10 % des avantages potentiels.
Ainsi, même si la réponse par courriel (et l’importation de courriels en masse) existent déjà, les utilisateurs n’obtiennent finalement pas l’expérience qu’ils recherchent, du travail supplémentaire est créé pour les modérateurs et le personnel, les communautés perdent du contenu précieux et de la croissance des utilisateurs, etc.
Les avantages d’une meilleure analyse des courriels
Les logiciels sociaux ne réussissent que dans la mesure où ils répondent aux besoins humains.
Les raisons pour lesquelles les gens publient sur des forums web incluent le désir de partager des connaissances avec d’autres, d’influencer leurs opinions, d’être perçus comme généralement intelligents, comme ayant une expertise dans un domaine, comme apportant des contributions réelles précieuses, etc.
Et en ce qui concerne la communication basée sur le texte, la probabilité d’atteindre ces résultats dépend non seulement de ce qui est dit, mais aussi de la typographie avec laquelle on le dit.
C’est pourquoi il existe des livres entiers sur les espaces blancs chez Shakespeare. C’est en partie pourquoi le New York Times est pris plus au sérieux que le New York Post. Et c’est en grande partie pourquoi Facebook a battu MySpace.[1]
Lorsque le texte écrit par un utilisateur se retrouve mal formaté sans faute de sa part, les besoins humains qui poussent les gens à utiliser les logiciels sociaux ne sont plus satisfaits. En fait, c’est l’inverse qui se produit ; les utilisateurs sont rendus ridicules.
Même les personnes qui n’utilisent pas la fonctionnalité de réponse par courriel finissent par perdre en autorité et en respect si d’autres messages dans le sujet (et le forum plus large) finissent par ressembler à un désastre.
Personas des parties prenantes
Bien que tout le monde bénéficie de messages qui s’affichent systématiquement avec une typographie esthétiquement plaisante, les personas utilisateurs qui pourraient particulièrement bénéficier d’une meilleure analyse des courriels entrants incluent :
- Les personnes qui sont actuellement membres de listes de diffusion comme [Python-Dev] et [Django-Dev], qui comprennent pleinement les avantages de Discourse et sont heureuses de voir leurs communautés migrer vers Discourse, mais uniquement si elles peuvent continuer à participer d’une manière indistinguable de GNU Mailman, Google Groups, etc. Voici un exemple réel de ce type de demande : https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-89
- Les membres de communautés basées sur les courriels qui seraient généralement heureux de migrer vers Discourse, mais qui seraient beaucoup plus enthousiastes à l’idée de le faire si leurs décennies de contenu existant étaient facilement recherchables depuis la même plateforme.
- Les utilisateurs occasionnels qui consultent les forums de manière intermittente. Par exemple, sur Growing Fruit, je suis abonné par courriel à tous les sujets concernant la culture du pawpaw nord-américain. Pendant l’été et l’automne, je visite ce forum plusieurs fois par jour pour lire le flux constant de nouveaux messages dans ces sujets, mais en dehors de ces mois, ce sont principalement les notifications par courriel sur ces sujets qui me maintiennent engagé.
- Les personnes qui n’utilisent le web que de manière intermittente. On suppose souvent que si les gens n’utilisent pas régulièrement le web, c’est en quelque sorte lié à la fracture numérique, mais ce n’est souvent pas le cas. Il y a beaucoup de personnes à la fois très intelligentes et techniques, mais qui sont isolées du besoin d’utiliser le web régulièrement en raison de leur position au sommet de leur domaine. Un exemple concret ici est quelqu’un comme Donald Knuth, qui n’utilise pas régulièrement le web malgré le fait d’être l’un des plus grands informaticiens vivants. Chaque domaine compte des personnes comme celle-ci, et les amener à partager leurs connaissances est inestimable. À mon expérience, ces personnes sont peu susceptibles de devenir des contributeurs réguliers à un forum, mais si quelqu’un leur dit qu’il y a un sujet dont les gens discutent et qui les intéresserait, elles s’abonneront souvent par courriel et contribueront à ces sujets spécifiques.
La vue d’ensemble est que l’amélioration de l’analyse des courriels entrants devrait non seulement augmenter l’engagement des personnes qui sont déjà des contributeurs actifs réguliers de Discourse, mais aussi débloquer de nombreuses communautés qui aimeraient sinon migrer vers la plateforme, et également solliciter du contenu très précieux de la part de personnes qui ne contribueraient pas autrement.
L’API d’analyse de courriels FWD:Everyone
L’API d’analyse de courriels FWD:Everyone fait deux choses :
- Elle supprime avec précision les signatures et les réponses de chaque message de courriel, tout en permettant toujours les réponses inline au texte cité.
- Elle prend le balisage HTML extrêmement complexe généré par les clients de messagerie et normalise ce balisage en environ 12 balises HTML généralement autorisées par les sites de contenu généré par les utilisateurs, tout en préservant l’intention de l’auteur dans la mesure du possible.
J’expliquerai les deux en plus de détails, mais voici d’abord une vidéo que j’ai réalisée pour expliquer le problème en montrant des fils de discussion réels : https://www.youtube.com/watch?v=nPb3NQlz6V4
Suppression des signatures et des réponses
L’API d’analyse de courriels FWD:Everyone fonctionne avec la même précision sur les courriels en texte brut et en HTML. L’API utilise préférentiellement la partie HTML du message lorsqu’elle est disponible, car :
- Les fonctionnalités de mise en forme HTML (comme le gras, l’italique, les citations, les extraits de code, etc.) qu’un auteur choisit d’utiliser font partie intégrante du message de l’auteur, aussi importantes que le texte lui-même.
- Lorsque les clients de messagerie convertissent la version HTML d’un message en version texte brut, ils le font souvent incorrectement. Par exemple, non seulement les clients de messagerie ne font souvent aucun effort pour rendre des fonctionnalités HTML comme les listes à puces en texte brut, mais souvent le texte à l’intérieur des éléments de mise en forme HTML est entièrement manquant.
Bien sûr, certains utilisateurs préfèrent envoyer des courriels en texte brut ; par conséquent, les courriels uniquement en texte brut doivent voir leurs signatures et réponses supprimées avec la même précision.
L’API d’analyse de courriels FWD:Everyone le fait, y compris la gestion correcte des réponses inline dans les courriels en texte brut et en HTML.
En termes de précision, il existe deux types d’erreurs qui peuvent survenir dans toute bibliothèque d’analyse de courriels lors de la suppression des signatures et des réponses :
- Faux positifs — Lorsque du texte qui devrait être inclus dans le message est incorrectement exclu.
- Faux négatifs — Lorsque du texte qui ne devrait pas être inclus dans le message est incorrectement inclus.
Il est difficile de donner des statistiques de précision précises car différentes communautés Discourse (avec un petit d) utilisent les courriels de manières très différentes. Mais par rapport à la solution d’analyse actuelle de Discourse, une attente réaliste pourrait être :
- 100 fois moins de faux positifs pour la suppression des signatures et des réponses
- 10 fois moins de faux négatifs pour la suppression des réponses
- 1 à 10 fois moins de faux négatifs pour la suppression des signatures — probablement mieux, mais pas d’un ordre de grandeur complet.
Pour donner un contexte, les faux positifs sont généralement bien pires que les faux négatifs car ils déforment ce que la personne a écrit. Mais les faux négatifs sont aussi très mauvais car ils donnent l’air au posteur (et à tous les autres sur le forum) d’être au mieux peu professionnels, et au pire carrément stupides.
L’approche adoptée par FWD:Everyone consiste à éviter tout tour de magie pour supprimer les signatures qui pourrait entraîner des faux positifs ; l’augmentation apparente des faux négatifs qui en résulterait est ensuite largement compensée par le simple fait d’avoir consacré énormément de travail à faire fonctionner l’algorithme de manière légitime, sans avoir besoin de prendre de raccourcis.
La raison fondamentale pour laquelle l’API d’analyse de courriels FWD:Everyone sera généralement beaucoup plus précise que la solution actuelle de Discourse est que notre API a été conçue pour analyser des fils de discussion complets, ce qui est un problème beaucoup plus difficile que l’analyse de messages de réponse par courriel isolés. Le résultat final est que notre produit est fortement surdimensionné, du moins par rapport aux besoins de Discourse et aux travaux antérieurs existants.
Normalisation du balisage HTML
Pour que les réponses soumises par courriel (et les fils de discussion importés) ressemblent à tout autre contenu généré par les utilisateurs, elles doivent finalement être rendues en utilisant le même sous-ensemble de HTML autorisé lorsque les utilisateurs répondent via le site web.
Cela est étonnamment complexe.
Les courriels composés dans des clients de messagerie comme Gmail et Outlook sont encodés à l’aide d’une combinaison d’environ 50 balises HTML, 25 attributs HTML et 175 styles CSS. De plus, ce balisage est souvent fortement obscurci ; on pourrait s’attendre à ce qu’un paragraphe de texte ressemble à ceci :
<p>Some text!</p>
Mais au lieu de cela, même les paragraphes simples sont souvent encodés à l’aide de combinaisons profondément imbriquées et complètement non sensiques de div, span, tables, listes, etc. C’est la principale source de complexité tant pour la suppression des réponses que pour la normalisation du balisage.
Quoi qu’il en soit, après analyse, chaque message est rendu en utilisant uniquement le balisage suivant :
Éléments de bloc autorisés : <p>, <ul>, <ol>, <li>, <blockquote>, <pre>
Éléments en ligne autorisés : <code>, <a>, <b>, <i>, <u>, <s>, <span>
Remarques :
- Les seuls attributs autorisés (sauf sur les balises
<a>) sont'style'et'dir'. - Le seul style en ligne autorisé est
'font-weight'. - Les balises
<a>peuvent également avoir les attributs'href','rel','title'et'target'. - Les éléments
<span>sont utilisés uniquement dans des cas limités pour s’assurer que les graisses de police s’appliquent correctement. Ainsi, ils sont toujours utilisés avec un'font-weight'en ligne. - À l’avenir, la balise
<img>sera également utilisée pour afficher des images en ligne.
Le rendu des messages dans ce sous-ensemble limité de HTML permet à tout message soumis par courriel d’être facilement rendu en utilisant exactement la même typographie que les messages soumis via l’interface web.
Tout cela est fait tout en préservant l’intention de l’auteur dans la mesure du possible, tout en s’assurant qu’il ne peut pas faire des choses comme ajouter des dizaines de sauts de ligne inutiles entre les paragraphes.
Voir également : la section « Mise en forme avec CSS » ci-dessous.
Prise en charge des langues
EmailReplyTrimmer prend actuellement en charge complètement ou partiellement 13 langues :
Anglais, norvégien, français, allemand, portugais, espagnol, italien, néerlandais, suédois, chinois, russe, polonais, ukrainien
En revanche, l’API d’analyse de courriels FWD:Everyone prend actuellement en charge plus de 30 langues, y compris toutes les langues actuellement prises en charge par Discourse :
Anglais, espagnol, portugais, catalan, néerlandais, français, allemand, italien, norvégien, danois, suédois, finnois, russe, polonais, ukrainien, turc, tchèque, roumain, hongrois, hébreu, arabe, persan, chinois, japonais, coréen, hindi, indonésien, thaï, tagalog, afrikaans
L’API d’analyse de courriels FWD:Everyone prend entièrement en charge les langues RTL. Cela signifie que non seulement le texte s’écoule correctement de droite à gauche dans des langues comme l’arabe, mais également que les attributs appropriés sont appliqués au balisage HTML afin que des fonctionnalités comme les puces s’affichent du bon côté de la page.
L’API fonctionne parfois également dans d’autres langues selon le client de messagerie utilisé, mais l’ensemble officiel de langues prises en charge est au minimum testé pour fonctionner avec Gmail, Outlook et Apple Mail. Les clients de messagerie moins populaires sont explicitement testés dans les langues où ils sont le plus utilisés. Et comme l’API est testée sur des milliers de fils de discussion provenant de listes de diffusion publiques, il existe d’innombrables correctifs pour les comportements erratiques réels d’origine inconnue.
Notez que la prise en charge d’une grande variété de langues est importante non seulement pour afficher du texte dans ces langues. Il est très courant que les gens écrivent du texte en anglais, mais aient leur client de messagerie configuré pour utiliser, par exemple, l’hébreu. Donc, dans de tels cas, analyser correctement une réponse en anglais nécessiterait non seulement de prendre entièrement en charge l’hébreu, mais aussi de prendre en charge les langues de droite à gauche de manière plus générale.
La prise en charge de langues issues de diverses familles linguistiques aide également à s’assurer que l’Unicode est traité et stocké correctement, plutôt que de manière susceptible de causer des problèmes à l’avenir à mesure que le support de plus de langues non occidentales est ajouté.
Mise en forme avec CSS
Comme mentionné ci-dessus, un point fort de notre API est sa capacité à normaliser le balisage HTML de manière réfléchie et logique. Ce processus de normalisation est conçu pour optimiser le texte en termes de lisibilité et d’accessibilité, tout en préservant l’intention originale de l’auteur dans la mesure du possible.
Ainsi, tout le texte n’apparaît que dans des éléments en ligne ou de bloc (pas de texte flottant), et tous les éléments en ligne n’apparaissent que dans des éléments de bloc. Cela facilite la mise en forme du texte, par exemple pour s’assurer que différents éléments ont la bonne quantité d’espaces blancs entre eux.
Comme exemple de la valeur de cela, les clients de messagerie permettent aux utilisateurs de faire des choses absurdes comme insérer une liste à puces directement avant ou après une ligne de texte, sans saut de ligne entre les deux. Le code (vaste simplifié) généré par un client de messagerie lors de cette opération pourrait ressembler à ceci :
<div>
Some text
<div> </div>
<span> • A bullet point</span>
<div> </div>
Some more text
</div>
L’API d’analyse de courriels FWD:Everyone normaliserait alors le balisage ci-dessus pour qu’il ressemble plutôt à ceci :
<p>Some text</p>
<ul>
<li>A bullet point</li>
</ul>
<p>Some more text</p>
Ce balisage normalisé est facile à comprendre et à styliser, et visuellement, il y a maintenant également des sauts de ligne avant et après la liste à puces. Des affordances comme celles-ci rendent le texte plus beau et plus facile à lire, tout en préservant l’intention de l’auteur. Ce type d’affordances utilisateur garantit que le contenu excellent soumis par courriel confère systématiquement un statut social, plutôt que de le saper.
Le balisage simplifié et normalisé généré par notre API garantit également que, lorsqu’il s’agit de réfléchir à la manière de styliser le texte, les concepteurs et les développeurs n’ont besoin de penser qu’à la sortie autorisée par l’API, plutôt qu’à la façon dont le courriel original aurait pu être formaté. Et comme la sortie autorisée par l’API est virtuellement identique à ce que le client web Discourse autorise, cela devrait être une solution quasi plug-and-play.
Intégration proposée
La fonctionnalité de réponse par courriel serait intégrée à Discourse sous forme de plugin, qui pourrait ensuite être activé par défaut pour toutes les instances Discourse hébergées.
Le code d’analyse de courriels existant serait utilisé pour les instances Discourse qui n’ont pas ce plugin activé.
De plus, dans l’éventualité où l’API d’analyse de courriels FWD:Everyone deviendrait temporairement indisponible, tous les messages entrants seraient traités à l’aide du code d’analyse de courriels existant. Une fois l’API de nouveau en ligne, tous les messages qui n’ont pas été modifiés via l’interface web depuis leur publication pourraient alors être retraités par l’API.
Le plugin pourrait également être rendu disponible pour les instances Discourse auto-hébergées, avec activation optionnelle.
Pour les groupes migrant de listes de diffusion existantes vers Discourse, chaque fil de discussion de la liste de diffusion pourrait également être analysé via l’API, mais cela serait probablement intégré aux scripts et processus de migration existants de Discourse plutôt que réalisé via un plugin.[2]
Tests de l’API
L’API est entièrement disponible pour que tout le monde puisse la tester, bien qu’avec une limite de taux très faible pour les utilisateurs non authentifiés.
Pour ceux qui ont des comptes Gmail, les moyens les plus simples de tester l’API sont :
- Se rendre sur https://www.prettyfwd.com et installer le module complémentaire G Suite.
- Se rendre sur https://api-demo.fwdeveryone.com et utiliser l’OAuth côté client pour jouer avec l’API
Les principales différences entre ces deux outils basés sur le web et l’API réelle sont que les premiers :
- Ne traiteront pas les fils de discussion contenant des messages stylisés à l’aide de tableaux HTML
- Ne supprimeront pas les réponses sur le premier message d’un fil de discussion. (Par exemple, si un fil de discussion contient plus de 100 messages, Gmail le divise en plusieurs fils de discussion.)
Pour tester l’API directement via du code, il existe des scripts de démarrage pour Python et Ruby :
Et voici la documentation pertinente, y compris les problèmes connus et la feuille de route du produit :
[1] Viewing American class divisions through Facebook and MySpace.
[2] Lors de l’importation en masse de contenu à partir d’une liste de diffusion existante, il est utile de procéder rapidement à une vérification de bon sens sur quelques fils de discussion pour s’assurer qu’ils sont analysés correctement. Certains groupes seront analysés avec une précision presque parfaite tel quel, mais d’autres pourraient grandement bénéficier de quelques heures de travail préventif. Par exemple, certains logiciels de liste de diffusion nécessitent un peu de code personnalisé pour chaque liste pour supprimer tout texte ajouté au bas de chaque message, tandis que pour d’autres logiciels de liste de diffusion, cela peut être fait de manière prévisible qui fonctionnera pour n’importe quelle liste hébergée sur cette plateforme. En raison de problèmes potentiels comme celui-ci, le processus d’importation en masse devrait de préférence être exécuté dans le cadre d’une migration supervisée plutôt que réalisé via un plugin.