Überlebenstipps für das Coden von HTML Newslettern

Code in Atom

Auf meiner Arbeit befasse ich mich mit der technischen Seite von Email Marketing. Das beinhaltet das Entwickeln von HTML Emails, Segmentierung, Pflege der Datenbank, Aufsetzen und Entwickeln von Regeln und Logik für getriggerte Flows in Zusammenarbeit mit anderen Plattformen für unsere jeweiligen Kunden. Auch wenn es nicht so klingt, kann ersteres sehr fordernd und nervenaufreibend sein, weswegen ich hier die Werkzeuge aufzähle, die beim Aufsetzen eines HTML Newsletters bei uns benutzt werden.

HTML Emails

Dass ich praktisch jede Mail manuell in HTML aufsetze hat Vorteile – es gibt mehr Freiheiten um manche Newsletter individuell anpassen zu können, ich kann auf Wunsch des Kunden Dinge hinzufügen oder entfernen, ich habe praktisch die Macht alles anzupassen. Aber es hat auch Nachteile. So ist das entwickeln von HTML Emails zum Beispiel ein Fluch verglichen mit dem Entwickeln von Webseiten. Nicht nur können wir wirklich nur mit einer Sprache arbeiten (HTML that is), darüber hinaus muss diese Sprache so simpel verwendet werden wie möglich, da es bei X Browsern, Y Mailprogrammen und Z Handys ungefähr A Möglichkeiten gibt, bei denen eine HTML Email für alle Empfänger gut aussieht. Und apropos Handys – natürlich muss der Newsletter auch responsive sein, was bedeutet, dass die X Browser und Y Mailprogramme auch noch auf Z Handys mit unterschiedlichen Betriebssystemen und Bildschirmgrößen getestet werden müssen. Kriegt ihr schon Zuckungen? Zurecht.

“In the broader web design world, we’ve been through the browser wars where Netscape and Internet Explorer fought each other to introduce competing ways to code just about everything. Thanks to the Web Standards Project and associated efforts, modern web browsers are much more consistent than they were ten years ago.

Unfortunately, while that war was being fought, email clients like Outlook and Lotus Notes were apparently off hiding in the marketing department behind a very expensive beanbag chair, and were left behind.

[…]

Outlook 2007 is a hugely popular email client, but that’s not the only problem: building HTML for email means you’re dealing with more than four or five major web browsers, and 12 to 15 different email clients, each with solid market share.”

What’s so hard about HTML emails?

Deswegen benutzen wir auf meiner Arbeit viele Hilfsmittel um sicher zu stellen, dass die Mails, die wir entwickeln, auch tatsächlich überall anders gut aussehen.

Litmus

Wir testen unseren Code immer mit Litmus, das einem eine Vorschau auf die Darstellung der Mail in allen Formen und Variationen bietet. Dieses Testen kann viel Zeit in Anspruch nehmen. Es kann sehr frustrierend sein. Denn auch wenn alles super aussah, als du es gecodet hast, sobald du den Code in Litmus kopierst und wie alle anderen Browser und Clients den Code interpretieren, hat man fast Lust, alles wieder hin zu schmeißen. Und wenn man dann einen bug für Outlook 2007 gefixt hat, ist das Design plötzlich in Outlook 2011 kaputt. Oder Gmail. Und die responsive Designs sind nochmal ein ganz neues Kapitel. Vor allem bei Android 4.4.

Generell das Internet

Wenn man wirklich nicht versteht, warum Outlook oder Lotus Notes oder Thunderbird wirklich diese wirklich simple Sache nicht anzeigen, ist es immer eine gute Idee, Übersichten wie zum Beispiel The Ultimate Guide to CSS zu Rate zu ziehen, denn ja, auch die simpelsten Dinge wie background-image, border-color oder margin können dir einige Jahre deines Lebens rauben.

Generell zahlt es sich aus, die folgenden Seiten im Auge zu behalten, da man dort auch schnell mitkriegt, wenn Gmail zum Beispiel plötzlich nicht mehr “width=”” anerkennt, sondern “style=”width:;” vorzieht.

Git

This is a pretty new one. Ich habe durchaus schon öfter von Git und Github gehört, wusste aber nie so richtig, was es war, und habe es als Werkzeug für Hardcore Entwickler abgetan. Im Grunde ist dieses Werkzeug auch nicht speziell wichtig für das Entwickeln von Emails, sondern immer, wenn man mit Code arbeitet.

Was tut Git? Es ermöglicht einem, verschiedene Versionen von Code zu speichern und diese Versionen dann zu vergleichen. Für weniger Hardcore Entwickler bieten Programme wie GitKraken, die das Ganze dann auch nett illustrieren und verständlicher machen.

Ich brauchte selber eine ganze Weile, bis ich verstand, was Git tut, und so richtig verstanden habe ich es wahrscheinlich auch noch immer nicht. :P Glücklicherweise bin ich da wohl auch nicht die Einzige, und es gibt den Artikel Git for Designers – Or anyone who really wants to use it but has no idea how, der es ganz nett erklärt.

Ich habe angefangen, Git zu benutzen, wenn

  • ich neue Module und Funktionen oder ganze HTML-Templates entwickle und dann beim Testen mit Litmus eine ganze Menge ändere und deswegen gerne den Verlauf festhalten will
  • ich Dinge bei den schon entwickelten Master-Templates ändere, um eine Dokumentation dafür zu haben, ob ich schon etwas geändert habe oder wann

Gulp

Ebenfalls neu unter meinen Werkzeugen ist Gulp. Ich habe damals in meiner unschuldigen Jugend HTML gelernt, indem ich alles immer mit der Hand geschrieben habe. Editoren mit farblicher Kodierung des Codes oder automatischem Schließen von Tags waren Luxus, als ich sie entdeckte. Gulp macht Dinge noch viel einfacher – wenn es einmal verstanden hat, that is. Gulp für das Coden von HTML-Mails zu benutzen, macht für mich Sinn, weil mein hauptsächlicher Kunde die gleiche Email oft für drei verschiedene Brands versendet. Das bedeutet, dass die Templates verschiedene Farbschemas haben, ansonsten aber gleich sind. Früher bedeutete das, dass ich den Text bei jeder Email neu einfügen musste, da ich die Farbcodes ja nicht mitkopieren konnte. Mit Gulp kann ich Variablen definieren, die für jede Brand durch einen anderen Farbcode erstattet werden, sodass ich Module und Text ganz einfach und schnell hin und her kopieren kann und nicht mehr über Farben nachdenken muss.
Da die HTML Templates alle schon entwickelt waren, als ich Gulp kennen lernte, bedeutete es jedoch, dass es ein ziemlich langer Prozess war, diese für die neue Arbeitsweise anzupassen.

Aktuell benutze ich folgende Plugins:

  • gulp-sass – um mit Sass übersichtlichere und besser formatierte Stylesheets erstellen zu können
  • gulp-inline-css – um diese Stylesheets dann automatisch zu inline styles in der HTML-Datei umzuwandeln, da man bei HTML Emails keine externen Styles verwenden sollte
  • handlebars und gulp-compile-handlebars – für Variablen in der HTML-Datei
  • gulp-rename – um die neue HTML-Datei direkt richtig umzubennen

Da das Design der Emails so gut wie immer gleich aussieht, muss ich somit nur noch den Inhalt in die Ausgangs-HTML-Datei einfügen. Dann diese Gulp-Kommandos ausführen und habe eine neue Datei, die bereit ist, direkt in die Plattform der Wahl eingelesen und als Newsletter verschickt zu werden. Möchte ich den gleichen Inhalt für eine andere Brand mit anderem Farbschema haben, ändere ich in der Ausgangsdatei bei der Wahl des Stylesheets statt “brand1.css” “brand2.css” (diese CSS-Dateien muss man natürlich erstellt haben), führe erneut alle Kommandos aus und taadaa – habe ich die gleiche Mail mit anderen Farben ohne die ganze Datei durchgehen zu müssen und alles manuell zu ersetzen.

Es hat eine ganze Weile gedauert, bis ich hier bin, und wahrscheinlich kenne ich nur einen winzigen Bruchteil der Dinge, die man mit Gulp machen kann, aber ich bin froh, es gelernt zu haben.

Weiteres Lesematerial:

Ich bin anscheinend nicht die Einzige, die den Workflow zum Erstellen von HTML Emails etwas mehr automatisiert, da ich auch den Artikel Using Grunt to Make Your Email Design Workflow Fun AgainGrunt kann nämlich für fast die gleichen Dinge benutzt werde wie Gulp! Die GitHub Repository eightmailboilerplate tut auch so gut wie das gleiche, nur – wie ich – mit Gulp. Da wird der Code sogar noch mehr simplifiziert und automatisiert als ich es bisher tue.

Die Plattform – Responsys

Ich arbeite hauptsächlich mit der Plattform Responsys von Oracle. Das bedeutet, dass ich die Newsletter in HTML code und Responsys nur für den Rest wie Tracking, Personalisierung, Segmentierung und Distribution zuständig ist. Es gibt sehr viele verschiedene Plattformen, und bei einigen arbeitet man gar nicht selber im HTML Code, da alles so genormt und automatisiert ist, dass man praktisch in der Software selber nur per Drag and Drop Blöcke in das Mailtemplate zieht und in einer grafischen Oberfläche alle wichtigen Einstellungen vornimmt.

So arbeitet man zum Beispiel auch bei den folgenden Anbietern, die auch eher für kleinere Zielgruppen geeignet sind:

Vor dem Senden – Testen

Als einen netten, schnell Spam-Tester für die Newsletter habe ich Mail-Tester gefunden. Man schickt eine Testmail (zum Beispiel von Responsys) an die angezeigte Mailadresse und bekommt dann eine Zusammenfassung zu den verschiedenen Aspekten, die das Risiko erhöhen, dass man bei den Empfängern im Spam-Ordner landet.
Bei Litmus bekommt man auch angezeigt, wie die Mail ohne geladene Bilder aussieht, ob der Absender vertrauenserweckend wirkt, wie der Preheader aussehen würde und wie lange es um Durchschnitt dauert, bis die Mail geladen ist.

Fluid Hybrid Emails

Fluid hybrid ist das neue Buzzwort in der Welt der Email Developer und beschreibt eine Methode, bei der man Emails ohne Media Queries und für alle Klienten responsive coden kann. Auch wenn das super klingt, hat es bisher einige Nachteile, die es nicht 100% brauchbar für die bisher entwickelten Templates unserer Kunden machen.

Zum Reinlesen:

Update 17/03/2016

  • Gulp NPM Pakete verlinkt
  • Links zu anderen Email Design Workflows hinzugefügt

Leave a Reply

Your email address will not be published. Required fields are marked *