Die Wahl eines Responsive E-Mail-Frameworks: MJML vs. Foundation for Emails

Die Implementierung von Responsivem E-Mail-Design kann etwas mühsam sein. Der Aufbau von Responsive E-Mails ist überhaupt nicht einfach; es ist, als würde man eine Zeitmaschine zurück ins Jahr 2001 nehmen, als wir alle Website-Layouts in Tabellen mit Dreamweaver und Fireworks programmierten.

Aber es gibt Hoffnung! Wir haben Werkzeuge zur Verfügung, die den Aufbau von E-Mails viel einfacher und mehr dem Programmieren einer modernen Website ähnlicher machen können. Schauen wir uns ein paar verschiedene Frameworks an, die darauf abzielen, die Dinge für uns zu vereinfachen.

Zuerst die Situation

Sie müssen mit vielen alten E-Mail-Clients kompatibel sein, von denen viele nicht einmal die grundlegendsten Webstandards (Floats, anyone?) unterstützen. Sie müssen sich auch mit allen Arten von Webmail-Clients auseinandersetzen, die aus Sicherheits- oder technischen Gründen ihre eigenen meinungsstarken Entscheidungen darüber getroffen haben, wie Ihre wertvollen E-Mails angezeigt werden.

Darüber hinaus werden E-Mails jetzt von verschiedenen Geräten mit sehr unterschiedlichen Viewports und Anforderungen gelesen.

Die beste Lösung wäre, wie so oft, die Dinge einfach zu halten und bei einfachen Einspaltendesigns zu bleiben, wobei mehrere Spalten nur für Menüs oder einfache Benutzeroberflächenelemente bekannter Breite verwendet werden. Schließlich können Sie großartige, effektive Designs mit nur einer Spalte erstellen.

Endbenutzer und Kunden, die an das „normale“ browserbasierte Web gewöhnt sind, können ihre E-Mail-Erfahrung jedoch an dieselben hohen Standards knüpfen wie beim Betrachten von Webseiten in Bezug auf Grafiken und Responsivität. Daher werden komplexe Designs erwartet: mehrere Spalten, unterschiedliche Verhaltensweisen auf Mobilgeräten im Gegensatz zu Desktops, viele Bilder usw., die alle konsistent und pixelgenau über alle E-Mail-Clients hinweg implementiert werden müssen. Welche Optionen gibt es, um all das zu ermöglichen?

Option 1: Von Grund auf neu aufbauen

Eine Option, die Sie wählen könnten, ist, jede E-Mail von Hand zu programmieren, sie einfach zu halten und sie während der Erstellung zu testen. Dies ist nur dann eine praktikable Option, wenn

1. Sie ein sehr einfaches Design zu implementieren haben.
2. Sie die direkte Kontrolle über das Design haben, sodass Sie die Dinge letztendlich vereinfachen können, wenn Sie keine konsistente Lösung für das, was Sie sich vorgestellt haben, finden.
3. Sie einen gewissen Grad an Verschlechterung bei einigen älteren Clients akzeptieren können: Es macht Ihnen nichts aus, wenn Ihre E-Mail in alten Outlook-Clients zum Beispiel nicht genau gleich aussieht (oder sogar schlecht).
4. Sie viel Zeit haben.

Offensichtlich müssen Sie Ihr Design intensiv testen. Campaign Monitor hat einen großartigen CSS-Leitfaden, auf den Sie während des Erstellungsprozesses zurückgreifen können und der so etwas wie „Can I Use“ ist, aber für E-Mails. Danach empfehle ich die Verwendung automatisierter Testsuiten wie Litmus oder Email on Acid. Beide bieten Ihnen eine vollständige Testsuite und Vorschauen, wie Ihre E-Mail auf einer riesigen Auswahl von E-Mail-Clients aussehen wird. Erwarten Sie jedoch einige Überraschungen, da oft dasselbe Design selbst bei demselben E-Mail-Client nicht korrekt aussieht, wenn es in verschiedenen Browsern oder verschiedenen Betriebssystemen angezeigt wird. Schriftarten werden unterschiedlich gerendert, Abstände ändern sich und so weiter.

Option 2: Ein Boilerplate-Template verwenden

Eine weitere Option ist die Verwendung eines der verschiedenen verfügbaren Boilerplates, wie z. B. Sean Powells hier erhältlich. Boilerplates befassen sich bereits mit vielen der Eigenheiten verschiedener E-Mail-Clients und Plattformen. Das ist sinnvoll, wenn

1. Sie alleine oder in einem kleinen Team arbeiten.
2. Sie viel Erfahrung haben, sodass Sie die meisten Eigenheiten der E-Mail-Formatierung bereits kennen, weil Sie ihnen schon begegnet sind.
3. Sie Ihre eigenen Werkzeuge für die Verwaltung von Komponenten (für verschiedene Newsletter, die Designelemente gemeinsam nutzen), das Inlining von Stilen (und ja, Sie sollten Ihre Stile weiterhin inlinen, wenn Ihre E-Mails ein internationales Publikum ansprechen) eingerichtet haben und eine Art Entwicklungswerkzeugkasten besitzen (sei es Gulp, Grunt oder etwas Ähnliches), das all dies für Sie automatisiert.
4. Sie den Ansatz verfolgen, alles im von Ihnen erstellten Code kontrollieren zu wollen und keine externen Tools nutzen möchten.
5. Sie es vorziehen, Ihre eigenen Fehler zu beheben, anstatt mögliche Fehler beheben zu müssen, die durch das von Ihnen verwendete Tool verursacht wurden.

Option 3: Ein Framework verwenden

Wenn jedoch einer der folgenden Punkte auf Sie zutrifft

1. Sie müssen viele E-Mail-Vorlagen mit gemeinsamen Komponenten erstellen.
2. Die Arbeit muss von einem Team von Entwicklern ausgeführt werden, die wechseln und/oder einen variablen Grad an Kompetenz und Erfahrung mit E-Mail-Implementierung haben.
3. Sie haben wenig oder gar keine Kontrolle über das ursprüngliche Design.

...dann werden Sie wahrscheinlich stark von der Verwendung eines Frameworks profitieren.

Derzeit sind zwei der interessantesten und beliebtesten verfügbaren Frameworks MJML und Foundation for Emails. Die größten Vorteile der Verwendung eines jeden Frameworks ist, dass sie die meisten Eigenheiten von E-Mail-Clients bereits für Sie gelöst haben. Sie bieten Ihnen auch einen etablierten Workflow, dem Sie folgen können, sowohl alleine als auch im Team. Sie verarbeiten auch das responsive Design sehr gut, wenn auch auf unterschiedliche Weise.

Werfen wir einen Überblick über beide Frameworks und vergleichen die besten Anwendungsfälle für jedes, bevor wir zu einigen Schlussfolgerungen kommen.

MJML

MJML ist ein Projekt, das intern von Mailjet, einem auf E-Mail-Marketing-Tools spezialisierten Unternehmen, ins Leben gerufen wurde. Es wurde dann Open-Source. Es arbeitet mit einer eigenen benutzerdefinierten, HTML-ähnlichen Vorlagensprache, die eigene Tags verwendet. Zum Beispiel

<mj-text>Your text here</mj-text>

Wenn Sie den endgültigen Code kompilieren, konvertiert MJML seine Tags in HTML für alles, von Tabellen bis hin zu benutzerdefinierten Komponenten, die es für Sie erstellt hat, alles mit seiner internen Engine. Es nimmt Ihnen die schwere Arbeit ab, komplexes Markup zu erstellen, und alles wurde getestet.

MJML verfügt über eine Reihe von Standardkomponenten. Dazu gehören Abschnitte, Spalten, Gruppen, Schaltflächen, Bilder, soziale Links (die sehr einfach zu erstellen sind), Tabellen, Akkordeons usw. Sie enthalten sogar ein vorformatiertes Karussell, das in den meisten Clients funktionieren sollte. Alle diese Komponenten lassen sich gut in responsive E-Mails übersetzen, mit Ausnahme der „Rechnungs“-Komponente, die ich in meinen Tests nicht zum Laufen bringen konnte. All diese Komponenten haben Parameter, die Sie in Ihrem Code übergeben können, um ihr Aussehen anzupassen.

Zum Beispiel ermöglicht die Komponente für soziale Links das vertikale und horizontale Stapeln von Icons und die Auswahl von Hintergrundfarben für die entsprechenden Icons. Es gibt tatsächlich viele weitere Parameter, mit denen Sie spielen können, alle mit dem Ziel, größere Flexibilität zu ermöglichen. Selbst die Logo-Bilddateien sind bereits im Paket enthalten, was ein großer Pluspunkt ist.

Hier ist eine Vorschau einer einfachen Konfiguration der Komponente für soziale Links

Sie können auch eigene benutzerdefinierte Komponenten erstellen oder von der Community erstellte Komponenten verwenden. Derzeit gibt es jedoch nur eine Community-Komponente.

MJML kümmert sich automatisch um Responsivität, was bedeutet, dass Komponenten von Mehrspaltigkeit (mehrere Elemente in derselben Zeile) zu Einspaltigkeit (Elemente werden übereinander statt nebeneinander angeordnet) wechseln, ohne dass ein aktives Eingreifen des Entwicklers erforderlich ist. Dies ist eine sehr flexible Lösung und funktioniert in den meisten Fällen gut, gibt dem Entwickler aber etwas weniger Kontrolle darüber, was genau in der Vorlage passiert. Wie die Dokumentation erwähnt, ist es erwähnenswert, dass

Aus ästhetischen Gründen unterstützt MJML derzeit maximal 4 Spalten pro Abschnitt.

Dies ist höchstwahrscheinlich nicht nur eine ästhetische Präferenz, sondern auch eine Begrenzung möglicher Nachteile bei zu vielen Spalten. Je mehr Spalten Sie haben, desto unvorhersehbarer ist das Ergebnis, denke ich.

Wie man mit MJML arbeitet

MJML kann als Kommandozeilentool verwendet werden, das Sie mit npm installieren können, und Ihre Dateien lokal ausgeben, mit Befehlen wie

$ mjml -r index.mjml -o index.html

Dies kann über Gulp oder ähnliches in Ihren Build-Prozess integriert werden, und in Ihrer Entwicklungsarbeit durch die Verwendung eines Watch-Befehls, der Ihre Vorschau bei jeder Speicherung aktualisiert.

$ mjml --watch index.mjml -o index.html

MJML hat Plugins für Atom und Sublime Text. In Atom liefert es sogar eine Echtzeit-Vorschau Ihres Layouts, die bei jeder Speicherung neu generiert werden kann. Ich habe es persönlich noch nicht ausprobiert, aber es scheint sehr interessant zu sein.

MJML hat auch eine eigene einfache Desktop-App und sie ist kostenlos. Sie können Ihren Code und Ihre Komponenten einrichten, Ihre Designs erstellen lassen und eine Echtzeit-Vorschau der Ergebnisse sowohl für Mobilgeräte als auch für Desktops erhalten. Ich finde, dass sie unter Ubuntu ziemlich gut funktioniert, aber der einzige Nachteil, den ich gefunden habe, ist, dass Sie Ihre Dateien niemals, niemals, *niemals* mit einem anderen Editor öffnen sollten, während sie in der App geöffnet sind, da die App abstürzt und der Inhalt der Datei verloren geht.

Hier sind einige Screenshots der Vorschauen bei der Arbeit

Die App kann auch mit einem kostenlosen Mailjet-Konto integriert werden, das es Ihnen ermöglicht, sofort Test-E-Mails an sich selbst zu senden. Das ist sehr praktisch, um problematische Clients schnell zu überprüfen, wenn Sie sie direkt zur Verfügung haben. (Ich würde empfehlen, die alte Windows-Maschine, die Sie im Lager haben, herauszunehmen, um Dinge in Outlook zu überprüfen, und das so oft wie möglich zu tun.) Ich würde jedoch weiterhin empfehlen, entweder Litmus oder Email on Acid zu verwenden, um Ihre E-Mails kundenübergreifend zu testen, bevor Sie sie bereitstellen, da Sie nie vorsichtig genug sein können und E-Mail-Standards sich genau wie in Browsern ändern können.

Insgesamt habe ich MJML als sehr einfach zu bedienen empfunden. Als ich jedoch versuchte, eine pixelgenaue Vorlage zu erstellen, die mit dem vom Kunden gewünschten Design identisch war, hatte ich einige Schwierigkeiten mit benutzerdefinierten Abständen für einige Bilder. Nicht alle verfügbaren Komponentenparameter funktionierten wie erwartet gemäß ihrer Beschreibung in der Dokumentation. Insbesondere hatte ich einige Probleme bei der Anpassung von Bildabständen und Polsterungen zwischen Desktop und Mobilgeräten.

Vorteile

• Vorgefertigte Komponenten
• Integration mit Mailjet
• Einfach zu bedienen, mit sofortiger Vorschau Ihrer Arbeit (auf Atom und Desktop App)

Nachteile

• Etwas weniger zuverlässig als Foundation for Emails, wenn Sie pixelgenaue Designs erstellen müssen
• Einige Komponenten haben Parameter, die nicht wie erwartet funktionieren
• Desktop App nicht perfekt stabil
• Keine strukturierte Ordnerstruktur für Ihre Inhalte (siehe Foundation unten)

Foundation for Emails

Foundation for Emails (früher bekannt als Ink – obligatorisches Prince-Zitat hier einfügen) ist ein Framework von Zurb, denselben Leuten, die uns das responsive Front-End-Framework Foundation for Sites gebracht haben.

Wenn Sie das Starter Kit herunterladen, erhalten Sie eine vollständige Entwicklungsumgebung mit Node.js-Befehlen zur Ausführung Ihres Projekts. Es richtet eine Node-Routine ein und öffnet sogar Ihren Browser, um Ihnen eine sofortige Vorschau Ihrer Arbeit zu geben.

Die zu verwendenden Dateien sind bereits in Ordnern und Unterordnern organisiert, mit einer klaren Angabe, wo Sie Ihre Sachen ablegen sollen. So gibt es beispielsweise Verzeichnisse speziell für Partial, Templates und Bilder. Diese Funktion halte ich für sehr wichtig, da es bei der Arbeit in einem Team sehr leicht passieren kann, dass man verschiedene Ordner verwendet und dies zu viel Zeitverlust beim Suchen nach Dingen führt, die nicht dort sind, wo man sie erwartet. Konventionen erzwingen ist keine Einschränkung; wenn man im Team arbeitet, ist es unverzichtbar.

Foundation for Emails wird mit einer Boilerplate-Vorlage geliefert, die der Ausgangspunkt für Ihren Code ist. Sie ist vollständig kommentiert, sodass Sie wissen, wie Sie sie mit Ihrem Code erweitern können. Sie wird mit SASS/SCSS-Unterstützung geliefert, was für komplexe Projekte sehr, sehr praktisch ist. Außerdem wird ein eigener Inliner mitgeliefert, sodass Sie sich keine Gedanken über die Konvertierung Ihres gesamten CSS (oder SASS/SCSS) in Inline-Stile machen müssen.

Es gibt eine Template-Engine hinter diesem Framework namens Inky. Und genau wie MJML hat es benutzerdefinierte Tags, die beim Kompilieren automatisch in HTML umgewandelt werden. Es gibt Tags wie <container>, <row>, <column>, die zum Erstellen Ihres Grids verwendet werden. Das Grid basiert auf einem 12-Spalten-System, das es Ihnen ermöglicht, Ihr Layout sehr genau zu unterteilen. Warum 12? Weil es durch 2, 3, 4 und 6 teilbar ist, was es sehr einfach macht, ein 2-, 3-, 4- oder 6-Spalten-Layout zu erstellen.

Foundation for Emails verwendet Panini, um den Code zu kompilieren. Panini ist eine benutzerdefinierte Bibliothek, die HTML-Seiten mithilfe von Layouts kompiliert. Sie unterstützt die Handlebars-Syntax und es gibt mehrere Helfer, die Sie verwenden können, um das Verhalten von Komponenten je nach Verwendungsort anzupassen. Sie können auch eigene Helfer erstellen, wenn Sie dies benötigen, und die benutzerdefinierten Variablen jedes Templates mit benutzerdefinierten Daten festlegen. Dies ist sehr nützlich, wenn Sie mehrere Vorlagen haben, die dieselben Komponenten gemeinsam nutzen.

Es gibt mehrere vorgefertigte E-Mail-Vorlagen zum Herunterladen, die viele der üblichen Anwendungsfälle für E-Mails abdecken, wie Newsletter und Ankündigungen. Es gibt auch einige vorgefertigte Komponenten (mit eigenen benutzerdefinierten Tags), darunter Schaltflächen, Menüs und Callouts (deren Zweck mir bei E-Mails nicht klar ist, aber egal).

Der Hauptunterschied zwischen Foundation for Emails und MJML besteht darin, dass Foundation for Emails standardmäßig die Desktop-Ansicht verwendet und dann für kleinere Bildschirme skaliert. Laut Dokumentation liegt das daran, dass viele Desktop-Clients keine Media Queries unterstützen und die Standardeinstellung für das große Bildschirm-Layout die Kompatibilität mit E-Mail-Clients erhöht. Das gesagt, verwaltet es nur einen Breakpoint. Sie erstellen die Desktop-Version und die mobile Version, und die mobile Version wechselt unter einer bestimmten Anzahl von Pixeln, die konfiguriert werden kann.

Sie können entscheiden, ob einige Komponenten nur für große oder kleine Bildschirme sichtbar sein sollen, indem Sie praktische vordefinierte Klassen wie .hide-for-large und .show-for-large verwenden (obwohl .hide-for-large möglicherweise nicht von allen Clients unterstützt wird). Sie können auch entscheiden, wie viel Platz eine Spalte einnehmen soll, indem Sie spezifische Klassen verwenden. Zum Beispiel wird eine Klasse von .large-6 und .small-12 auf einem div eine Spalte ergeben, die die halbe Bildschirmbreite auf dem Desktop und die volle Bildschirmbreite auf Mobilgeräten einnimmt. Dies ermöglicht sehr spezifische und vorhersagbare Layoutergebnisse.

Foundation for Emails ist meiner Meinung nach etwas umständlicher zu bedienen als MJML, aber es ermöglicht eine viel engere Kontrolle über das Layout. Das macht es ideal für Projekte, bei denen Sie pixelgenaue Designs mit sehr spezifischen Unterschieden zwischen mobilen und Desktop-Layouts reproduzieren müssen.

Vorteile

• Eine präzisere Kontrolle über die Endergebnisse
• Vorgefertigte Vorlagen
• Sass-Unterstützung
• Großartige Dokumentation

Nachteile

• Die Projektdatei ist schwer und nimmt viel Speicherplatz ein
• Etwas weniger intuitiv zu bedienen als MJMLs vordefinierte Parameter für Komponenten
• Weniger Komponenten für benutzerdefinierte Layouts verfügbar

Schlussfolgerungen

Die Erstellung von E-Mail-Vorlagen ist selbst weniger eine exakte Wissenschaft als die Frontend-Entwicklung. Sie erfordert viel Ausprobieren und SEHR viel Testen. Welches Werkzeug Sie auch immer verwenden, wenn Sie alte Clients unterstützen müssen, müssen Sie Ihre Layouts bis zum Gehtnichtmehr testen – insbesondere wenn sie auch nur den geringsten Grad an Komplexität aufweisen. Wenn Sie beispielsweise Text haben, der neben einem Bild stehen soll, empfehle ich, Inhalte mit unterschiedlichen Längen zu testen und zu sehen, was in allen Clients passiert. Wenn Text ein Bild überlappen soll, kann das ein Albtraum sein.

Je komplexer das Layout und je weniger Kontrolle Sie über das Layout haben, desto nützlicher ist es, ein Framework zu verwenden, anstatt Ihre eigenen E-Mails von Hand zu codieren, insbesondere wenn das Design Ihnen von einem Dritten übergeben wird und so umgesetzt werden muss, wie es ist.

Ich würde nicht sagen, dass ein Framework besser ist als das andere, und das ist nicht der Sinn dieses Beitrags. Vielmehr würde ich MJML und Foundation for Emails für unterschiedliche Anwendungsfälle empfehlen

• MJML für Projekte mit schneller Bearbeitungszeit und Designflexibilität.
• Foundation for Emails für Projekte, die eine engere Kontrolle über das Layout erfordern und bei denen das Design sehr spezifisch ist.

Ressourcen und Links

• Die MJML-Website
• Die Website von Foundation for Emails
• Litmus E-Mail-Tests
• Email on Acid Tests
• Eine interessante Unterhaltung im Litmus-Forum, die in gewisser Weise der Ausgangspunkt für diesen Artikel war.
• Ein weiterer Artikel von James Luterek, der diese Frameworks vergleicht