Negli ultimi mesi, sono giunte numerose richieste da diverse comunità Discourse per migliorare l’analisi delle email in arrivo. Espressi come user story, questi richieste possono essere raggruppati in tre categorie principali:
- “Vorrei poter utilizzare le stesse funzionalità HTML quando rispondo via email che uso quando pubblico sul sito web.”
- “Vorrei poter visualizzare e cercare i messaggi provenienti dalla nostra mailing list.”
- “Vorrei che i contenuti creati via email, sia tramite risposta diretta che tramite importazione massiva, venissero sempre formattati in modo ordinato e analizzati con precisione.”
Di seguito collegherò esempi reali di queste richieste, ma per ora è importante comprendere che ciascuna di queste tre richieste apparentemente diverse chiede in realtà la stessa cosa fondamentale: un’analisi più accurata delle email in arrivo.
Qualche mese fa ho scritto a @sam per proporre l’attivazione di Discourse per utilizzare la API commerciale di analisi delle email offerta dalla nostra azienda. Sam ha suggerito di creare un post esplorativo qui per spiegare i vantaggi che l’integrazione con la nostra API offrirebbe rispetto alla soluzione attuale di analisi delle email in arrivo di Discourse, nonché come la nostra API potrebbe essere integrata come plugin.
Tratterò entrambi gli argomenti in dettaglio, partendo dallo stato attuale della soluzione di analisi delle email di Discourse. E a beneficio di chi non ha dedicato gli ultimi anni a riflettere sull’analisi delle email, includerò anche alcuni contesti di base sul problema.
Questo post è piuttosto lungo, ma sentitevi liberi di saltare alle sezioni che vi interessano. Ecco cosa verrà trattato:
- Lo stato attuale dell’analisi delle email in Discourse
- I vantaggi di un’analisi delle email più accurata
- Personaggi utente delle parti interessate
- La FWD:Everyone Email Parsing API
A. Rimozione delle firme e delle risposte
B. Normalizzazione del markup HTML
C. Supporto linguistico
D. Stile con CSS - Integrazione proposta
- Test dell’API
Lo stato attuale dell’analisi delle email in Discourse
Discourse dispone già di una funzionalità di risposta via email che trasforma le risposte email degli utenti in nuovi post del forum all’interno di un argomento. Questa funzionalità funziona così:
- Un utente riceve una notifica email contenente un nuovo post su un argomento del forum che sta seguendo.
- L’utente risponde a questa email.
- Questa risposta email viene trasformata in un nuovo post nell’argomento del forum pertinente.
Concettualmente, questa è una funzionalità preziosa; è il flusso di lavoro preferito da molte persone ed è essenziale per molte comunità basate su mailing list che stanno valutando la migrazione a Discourse.
Il problema è che quando queste risposte email vengono trasformate in post del forum, spesso vengono renderizzate con formattazione mancante o errata, o addirittura con testo mancante. Questo è profondamente problematico, per motivi che esplorerò di seguito.
I problemi comuni includono:
- Punti elenco che non vengono renderizzati correttamente
- A capo mancanti tra i testi
- A capo extra tra i testi
- Testo scritto dall’utente eliminato completamente
E quando dico che questi problemi sono comuni, non intendo che si verificano occasionalmente quando si inviano email in lingue straniere utilizzando client di posta poco diffusi. Piuttosto, intendo che si verificano frequentemente quando si inviano semplici messaggi di risposta via email da Gmail e Outlook in inglese.
Ecco due esempi reali di utenti che lamentano questi problemi, entrambi dalla mailing list [Python-Dev]:
https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-5
https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-36
(Prettyfwd utilizza la FWD:Everyone Email Parsing API.)
Anche se non ho provato a importare contenuti da mailing list esistenti con Discourse, posso dire per esperienza che, indipendentemente dal tasso di errore per le risposte via email, il tasso di errore quando si renderizzano intere thread di email sarà almeno di un ordine di grandezza superiore. Ciò è dovuto alla maggiore complessità nella rimozione di firme e risposte, nel tenere conto delle risposte inline, nella gestione di markup profondamente nidificati, ecc.
Come esempio reale, questo resoconto sulla migrazione da Mailman a Discourse scritto da Tanya Lattner (presidente della fondazione LLVM) accenna a questi problemi nella sezione delle preoccupazioni tecniche:
Ho chiesto e si è scoperto che la cosa specifica che li infastidisce è l’alta percentuale di email a cui manca del contenuto a causa di un troncamento prematuro. Poiché le discussioni preesistenti e la documentazione degli ultimi 19 anni dell’archivio della mailing list sono preziose, ritengono di non poter disattivare Mailman finché questo problema non sarà completamente risolto.
Quindi, come possiamo sapere se lo stato attuale dell’analisi delle email in Discourse è «sufficientemente buono»? Offrirei questo come un test di verifica in tre parti:
- Gli utenti devono avere piena fiducia che, se utilizzano la funzionalità di risposta via email, il loro contenuto verrà analizzato con precisione e apparirà esattamente come se fosse stato pubblicato tramite l’interfaccia web.
- Gli amministratori del forum devono avere fiducia che, se abilitano la risposta via email, ciò non creerà lavoro extra e lamentele.
- I dipendenti di Discourse devono avere abbastanza fiducia nella funzionalità da promuoverla attivamente come un modo di primo livello per partecipare.
A meno che non possiamo affermare con piena fiducia che ciascuna di queste condizioni sia soddisfatta, anche se la risposta via email esiste come funzionalità, la stragrande maggioranza dei potenziali benefici non si realizzerà mai.
Questo è ciò che sta accadendo attualmente.
Cioè, definirei il codice esistente di analisi delle email come una soluzione 80-20, ma in un contesto in cui una soluzione 80-20 non ha davvero senso; il problema è che anche se, ad esempio, l’80% delle email viene analizzato correttamente, è improbabile che si ottenga nemmeno il 10% dei potenziali benefici.
Quindi, anche se la risposta via email (e l’importazione massiva di email) esistono già, gli utenti non ottengono l’esperienza che cercano, viene creato lavoro extra per moderatori e personale, le comunità perdono contenuti preziosi e crescita degli utenti, ecc.
I vantaggi di un’analisi delle email più accurata
Il software sociale ha successo solo nella misura in cui soddisfa i bisogni umani.
Le ragioni per cui le persone pubblicano su forum web includono il desiderio di condividere conoscenze con gli altri, influenzare le loro opinioni, essere visti come generalmente intelligenti, avere competenze specifiche nel settore, apportare contributi preziosi nel mondo reale, ecc.
E quando si tratta di comunicazione basata sul testo, la probabilità di ottenere questi risultati dipende non solo da ciò che viene detto, ma anche dalla tipografia con cui viene detto.
È per questo motivo che esistono interi libri sullo spazio bianco in Shakespeare. È in parte il motivo per cui il New York Times è preso più sul serio rispetto al New York Post. Ed è una grande parte del motivo per cui Facebook ha battuto MySpace.[1]
Quando il testo scritto da un utente finisce per essere mal formattato senza alcuna colpa sua, i bisogni umani che spingono le persone a utilizzare software sociale non vengono più soddisfatti. In realtà, sta accadendo il contrario; gli utenti vengono fatti sembrare stupidi.
Anche le persone che non utilizzano la funzionalità di risposta via email finiscono per perdere autorità e rispetto se altri post nell’argomento (e nel forum più ampio) finiscono per sembrare un disastro.
Personaggi utente delle parti interessate
Mentre tutti beneficiano quando i post vengono renderizzati in modo coerente con una tipografia esteticamente gradevole, i personaggi utente che potrebbero beneficiare in modo particolare di un’analisi delle email in arrivo più accurata includono:
- Persone che sono attualmente membri di mailing list come [Python-Dev] e [Django-Dev], che comprendono appieno i vantaggi di Discourse e sono felici di vedere le loro comunità migrate su Discourse, ma solo se possono continuare a partecipare in un modo indistinguibile da GNU Mailman, Google Groups, ecc. Ecco un esempio reale di questo tipo di richiesta: https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-89
- Membri di comunità basate su email che sarebbero generalmente felici di migrare su Discourse, ma che sarebbero molto più entusiasti di farlo se i loro decenni di contenuti esistenti fossero facilmente ricercabili all’interno della stessa piattaforma.
- Utenti occasionali che controllano i forum in modo intermittente. Ad esempio, su Growing Fruit sono iscritto via email a tutti gli argomenti riguardanti la coltivazione di pawpaw nordamericani. Durante l’estate e l’autunno visito quel forum diverse volte al giorno per leggere il flusso costante di nuovi post in questi argomenti, ma fuori da questi mesi sono principalmente le notifiche email su questi argomenti a tenermi coinvolto.
- Persone che usano il web solo in modo intermittente. Spesso si presume che se le persone non usano regolarmente il web, ciò sia in qualche modo legato al divario digitale, ma spesso non è così. Ci sono molte persone che sono sia altamente intelligenti che tecniche, ma che sono isolate dalla necessità di utilizzare il web su base regolare perché si trovano al vertice dei loro campi. Un esempio reale qui è qualcuno come Donald Knuth, che non utilizza regolarmente il web nonostante sia uno dei più grandi scienziati informatici viventi. Ogni campo ha persone come questa, e farle condividere le loro conoscenze è inestimabile. Per esperienza, queste persone è improbabile che diventino contributori regolari di qualsiasi forum, ma se qualcuno dice loro che c’è un argomento di cui le persone stanno discutendo che potrebbe interessarle, spesso si iscrivono via email e contribuiscono a quegli argomenti specifici.
Il quadro generale è che migliorare l’analisi delle email in arrivo non dovrebbe solo aumentare l’engagement da parte di persone che sono già contributori attivi regolari di Discourse, ma dovrebbe anche sbloccare molte comunità che altrimenti vorrebbero migrare sulla piattaforma e sollecitare contenuti altamente preziosi da parte di persone che altrimenti non contribuirebbero.
La FWD:Everyone Email Parsing API
La FWD:Everyone Email Parsing API fa due cose:
- Rimuove con precisione firme e risposte da ogni messaggio email, consentendo comunque risposte inline al testo citato.
- Prende il markup HTML estremamente complesso generato dai client di posta e normalizza quel markup nei ~12 tag HTML tipicamente consentiti dai siti di contenuti generati dagli utenti, preservando al contempo l’intenzione dell’autore nella misura massima possibile.
Spiegherò entrambi in dettaglio, ma prima ecco un video che ho realizzato che spiega il problema mostrando thread di email reali: https://www.youtube.com/watch?v=nPb3NQlz6V4
Rimozione delle firme e delle risposte
La FWD:Everyone Email Parsing API funziona con la stessa accuratezza sia su email in testo semplice che in HTML. L’API utilizza preferenzialmente la parte del messaggio HTML quando disponibile, perché
- Le funzionalità di formattazione HTML (come grassetto, corsivo, citazioni, snippet di codice, ecc.) che un autore sceglie di utilizzare sono una parte essenziale del messaggio dell’autore, tanto importanti quanto il testo stesso.
- Quando i client di posta convertono la versione HTML di un messaggio nella versione in testo semplice, spesso lo fanno in modo errato. Ad esempio, non solo i client di posta spesso non tentano di renderizzare funzionalità HTML come elenchi puntati in testo semplice, ma spesso il testo all’interno degli elementi di formattazione HTML sarà completamente assente.
Naturalmente, alcuni utenti preferiscono inviare email in testo semplice; per questo motivo, le email solo in testo semplice devono avere le firme e le risposte rimosse con la stessa accuratezza.
La FWD:Everyone Email Parsing API fa questo, gestendo correttamente le risposte inline sia nelle email in testo semplice che in quelle in HTML.
In termini di accuratezza, ci sono due tipi di errori che possono verificarsi in qualsiasi libreria di analisi delle email quando si rimuovono firme e risposte:
- Falsi positivi — Quando il testo che dovrebbe essere incluso nel messaggio viene erroneamente escluso.
- Falsi negativi — Quando il testo che non dovrebbe essere incluso nel messaggio viene erroneamente incluso.
È difficile fornire statistiche di accuratezza precise perché diverse comunità Discourse (con la d minuscola) utilizzano l’email in modo molto diverso. Ma rispetto alla soluzione attuale di analisi di Discourse, un’aspettativa realistica potrebbe essere:
- 100 volte meno falsi positivi per la rimozione di firme e risposte
- 10 volte meno falsi negativi per la rimozione delle risposte
- 1-10 volte meno falsi negativi per la rimozione delle firme — probabilmente meglio, ma non di un intero ordine di grandezza.
Per contesto, i falsi positivi sono generalmente molto peggiori dei falsi negativi poiché distorcono ciò che la persona ha scritto. Ma anche i falsi negativi sono molto gravi poiché fanno sembrare il postatore (e tutti gli altri nel forum) poco professionali al meglio, e completamente stupidi al peggio.
L’approccio adottato da FWD:Everyone è quello di evitare qualsiasi trucco per rimuovere le firme che potrebbe portare a falsi positivi; l’aumento apparente dei falsi negativi che ciò comporterebbe viene poi in gran parte compensato dal fatto di aver dedicato un’enorme quantità di lavoro a far funzionare l’algoritmo in modo legittimo, senza bisogno di tagliare gli angoli.
La ragione principale per cui la FWD:Everyone Email Parsing API sarà generalmente molto più accurata della soluzione attuale di Discourse è che la nostra API è stata progettata per analizzare intere thread di email, il che è un problema molto più difficile rispetto all’analisi di singoli post di risposta via email. Il risultato finale è che il nostro prodotto è altamente sovradimensionato, almeno rispetto sia alle esigenze di Discourse che alle opere precedenti esistenti.
Normalizzazione del markup HTML
Affinché le risposte inviate via email (e le thread di email importate) abbiano lo stesso aspetto di qualsiasi altro contenuto generato dall’utente, devono infine essere renderizzate utilizzando lo stesso sottoinsieme di HTML consentito quando gli utenti rispondono tramite il sito web.
Questo è sorprendentemente complicato.
Le email composte in client di posta come Gmail e Outlook sono codificate utilizzando una combinazione di ~50 tag HTML, ~25 attributi HTML e ~175 stili CSS. Inoltre, questo markup è spesso pesantemente offuscato; ci si aspetterebbe che un paragrafo di testo assomigli a questo:
<p>Alcun testo!</p>
Ma invece, anche i paragrafi semplici sono spesso codificati utilizzando combinazioni profondamente nidificate e completamente insensate di div, span, tabelle, elenchi, ecc. Questa è la principale fonte di complessità sia per la rimozione delle risposte che per la normalizzazione del markup.
In ogni caso, dopo l’analisi, ogni messaggio viene renderizzato utilizzando solo il seguente markup:
Elementi di blocco consentiti: <p>, <ul>, <ol>, <li>, <blockquote>, <pre>
Elementi inline consentiti: <code>, <a>, <b>, <i>, <u>, <s>, <span>
Note:
- Gli unici attributi consentiti (tranne sui tag
<a>) sono'style'e'dir'. - L’unico stile inline consentito è
'font-weight'. - I tag
<a>possono anche avere gli attributi'href','rel','title'e'target'. - Gli elementi
<span>sono utilizzati solo in casi limitati per garantire che i font-weight vengano ereditati correttamente. Pertanto, vengono sempre utilizzati con uno stile inline'font-weight'. - In futuro, anche il tag
<img>verrà utilizzato per visualizzare immagini inline.
La renderizzazione dei post in questo sottoinsieme limitato di HTML consente a qualsiasi post inviato via email di essere facilmente renderizzato utilizzando esattamente la stessa tipografia dei post inviati tramite l’interfaccia web.
Tutto ciò viene fatto preservando l’intenzione dell’autore nella misura massima possibile, garantendo al contempo che non possano fare cose come aggiungere dozzine di a capo non necessari tra i paragrafi.
Vedi anche: la sezione «Stile con CSS» di seguito.
Supporto linguistico
EmailReplyTrimmer attualmente ha supporto completo o parziale per 13 lingue:
Inglese, Norvegese, Francese, Tedesco, Portoghese, Spagnolo, Italiano, Olandese, Svedese, Cinese, Russo, Polacco, Ucraino
Al contrario, la FWD:Everyone Email Parsing API supporta attualmente oltre 30 lingue, incluse tutte le lingue attualmente supportate da Discourse:
Inglese, Spagnolo, Portoghese, Catalano, Olandese, Francese, Tedesco, Italiano, Norvegese, Danese, Svedese, Finlandese, Russo, Polacco, Ucraino, Turco, Ceco, Rumeno, Ungherese, Ebraico, Arabo, Persiano, Cinese, Giapponese, Coreano, Hindi, Indonesiano, Thai, Filippino, Afrikaans
La FWD:Everyone Email Parsing API supporta pienamente le lingue RTL. Ciò significa che non solo il testo scorrerà correttamente da destra a sinistra in lingue come l’arabo, ma verranno anche applicati gli attributi appropriati al markup HTML in modo che funzionalità come i punti elenco vengano renderizzate sul lato corretto della pagina.
L’API funzionerà talvolta anche in lingue aggiuntive a seconda del client di posta utilizzato, ma l’insieme ufficiale di lingue supportate è stato testato almeno per funzionare con Gmail, Outlook e Apple Mail. I client di posta meno popolari sono testati esplicitamente nelle lingue in cui hanno il maggior utilizzo. E poiché l’API viene testata contro migliaia di thread di email da mailing list pubbliche, ci sono innumerevoli correzioni per comportamenti erratici reali di origine sconosciuta.
Nota che supportare una vasta gamma di lingue è importante non solo per visualizzare il testo in quelle lingue. È molto comune che le persone scrivano testo in inglese, ma abbiano il client di posta configurato per utilizzare, ad esempio, l’ebraico. Quindi, in casi come questo, analizzare correttamente una risposta in inglese richiederebbe non solo il pieno supporto dell’ebraico, ma anche il supporto delle lingue da destra a sinistra in generale.
Il supporto di lingue provenienti da una vasta gamma di famiglie linguistiche aiuta anche a garantire che l’Unicode venga elaborato e archiviato correttamente, piuttosto che in modi che potrebbero causare problemi in futuro man mano che viene aggiunto il supporto per più lingue non occidentali.
Stile con CSS
Come accennato in precedenza, un punto di forza della nostra API è la sua capacità di normalizzare il markup HTML in modo ponderato e logico. Questo processo di normalizzazione è progettato per ottimizzare il testo per la leggibilità e l’accessibilità, preservando al contempo l’intenzione originale dell’autore nella misura massima possibile.
Di conseguenza, tutto il testo appare solo all’interno di elementi inline o di blocco (nessun testo fluttuante libero), e tutti gli elementi inline appaiono solo all’interno di elementi di blocco. Questo rende facile stilizzare il testo, ad esempio per garantire che diversi elementi abbiano la quantità corretta di spazio bianco tra loro.
Come esempio di quanto ciò sia prezioso, i client di posta consentono agli utenti di fare cose assurde come inserire un elenco puntato direttamente prima o dopo una riga di testo, senza un a capo in mezzo. Il codice (vasto semplificato) generato da un client di posta quando si fa ciò potrebbe assomigliare a questo:
<div>
Alcuni testo
<div> </div>
<span> • Un punto elenco</span>
<div> </div>
Ancora più testo
</div>
La FWD:Everyone Email Parsing API normalizzerebbe quindi il markup sopra in modo che assomigli invece a questo:
<p>Alcuni testo</p>
<ul>
<li>Un punto elenco</li>
</ul>
<p>Ancora più testo</p>
Questo markup normalizzato è facile da comprendere e stilizzare, e visivamente ora ci sono anche a capo prima e dopo l’elenco puntato. Affordanze come queste rendono il testo più bello e più facile da leggere, preservando l’intento dell’autore. Questi tipi di affordance utente assicurano che i contenuti eccellenti inviati via email conferiscano costantemente status sociale, invece di minarlo.
Il markup semplificato e normalizzato generato dalla nostra API garantisce anche che, quando si pensa a come stilizzare il testo, i designer e gli sviluppatori debbano pensare solo a quale output l’API consente, piuttosto che a come potrebbe essere stato formattato l’email originale. E poiché l’output consentito dall’API è virtualmente identico a ciò che consente il client web di Discourse, ciò dovrebbe essere quasi una soluzione plug-and-play.
Integrazione proposta
La funzionalità di risposta via email verrebbe integrata con Discourse come plugin, che potrebbe quindi essere abilitato per default per tutte le istanze di Discourse ospitate.
Il codice esistente di analisi delle email verrebbe utilizzato per le istanze di Discourse che non hanno questo plugin abilitato.
Inoltre, nel caso in cui la FWD:Everyone Email Parsing API diventasse temporaneamente non disponibile, qualsiasi messaggio in arrivo verrebbe elaborato utilizzando il codice esistente di analisi delle email. Una volta che l’API sarà di nuovo online, qualsiasi messaggio che non è stato modificato tramite l’interfaccia web dalla pubblicazione potrebbe quindi essere riesaminato dall’API.
Il plugin potrebbe anche essere reso disponibile per le istanze di Discourse auto-ospitate da abilitare opzionalmente.
Per i gruppi che migrano da mailing list esistenti a Discourse, ogni thread di email sulla mailing list potrebbe anche essere analizzato tramite l’API, ma questo verrebbe probabilmente integrato negli script e nei processi di migrazione esistenti di Discourse piuttosto che fatto tramite un plugin.[2]
Test dell’API
L’API è completamente disponibile per chiunque per testarla, sebbene con un limite di velocità molto basso per gli utenti non autenticati.
Per chi ha account Gmail, i modi più semplici per testare l’API sono:
- Andare su https://www.prettyfwd.com e installare il componente aggiuntivo G Suite.
- Andare su https://api-demo.fwdeveryone.com e utilizzare l’OAuth lato client per giocare con l’API
Le differenze chiave tra questi due strumenti basati sul web e l’API effettiva sono che i primi:
- Non elaboreranno thread che contengono messaggi stilizzati utilizzando tabelle HTML
- Non rimuoveranno le risposte sul primo messaggio di un thread. (Ad esempio, se un thread ha oltre 100 messaggi, quindi Gmail lo divide in più thread.)
Per testare l’API direttamente tramite codice, ci sono script di avvio sia per Python che per Ruby:
E qui c’è la documentazione pertinente, inclusi problemi noti e la roadmap del prodotto:
[1] Viewing American class divisions through Facebook and MySpace.
[2] Quando si importa in massa contenuti da una mailing list esistente, vale la pena fare prima un rapido controllo di sanità mentale su alcuni thread per assicurarsi che vengano analizzati correttamente. Alcuni gruppi verranno analizzati con un’accuratezza quasi perfetta così come sono, ma altri potrebbero beneficiare notevolmente di un paio di ore di lavoro preventivo. Ad esempio, alcuni software per mailing list richiedono un po’ di codice personalizzato per ogni lista per rimuovere qualsiasi testo aggiunto in fondo a ogni messaggio, mentre per altri software per mailing list questo può essere fatto in modo prevedibile che funzionerà per qualsiasi lista ospitata su quella piattaforma. A causa di potenziali problemi come questo, il processo di importazione massiva dovrebbe preferibilmente essere eseguito come parte di una migrazione supervisionata piuttosto che fatto tramite un plugin.