7 Mythen der E-Mail-Entwicklung

E-Mail begann 1971 als reine Text- und 1:1-Kommunikationsmethode, als sie von Ray Tomlinson konzipiert wurde. Im Laufe der Jahrzehnte hat sich E-Mail weiterentwickelt und sich von den reinen Textversionen früherer E-Mails zu HTML bewegt. Die E-Mail-Entwickler haben E-Mails in die Zukunft gepusht, indem sie kreative Techniken innerhalb strenger Grenzen anwenden.

In dieser Zeit haben E-Mail-Entwickler alle Arten von „Best Practices“ entwickelt, um anderen den Einstieg in die E-Mail-Codierung zu erleichtern oder um diejenigen in den Gräben daran zu erinnern, was E-Mail-Entwickler können und was nicht.

Wir sind heute hier, um E-Mail-Entwickler daran zu erinnern, dass Best Practices nicht als statisch angesehen werden sollten. Sie ändern sich. Was Ende der 90er Jahre für E-Mail-Entwickler das Beste war, stimmt Mitte der 2010er Jahre nicht mehr.

Hier sind sieben Mythen über die E-Mail-Entwicklung, die es schon seit Ewigkeiten gibt, und warum es an der Zeit ist, sie endlich zur Ruhe zu bringen:

• Mythos Nr. 1: E-Mails müssen 600 Pixel breit sein.
• Mythos #2: Sie dürfen nur Standard-Systemfonts verwenden.
• Mythos Nr. 3: Verwenden Sie nur den Übergangs-DOCTYPE.
• Mythos Nr. 4: Attributselektoren müssen verwendet werden.
• Mythos Nr. 5: Alle Stile in E-Mails müssen inline sein.
• Mythos Nr. 6: Verwenden Sie keine Hintergrundbilder in E-Mails.
• Mythos Nr. 7: E-Mails müssen bei allen E-Mail-Clients identisch aussehen.

Mythos Nr. 1: E-Mails müssen 600 Pixel breit sein.

Bevor Mobiltelefone und Tablets alltäglich wurden und E-Mail nur eine Desktop-Anwendung war, schrieben Best Practice vor, dass alle E-Mails nicht breiter oder schmaler als 600 Pixel sein sollten. Warum genau 600 Pixel? Die Darstellungsgröße der damals am häufigsten verwendeten E-Mail-Clients (HoTMaiL, Yahoo und Outlook) lag bei 500-550 Pixeln. Wenn die E-Mail-Breite nicht breiter als 600 Pixel ist, würde so wenig horizontales Scrollen in der E-Mail wie möglich möglich sein.

Diese 600-Pixel-Regel blieb bestehen. Auch wenn es heute mehr Geräte mit unterschiedlichen Bildschirmgrößen gibt, warum halten wir uns an diese 600-Pixel-Regel?

Es ist eine einfache Regel, die Sie einhalten können, insbesondere wenn Ihr E-Mail-Workflow das Erstellen eines Designs in Adobe Photoshop oder Sketch umfasst – Sie benötigen eine physische Breite, um Ihr E-Mail-Design zu starten. Es stimmt, dass eine E-Mail mit einer Breite von 600 Pixeln unter den populäreren E-Mail-Clients auf Desktops immer noch sehr gut angezeigt wird. Und mithilfe von Medienabfragen können E-Mail-Entwickler ganz einfach die Breite der E-Mail ändern, je nachdem, welches Gerät die Abonnenten zum Öffnen verwenden.

Fluid width löst das Problem der schieren Anzahl von Geräten, die E-Mail-Entwickler unterstützen müssen. Damit dies funktioniert, verwenden Sie max-width, um zu verhindern, dass E-Mails in größeren Ansichtsfenstern zu breit und unleserlich werden, und bedingte MSO-Anweisungen, damit Outlook verständlich ist (da die CSS-Eigenschaft max-width nicht gerendert wird).

Zalandos E-Mails sind 450 Pixel breit – weit entfernt von dem 600-Pixel-Standard, den wir gewohnt sind. In Kombination mit den großen CTAs sieht es so aus, als ob die mobilfreundlichen E-Mails von Zalando mehr auf die mobile Masse ausgerichtet sind.

Inzwischen verwenden die E-Mails von Email Weekly die Fluid-Technik mit einer maximalen Breite von 960 Pixeln. Es verwendet Medienabfragen, um die Breite der E-Mail je nach Gerätebreite elegant zu ändern.

Abhängig von den Clients und Geräten, mit denen Ihre Abonnenten Ihre E-Mail öffnen, kann es sinnvoll sein, die Breite Ihrer E-Mail auf maximal 600 Pixel einzustellen.

Wo öffnen Ihre Abonnenten Ihre E-Mails? Mit E-Mail-Analyse können Sie herausfinden, auf welchen Geräten und E-Mail-Clients Ihre E-Mails geöffnet werden. Mehr erfahren →

Mythos #2: Sie dürfen nur Standard-Systemfonts verwenden.

Systemschriftarten sind seit langem die sichere Option für die Verwendung in E-Mails. Nun, sie waren die einzige Option.

Auf der anderen Seite experimentieren Webdesigner seit den frühen 2000er Jahren mit der Verwendung nicht standardmäßiger Schriftarten im Web. Im Jahr 2008 erhielt die CSS-Regel @font-face endlich die Unterstützung von Webbrowsern für Webdesigner, um auf ihren Websites nicht standardmäßige Schriftarten zu verwenden. Im Jahr 2010 führte Google eine eigene Bibliothek mit Webfonts ein, die Webdesigner kostenlos nutzen können.

Kein Glück für E-Mail-Designer, da eine solide Methode zum Importieren der Webfonts in eine HTML-E-Mail fehlt. Ganz zu schweigen von der fehlenden Lizenzierung: Als Webfonts zum ersten Mal erstellt wurden, dachte niemand, dass sie in E-Mails verwendet werden würden, sodass die Lizenzierung von Webfonts die Verwendung von E-Mails nicht umfasste.

Obwohl wir Standard-Systemschriftarten in Ihren E-Mails empfehlen, bedeutet dies nicht, dass Sie Webschriftarten nicht als progressive Verbesserungstechnik verwenden können. Online-Font-Repositorys beginnen, die E-Mail-Nutzung in ihrer Lizenzierung abzudecken. Und Google Fonts mit seinen 800 kostenlos nutzbaren Webfonts wird jetzt zur bevorzugten Bibliothek für E-Mail-Designer, die nicht standardmäßige Webfonts in ihren E-Mails verwenden möchten.

Unterstützung für Webfonts gibt es in Google Android 4.4, Apple Mail für iPhone, iPad und Mac sowie Outlook 2011 und 2016 unter OS X. Dies mag nicht viel erscheinen, aber im September dieses Jahres vier der fünf besten E-Mail-Clients , in Marktanteil, unterstützen Webfonts – iPhone, iPad, Google Android und Apple Mail. Das sind über 50% aller E-Mail-Öffnungen im September! Natürlich müssen Sie sich Ihren eigenen Abonnentenstamm ansehen, aber dies ist ein guter Indikator dafür, wie viele Personen möglicherweise Webfonts in Ihren E-Mails sehen können.

Können Sie die feinen Unterschiede zwischen diesen beiden E-Mails erkennen? Der linke verwendet Webfonts, während der rechte Webfonts deaktiviert hat. Outnet hat sich für eine großartige Fallback-Schrift entschieden, die ihrem Webfont sehr nahe kommt und zeigt, wie Sie Webfonts heute konsequent in Ihren E-Mails verwenden können.

Mythos Nr. 3: Verwenden Sie nur den Übergangs-DOCTYPE.

Der DOCTYPE eines HTML-Dokuments teilt dem Browser mit, wie die Seite zu rendern ist, und wird verwendet, um den HTML-Code des Dokuments zu validieren.

Der am häufigsten verwendete DOCTYPE in E-Mails ist:

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional //EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

E-Mail-Entwickler haben sich angewöhnt, einen DOCTYPE zu verwenden, obwohl einige E-Mail-Clients den DOCTYPE ganz entfernen oder durch einen anderen ersetzen. Gmail, Outlook.com und Yahoo! Mail gehört zu den E-Mail-Clients, die alle in Ihrer E-Mail vorhandenen DOCTYPE entfernen und durch HTML5 DOCTYPE ersetzen.

Im Web ändern verschiedene DOCTYPEs, wie einige CSS-Eigenschaften und HTML-Elemente gerendert werden. Der obige DOCTYPE ermöglicht die breiteste Palette von HTML-Elementen, einschließlich veralteter Elemente wie <font>, die in E-Mails verwendet wurden. In früheren Tests hat sich dieser DOCTYPE als der zuverlässigste für E-Mail erwiesen. WAS bewiesen – Vergangenheitsform.

Dies war, bevor HTML5 der Standard wurde, der es heute ist:

 <!DOCTYPE html>

Der HTML5 DOCTYPE ermöglicht die Verwendung neuerer HTML5-Elemente, zum Beispiel <video>, die in E-Mails verwendet werden können. Auch wenn möglicherweise nicht alle Clients die neuen Elemente oder Eigenschaften rendern können, gibt es keinen Grund, Ihre E-Mail nicht in die Zukunft zu schieben, indem Sie Ihren DOCTYPE aktualisieren. Sie können veralteten Code weiterhin mit einem HTML5-DOCTYPE verwenden, aber der Code ist nicht mehr gültig, wenn er durch einen Validierungsdienst überprüft wird. Ob Ihr Code gültig ist oder nicht, hat zwar keine Auswirkungen auf die Zustellbarkeit oder Leistung, aber es kann eine gute Idee sein, Ihr HTML-Markup auf offene HTML-Tags zu überprüfen, die sich auf die Darstellung Ihrer E-Mail auswirken können.

Mythos Nr. 4: Attributselektoren müssen verwendet werden.

Yahoo! Mail war ein etwas einfacher zu entwickelnder E-Mail-Client als beispielsweise Outlook. Es unterstützte Stil im Kopf, solange wir uns erinnern können. Eine Eigenart Yahoo! Mail bot an, dass es jede CSS-Anweisung in einer Medienabfrage neben jedem CSS außerhalb der Medienabfragen wiedergab. Die einfache Lösung hierfür bestand darin, die CSS-Anweisung als Attributauswahl zu schreiben:

 *[class=”foo”] {color:#000000; font-family: sans-serif;}

Das Schreiben von CSS in den Kopf solcher E-Mails wurde zum Standard, da andere E-Mail-Clients, die auch Stil im Kopf lesen, keine Probleme hatten, einfache Attributselektoren wie das obige Beispiel zu lesen.

Anfang 2015 hat Yahoo! Mail hat ein Update veröffentlicht, das es ermöglicht, den Stil wie jeder "normale" E-Mail-Client zu lesen:

 .foo {color:#000000; font-family: sans-serif;}

Da Attributselektoren jedoch so tief in der E-Mail-Entwicklung verwurzelt waren, überraschte es nicht, dass sie immer noch im E-Mail-Code herumschwirrten. E-Mail-Entwickler waren einfach daran gewöhnt, sie zu verwenden, und oft wurden E-Mail-Vorlagen nicht aktualisiert.

Zuvor harmlos können Attributselektoren jetzt Ihrer E-Mail ein wenig Schaden zufügen, wenn Sie sie in Ihrem Code haben. Wenn der Stil Ihrer E-Mail in Gmail nicht zu funktionieren scheint, überprüfen Sie, ob Sie noch Attributauswahlen in Ihrem Stil verwenden. Gmail unterstützt keine Attributauswahl, aber jetzt (endlich!) unterstützt es den Stil im <head>.

Da für Yahoo! Da Mail und Gmail diese nicht unterstützen, müssen Sie in Ihren E-Mails keine Attributselektoren im CSS verwenden.

Mythos Nr. 5: Alle Stile in E-Mails müssen inline sein.

Tabellen für Layout- und Inlining-Stile sind seit jeher das Fundament der E-Mail-Entwicklung. Sie definieren den Unterschied zwischen E-Mail- und Webentwicklung. Das Inlinieren von Stilen ist für E-Mail-Entwickler mittlerweile so alltäglich, dass es ein wenig unklar geworden ist, warum Stile überhaupt inliniert werden mussten.

Schockierenderweise behaupten einige Websites, dass Inline-Stile aufgrund von Outlook und Gmail benötigt werden. Was schlichtweg falsch ist. [Twittern]

Outlook hatte noch nie ein Problem mit dem Stil im Kopf der E-Mail. Auf der anderen Seite tat Gmail. Gmail war buchstäblich der Hauptgrund (mit einem Marktanteil von 16 % im September 2016), warum E-Mail-Entwickler ihr CSS inline einbinden.

Ende September begann Gmail, Stil im Kopf zu unterstützen. Müssen wir also mehr alle Stile inline einbinden?

Wenn Ihre Abonnenten hauptsächlich Gmail, iOS oder sogar Outlook verwenden, können wir mit Sicherheit sagen, dass es jetzt an der Zeit ist, Ihre Stile in den Vordergrund zu stellen. Wenn jedoch die Mehrheit Ihrer Abonnenten obskure E-Mail-Clients oder internationale E-Mail-Clients (Yandex, Libero, Terra) verwendet, die auf Inline-Stilen basieren, müssen Sie sie möglicherweise weiterhin verwenden. Wie immer empfehlen wir, Ihre E-Mail zu testen, wenn Sie größere Änderungen daran vornehmen.

Mythos Nr. 6: Verwenden Sie keine Hintergrundbilder in E-Mails.

Hintergrundbilder sind in E-Mails notorisch schwer zu bekommen. E-Mail-Entwickler verwenden komplizierten VML-Code zum Rendern in vielen Versionen von Outlook, und auch in anderen E-Mail-Clients fehlt die Unterstützung für Hintergrundbilder.

Hier ist die Sache: Hintergrundbilder können und werden in E-Mails funktionieren, aber so werden sie in das Design Ihrer E-Mail integriert. Bei eingeschränktem Support sollten Sie Hintergrundbilder nicht als Schlüsselelement im Design Ihrer E-Mail verwenden, da dies die Erfahrung für Ihren Abonnenten beeinflusst oder beeinträchtigt. Sie können sie jedoch in Ihren E-Mails ähnlich wie Webfonts verwenden – als fortschreitende Verbesserung.

Einer der Hauptgründe dafür, keine Hintergrundbilder in E-Mails zu verwenden, war die fehlende Unterstützung von Gmail für die CSS-Eigenschaften background-size und background-position. Diese CSS-Eigenschaften sind wichtig für Bildschirme mit hoher Pixeldichte und hybride/flüssige/responsive E-Mails, bei denen eine gewisse Kontrolle über die Größe und Platzierung der Hintergrundbilder erforderlich ist. Beide werden jetzt in Gmail und Inbox by Gmail unterstützt, sodass es noch weniger Gründe gibt, die Verwendung von Hintergrundbildern in E-Mails nicht auszuprobieren.

Kristian Robinson, leitender E-Mail-Entwickler bei TWO Digital Marketing und Redner der Email Design Conference 2016, geht tiefer in die Hintergrundbilder in E-Mails ein, wenn Sie sich dazu inspiriert fühlen, sie anzugehen.

Mythos Nr. 7: E-Mails müssen bei allen E-Mail-Clients identisch aussehen.

E-Mail-Clients haben alle leicht unterschiedliche Möglichkeiten, HTML-E-Mails zu rendern. Anstatt dies zu akzeptieren, haben E-Mail-Entwickler versucht, sich über eine Vielzahl von E-Mail-Clients zu identischen E-Mails zu hacken. Eine sehr ehrenvolle Aufgabe, die jedoch zu aufgeblähtem und hackigem HTML-Code führen kann, der ein Albtraum sein kann, um ihn zu verwalten und auf dem neuesten Stand zu halten.

Es ist vielleicht nicht der E-Mail-Entwickler, der nach Perfektion sucht, sondern der Kunde oder andere Stakeholder. Es liegt jedoch in der Verantwortung des E-Mail-Entwicklers, seine Mitmenschen über die Fallstricke der E-Mail-Entwicklung aufzuklären – warum E-Mail-Clients unterschiedlich rendern und warum es keine Rolle spielt, ob etwas in einem E-Mail-Client im Vergleich zu einem anderen 1 Pixel höher ist.

"Die Zeit, in der E-Mails pixelgenau sein mussten, liegt weit hinter uns." @ericlepetitsf #LitmusLive

— Chad S. White (@chadswhite) 16. August 2016

Dieser Mythos ist besonders schädlich, wenn versucht wird, neue Techniken in E-Mails einzusetzen, die möglicherweise nicht in 100 % der E-Mail-Clients wiedergegeben werden, z. B. Webfonts und Hintergrundbilder. Beides sind fantastische Möglichkeiten, Ihre E-Mails zu verbessern. Und wo wären wir als Branche, wenn wir nicht versuchen würden, neue Techniken in unseren E-Mails zu übernehmen und mit ihnen zu experimentieren?

Nur weil etwas seit Jahren auf eine bestimmte Art und Weise gemacht wird, heißt das nicht, dass es keinen besseren Weg gibt. Jetzt ist es an der Zeit, die Regeln und Best Practices zu hinterfragen, mit denen die E-Mail-Marketing-Branche seit Jahrzehnten arbeitet.

Programmieren Sie E-Mails schneller – und einfacher – mit Builder

Beschleunigen Sie Ihren E-Mail-Entwicklungsworkflow mit Builder, dem einzigen speziell für E-Mail entwickelten Code-Editor. Und es ist kostenlos!

Beginnen Sie mit der Verwendung von Builder →