Un éditeur d’email intégré qui semble natif

Intégrez l’éditeur d’email à votre produit avec un parcours cohérent, un thème adapté, des commandes localisées et des vérifications concrètes d’accessibilité.

Weavour4 min de lecture
Une zone d’édition en papier dans un cadre sombre, à côté d’échantillons de matières assortis.

Un éditeur d’email intégré peut reprendre votre couleur de marque et donner malgré tout l’impression de quitter votre produit. Les utilisateurs remarquent une navigation différente, des états d’enregistrement inhabituels ou un changement de langue qui semble toucher leur travail.

L’impression d’une expérience native vient de la continuité. Commencez par le parcours, puis utilisez les réglages d’apparence disponibles pour rendre la transition visuellement cohérente.

Inscrire l’éditeur dans la tâche en cours

Imaginez un client qui prépare une annonce depuis l’écran Campagnes de votre application. Il s’attend à reconnaître le nom de sa campagne, comprendre si ses modifications sont enregistrées et retrouver cette campagne en quittant l’éditeur.

Gardez ces responsabilités de l’hôte visibles. Évitez deux barres de navigation qui semblent chacune piloter tout le parcours. Distinguez l’édition du message du choix des destinataires et de l’autorisation d’envoi, même lorsque ces étapes sont proches.

Employez les termes déjà connus dans votre produit. Si un travail inachevé est appelé « brouillon », une mention inattendue de « projet » oblige à comprendre un concept supplémentaire. Quelques mots cohérents comptent souvent davantage qu’un rayon de bordure parfaitement identique.

Relier les rôles visuels aux réglages disponibles

Partez des rôles de votre système de design : action principale, fond de travail, surface des panneaux, fond des commandes et texte. Faites correspondre ces rôles explicitement plutôt que d’utiliser une seule couleur de marque partout.

Le thème Weavour comprend notamment primaryColor, backgroundColor, surfaceColor, shellColor, inputColor, les couleurs de texte, cornerRadius, density et fontFamily. Utilisez les valeurs acceptées et contrôlez le résultat. Une iframe reste un document distinct : styliser son conteneur ne donne pas un accès arbitraire à toutes ses commandes internes.

Une application avec des panneaux clairs et des champs plus soutenus peut ainsi différencier l’habillage et les contrôles. Gardez les couleurs propres à l’email indépendantes. Modifier l’apparence de l’éditeur ne doit pas redessiner l’annonce du client en cours de rédaction.

Rendre les changements de langue prévisibles

La langue de l’interface et celle du message répondent à deux besoins différents. Une personne francophone peut préparer une annonce en anglais. Passer les commandes en français doit l’aider à travailler sans traduire un contenu déjà validé.

Weavour propose des libellés en anglais, français et espagnol. La méthode updateConfig change la langue et les réglages de présentation pris en charge sans remplacer le document. Intégrez cette distinction à votre politique linguistique et vérifiez-la sur un vrai brouillon.

Identifiez aussi les messages relevant de l’hôte : erreurs d’authentification, échec de persistance, contrôle de l’audience et validation d’envoi. Localisez-les avec le reste du produit. Un éditeur traduit entouré d’erreurs non traduites donne toujours une impression de rupture.

Préserver l’usage selon le thème et la taille

Une palette harmonisée n’a d’intérêt que si elle reste lisible. Examinez le texte courant, les libellés secondaires, les sélections, les erreurs et les indicateurs de focus sur leurs surfaces réelles. Les recommandations du W3C sur le contraste expliquent les exigences applicables au texte.

Testez également l’agrandissement. Le guide du W3C sur le redimensionnement du texte fournit un repère utile. Des libellés traduits plus longs révèlent parfois des coupures absentes d’une capture en anglais.

Parcourez ensuite les écrans étroits, fenêtres comprises, jusqu’au retour à l’application. L’hôte peut devoir adapter sa disposition. Masquer une action indispensable ne remplace pas une décision sur la manière d’accomplir la tâche sur petit écran.

Tester pendant une vraie session de rédaction

Utilisez une annonce partiellement écrite pour la recette. Modifiez une phrase, changez le thème et la langue, puis poursuivez. Vérifiez la conservation du contenu et le comportement attendu de l’annulation au lieu de recréer l’éditeur pour appliquer un réglage.

  • Entrer au clavier et trouver les actions principales.
  • Ouvrir puis fermer une fenêtre en contrôlant le retour du focus.
  • Changer de thème avec du travail non enregistré.
  • Essayer les libellés français et espagnols longs.
  • Agrandir le texte et vérifier la disposition de l’application hôte.
  • Quitter, détruire l’instance et rouvrir le brouillon enregistré.

Un changement d’identité diffère d’un changement visuel : modifier le contexte d’éditeur, d’utilisateur ou d’organisation nécessite de détruire puis remonter le SDK Weavour. Traitez-le comme un nouveau contexte documentaire et gérez consciemment le travail non enregistré.

Commencez votre revue par la continuité de la tâche, puis affinez typographie et couleurs. Découvrez Weavour avec un écran réel de votre application comme référence d’intégration.

Retour au blog