Sendune – concepteur d’e-mails HTML open source

• Éditeur d’e-mails HTML en mode glisser-déposer
• Génère directement du HTML sans code intermédiaire comme MJML
• Prend en charge trois types de modèles de base : conception en glisser-déposer, édition du code HTML, texte brut
  • Possibilité de créer et d’enregistrer ses propres modèles
• Motivation du développement
  • Écrire du HTML pour les e-mails est une tâche très difficile
  • Au moindre écart par rapport aux règles, l’e-mail s’affiche mal sur différents clients OS/desktop/mobile
  • Près de 50 ans après l’invention de l’e-mail et 35 ans après la naissance du HTML, le design d’e-mails n’est toujours pas résolu
  • Il existe quelques bons concepteurs d’e-mails open source, mais leurs dépendances compliquent leur intégration dans une application
  • Pour ces raisons, il a été décidé de publier ce concepteur d’e-mails HTML en open source

[GN⁺]

Avis sur Hacker News

• Selon un avis, l’absence de MJML est une erreur. C’est la fonctionnalité la plus importante pour la conception d’e-mails
• Le design a l’air excellent. Je vais l’essayer
• Vraiment excellent. Je me demande s’il est possible d’ajouter des styles responsives, par exemple convertir des colonnes en lignes sur les petits écrans
• Le glisser-déposer ne fonctionne pas. Sur Firefox, macOS, les éléments apparaissent quand on clique dessus, mais il est impossible de les faire glisser dans l’e-mail
• Ce projet semble très prometteur. Le « HTML pour les e-mails » est difficile à concevoir et à implémenter, en particulier sur mobile, tablette ou avec la saisie en langues asiatiques
  • Je travaille sur beaucoup de modèles d’e-mails pour un CRM B2B et j’ai choisi une autre approche basée sur l’éditeur slatejs/platejs
  • La représentation interne des modèles d’e-mails dans slatejs/platejs est au format JSON, ce qui permet de les stocker facilement dans Postgres jsonb
  • Il est facile d’ajouter des widgets basés sur Reactjs. Par exemple : mentions, médias, diagrammes, etc.
  • L’inconvénient est qu’il n’est pas possible de concevoir des modèles avec une précision au pixel près
  • Une meilleure abstraction serait probablement MJML. Cependant, avec le format JSON de slatejs/platejs, on peut copier-coller le contenu édité vers divers actifs comme le CRM, la base de connaissances, etc.
  • Stocker les données en MJML n’est pas une bonne option
  • J’avais envisagé d’utiliser quelque chose de similaire à SendWithSES/Drag-and-Drop-Email-Designer comme étape finale, mais la plupart des utilisateurs finaux s’en moquent
  • Les avis sur la représentation des données et le flux « Postgres <> Editor > Email HTML > Send button » sont les bienvenus. Très peu de gens réfléchissent sérieusement à ce sujet
• Selon un avis, toute l’idée de départ est absurde
  • Je reconnais que beaucoup de gens veulent des e-mails riches en mise en forme avec des images et des logos. Ce n’est pas mon cas, mais je comprends les besoins et les envies des autres
  • Pourquoi du HTML ? Un langage de balisage simple (Markdown, orgmode, etc.) aurait suffi, sans qu’il soit nécessaire d’avoir une version texte brut séparée et une version HTML. Cela aurait été plus accessible pour les lecteurs d’écran et autres dispositifs d’assistance, moins intrusif pour la vie privée et moins vulnérable aux problèmes de sécurité
  • Mais la réponse a été : « mettons un navigateur web complet dans tous les clients e-mail »
  • Je sais bien qu’il est trop tard pour revenir en arrière
• View -> Message Body As -> Plain Text
  • Ce n’est pas de ma faute, mais il faut toujours fournir un texte alternatif
• Quiconque a déjà travaillé avec des e-mails HTML connaît la difficulté. Bravo pour l’avoir développé et open sourcé. Je vais probablement l’utiliser pour une newsletter
• J’ai brièvement cherché quelque chose comme ça il y a quelques jours. Je vais regarder. Merci
• Je ne m’y attendais pas. Je vais répondre aux questions pendant quelques heures