Vanilla Email Designer

Vanilla Email Designer : un éditeur visuel de newsletters en JavaScript natif

Créer une newsletter en HTML reste un exercice étonnamment délicat. Là où une page web moderne peut s’appuyer sur des frameworks, des feuilles de styles élaborées et du JavaScript, un courrier électronique doit composer avec des clients de messagerie aux capacités très différentes.

C’est de ce constat qu’est né Vanilla Email Designer, un éditeur visuel open source permettant de construire des newsletters sans avoir à écrire directement leur code HTML.

Le projet fait volontairement un choix différent de nombreuses solutions existantes : aucun framework JavaScript, aucune dépendance à jQuery et aucune étape de compilation. Vanilla Email Designer est développé en JavaScript natif — le fameux Vanilla JavaScript.

Un éditeur conçu pour être intégré à une application existante

Vanilla Email Designer n’est pas un service d’envoi de newsletters et n’a pas vocation à le devenir.

Il s’agit d’un composant autonome que les développeurs peuvent intégrer à leur propre application web.

L’éditeur prend en charge la construction visuelle du message tandis que l’application qui l’héberge conserve la responsabilité de la gestion des utilisateurs, de la médiathèque, du stockage des newsletters et, naturellement, de leur expédition.

Cette séparation permet de ne pas imposer une architecture particulière. Une application développée en PHP, Python, Go, Node.js ou avec une autre technologie côté serveur peut utiliser le même éditeur.

Une construction par composants

La newsletter est constituée à partir de blocs que l’utilisateur ajoute et organise visuellement.

Vanilla Email Designer propose notamment :

  • une image d’en-tête ;
  • des titres ;
  • des zones de texte enrichi ;
  • des images ;
  • des boutons d’action ;
  • des séparateurs ;
  • des espacements ;
  • des structures à une ou deux colonnes ;
  • un bas de page comprenant les liens réglementaires et les réseaux sociaux.

Les éléments peuvent être déplacés, dupliqués ou supprimés. Les colonnes peuvent elles-mêmes recevoir différents contenus tels que du texte, une image ou un bouton.

L’objectif est de permettre à l’utilisateur de construire un message relativement élaboré sans avoir à connaître le HTML utilisé derrière l’interface.

Vanilla Email Designer

Modifier le texte directement dans la newsletter

Les zones de texte sont éditables directement dans la composition.

Une barre d’outils permet d'appliquer les opérations habituelles :

gras, italique, souligné, taille et couleur du texte, alignement à gauche, centré, à droite ou justifié, ainsi que création de liens.

Le collage de textes provenant d’autres applications est également contrôlé afin d’éviter d’importer dans la newsletter une quantité de balises et de styles parasites.

Cette question est particulièrement importante pour les newsletters : copier quelques paragraphes depuis un traitement de texte peut autrement produire un HTML considérablement plus complexe que le texte visible ne le laisse supposer.

Des en-têtes et pieds de page protégés

Certains composants possèdent volontairement un comportement particulier.

Une newsletter ne peut comporter qu’un seul en-tête et un seul bas de page. L’en-tête reste en première position tandis que le bas de page reste à la fin du document.

Cette protection évite qu’une manipulation accidentelle ne produise une structure incohérente.

Le bas de page peut notamment comporter le lien de désabonnement, un lien vers une version en ligne du message ainsi que des liens accompagnés de pictogrammes vers des réseaux sociaux ou d’autres sites.

Les URL propres à chaque destinataire peuvent être injectées au moment de l’envoi grâce à des variables telles que :

{{unsubscribe_url}}
{{online_url}}

 
C’est ensuite au logiciel utilisant Vanilla Email Designer de remplacer ces variables par les véritables adresses.

Une médiathèque laissée à l’application

L’une des décisions d’architecture importantes concerne les images.

Vanilla Email Designer n’impose aucun système de téléchargement ni de stockage des fichiers. Il expose à la place une fonction permettant à l’application qui l’intègre de connecter sa propre médiathèque.

Un CMS peut donc conserver son gestionnaire de médias existant et simplement retourner à l’éditeur l’URL et le texte alternatif de l’image sélectionnée.

Cette approche évite de transformer l’éditeur en gestionnaire de fichiers et facilite son intégration dans des logiciels déjà existants.

Deux représentations d’une même newsletter

L’éditeur distingue volontairement le document de travail du message qui sera envoyé.

Le premier est enregistré sous forme de JSON. Il décrit les composants, leur ordre et leurs propriétés. C’est ce fichier qui permet de rouvrir ultérieurement la newsletter dans l’éditeur et de continuer à la modifier.

Le second est le HTML destiné à l’email.

Cette séparation est importante :

JSON → document éditable
HTML → document destiné à l'envoi

Une application peut ainsi conserver les deux représentations en base de données.

Le HTML des emails n’est pas celui du Web moderne

Vanilla Email Designer doit tenir compte d’une contrainte fondamentale : un email HTML n’est pas une page web.

Les différents clients de messagerie n’interprètent pas tous le HTML et le CSS de la même façon. Certaines techniques parfaitement ordinaires sur un site web deviennent donc problématiques dans un courrier électronique.

L’export produit par Vanilla Email Designer privilégie en conséquence des structures HTML relativement conservatrices, notamment des tableaux de présentation lorsque cela améliore la compatibilité.

L’éditeur propose également un aperçu ordinateur et mobile, et les structures à deux colonnes peuvent être réorganisées sur les écrans étroits.

Cela ne dispense naturellement pas de tester une campagne importante dans plusieurs clients de messagerie : l’uniformité absolue du rendu des emails HTML reste pratiquement impossible à garantir.

Et les images intégrées aux emails ?

Vanilla Email Designer génère des balises images classiques mais laisse volontairement le traitement final à l’application d’envoi.

Celle-ci peut donc choisir de conserver des images distantes ou, comme c’est le cas dans certaines intégrations, de les transformer en pièces jointes CID afin qu’elles soient incorporées directement au courrier électronique.

L’éditeur ne dépend ainsi d’aucune stratégie particulière d’expédition.

Une interface internationalisable

Le projet a été conçu dès sa première publication publique pour pouvoir être traduit.

L’anglais constitue la langue par défaut. Une traduction française est fournie avec le projet.

Ajouter une autre langue consiste essentiellement à fournir un nouveau dictionnaire de traduction :

src/lang/
├── en.js
├── fr.js
└── ...

Les traductions peuvent également être surchargées partiellement par l’application qui intègre l’éditeur.

Cette architecture doit permettre à la communauté d’ajouter progressivement d’autres langues sans modifier le cœur du logiciel.

Pourquoi « Vanilla » ?

Le nom Vanilla Email Designer résume l’un des principes du projet.

Le cœur est développé en JavaScript natif.

Pas de React.
Pas de Vue.
Pas d’Angular.
Pas de jQuery.
Pas de chaîne de compilation obligatoire.

Cette sobriété a plusieurs avantages : le composant reste relativement facile à intégrer, son fonctionnement ne dépend pas du framework choisi par le projet hôte et un développeur peut directement examiner ou modifier ses sources.

Une intégration minimale ressemble ainsi à ceci :

import EmailDesigner from './src/EmailDesigner.js';
import fr from './src/lang/fr.js';

const editor = new EmailDesigner('#emailDesigner', {
    translations: fr
});

Et l’application peut ensuite récupérer séparément le projet et son HTML :

const project = editor.getData();
const html = editor.getHtml();

Un projet né d’un besoin réel

Vanilla Email Designer n’a pas été conçu comme un exercice théorique.

Son développement est issu d’un besoin rencontré lors de l’évolution de BlogThèque : remplacer un système de composition de newsletters devenu trop dépendant d’un éditeur de texte classique par un véritable constructeur visuel.

Le composant a donc été développé puis testé dans une application réelle, avec sauvegarde et réouverture des newsletters, utilisation d’une médiathèque existante et envoi effectif des messages.

Une fois cette intégration fonctionnelle, il est apparu que l’éditeur pouvait présenter un intérêt pour d’autres développeurs et webmasters. Le code a alors été progressivement débarrassé de ses dépendances spécifiques à BlogThèque, internationalisé et documenté pour devenir un projet autonome.

Une construction assistée par intelligence artificielle

Vanilla Email Designer est un projet initié, dirigé et validé par François Milhiet.

Sa conception et son développement ont été réalisés en collaboration avec ChatGPT d’OpenAI, au fil d’une série de prompts, d’analyses, d’itérations et de validations.

Les orientations fonctionnelles, les choix d’architecture, les arbitrages, les essais en conditions réelles et la validation finale restent conduits par l’initiateur du projet. ChatGPT intervient comme assistant de conception, de programmation, de documentation et de contrôle.

Cette méthode de développement assisté par intelligence artificielle fait partie intégrante de l’histoire de Vanilla Email Designer et est indiquée dans un souci de transparence.

Un logiciel libre sous licence AGPL v3

Vanilla Email Designer est désormais disponible en open source sous licence copyleft GNU Affero General Public License v3.0 (AGPL-3.0).

Le dépôt contient le code source de l’éditeur, les fichiers de langues, les pictogrammes, une démonstration autonome ainsi qu’une documentation destinée aux développeurs souhaitant l’intégrer à leur propre projet.

La première version publique est la v0.1.3.

Le projet est encore jeune. Cette première publication constitue surtout une base désormais fonctionnelle et utilisable, destinée à évoluer au gré des besoins rencontrés en production et, éventuellement, des contributions de nouveaux utilisateurs.