HTML & E-Mail: 6 häufige Fehler, die Sie vermeiden sollten

E-Mail mit HTML-Code erstellen? Hier sind 6 allzu häufige Fehler, die Sie vermeiden sollten, um die Vorteile einer optimierten, sauberen E-Mail-Kommunikation zu nutzen.

Fehler 1. Verwendung von übermäßig ausführlichem Code

Wir wissen, dass wir dank HTML und CSS eine E-Mail-Struktur aufbauen und ihr eine Form bzw. ein Format geben können, das es ermöglicht, eine bestimmte Schriftart, eine bestimmte Hintergrundfarbe, Bilder usw. anzuzeigen.

Jetzt werden wir sehen, wie sowohl HTML- als auch CSS-Tags in mancher Hinsicht dieselbe Funktion ausführen und sich am Ende überschneiden. Nehmen wir ein praktisches Beispiel: Definieren der Hintergrundfarbe für eine Tabelle sowohl in HTML als auch in CSS.

Der Code wird im Bild angezeigt. Sie können sehen, dass es zwei Punkte gibt, an denen die Hintergrundfarbe definiert wird:

• bgcolor = „#e75c00“ ist das Attribut der Tag-Tabelle;
• background-color ist das CSS-Attribut, das auf die Tabelle angewendet wird.

Beide Attribute machen dasselbe und überlappen sich daher: Sie legen dem Hintergrund der Tabelle die orange Farbe (#e75c00 gemäß dem hexadezimalen Format) auf.

Der kritische Punkt sollte nun klarer werden: Die HTML- und CSS-Eigenschaftsdefinitionen können sich übereinander stapeln. Tatsächlich kann der Code beim Überarbeiten oder Variieren desselben E-Mail-Modells oft durch redundante Eigenschaften blockiert werden, die dieselbe Funktion ausführen.

Und das ist nicht alles. Da auf jedes einzelne Element Inline-Styles angewendet werden können, kann auch dieser (perverse) Fall eintreten:

Ein Browser (oder E-Mail-Client) würde den Code ungefähr so ​​lesen:

• Wenden Sie einen grauen Hintergrund ( bgcolor = „#efefef“ ) auf die Tabelle an
• Zehn wenden einen schwarzen Hintergrund ( bgcolor = „#000000“ ) auf die Zeile an
• Wenden Sie abschließend einen orangefarbenen Hintergrund ( background-color: #e75c00 ) auf die Zelle an, die den Text Hello World!

Das Endergebnis ist sowohl in diesem als auch im vorherigen Beispiel identisch: weißer Text auf orangefarbenem Hintergrund.

Das Problem ist, dass im zweiten Fall drei verschiedene Hintergrundregeln definiert wurden. Der Benutzer sieht diejenige, die in Bezug auf die Zelle definiert ist, da der Browser den Code sequentiell liest (Tabelle -> tr -> td). Da die letzte Definition auf <td> gesetzt wurde, wird genau das angezeigt.

Es ist klar, dass ein Großteil des Codes nicht erforderlich ist. Dies liegt nicht nur daran, dass nur die Hintergrundfarbe der Zelle angezeigt wird, sondern auch daran, dass eines der Ziele eines guten E-Mail-Marketings darin besteht, die Kommunikation so hell wie möglich zu halten. Sehr ausführlicher, redundanter Code ist kein Light-Code.

Unsere Empfehlungen:

• Halten Sie den Code so sauber wie möglich
• Vermeiden Sie unnötige Wiederholungen beim Formatieren des Codes
• Geben Sie Inline-Stilen den Vorzug
• Versuchen Sie eine modulare Struktur für den Kommunikationscode aufzubauen
• Versuchen Sie, den Code durch Einrücken so geordnet wie möglich zu halten (es gibt mehrere Online-Dienste, die dies tun, wie HTMLformatter oder Clean CSS), um einen Überblick über die Struktur der Kommunikation zu haben
• Verfolgen Sie den Verlauf der Makroänderungen, die an einem Modell vorgenommen wurden

Fehler 2. Übermäßiges Kommentieren des Codes

Wie bei den meisten Sprachen ist es auch möglich, HTML-Kommentare hinzuzufügen. Was ist ein Kommentar in einem HTML-Skript? Es ist ein Teil der Auflistung, der von dem Programm ignoriert wird, das den Code liest und ausführt.

Ein Beispiel für einen Kommentar ist in der folgenden Abbildung dargestellt:

Wie Sie sehen, hat alles zwischen <!- und -> nicht nur eine andere Farbe (je nach Schnittprogramm), sondern wird vor allem nicht auf dem Bildschirm angezeigt.

So können „Service-Mitteilungen“ über den geschriebenen Code oder Anleitungen für noch zu vervollständigende oder zu verbessernde Teile eingefügt werden.

Es gibt auch eine andere Möglichkeit, Kommentare zu verwenden. Da nicht alles angezeigt wird, was zwischen Anfangs- und Schlussmarke steht, ist es möglich, ganze Seitenteile damit zu kaschieren, wie im folgenden Beispiel gezeigt. Tatsächlich können wir sehen, dass nur drei Zeilen auf dem Bildschirm sichtbar sind, anstatt der vier, die im Code geschrieben sind.

Es ist natürlich ein nützliches Werkzeug, aber wir dürfen es nicht missbrauchen. Der kommentierte Code wird zwar nicht angezeigt, bleibt aber dennoch in der gesendeten Kommunikation und belastet diese.

Unser Rat:

• Verwenden Sie Kommentare sinnvoll, um beispielsweise den Anfang und das Ende von Kommunikationsstrukturen zu kennzeichnen oder nützliche Informationen für den Entwickler einzufügen
• Seien Sie nicht langatmig in den Kommentaren und schreiben Sie sie noch besser auf Englisch
• Löschen Sie den kommentierten Code vor dem Senden, da er für Kommunikationszwecke nicht erforderlich ist

Fehler 3. E-Mail-Inhalte falsch verwalten

Beim Entwerfen einer E-Mail ist es sinnvoll, noch vor dem Schreiben einer einzigen Codezeile bestimmte Parameter zu definieren, die in der anschließenden Realisierungsphase und damit während der Produktion nicht mehr geändert werden können.

Einige dieser Parameter umfassen:

• E-Mail-Breite
• Bildgröße
• Anzahl der Bilder
• In der Kopfzeile verwendete Schriftgröße
• Schriftgröße für Textkörper

Und so weiter. Ein Parameter, der oft weggelassen wird, ist die maximale Anzahl von Tastenanschlägen für ein beliebiges Textelement.

An dieser Stelle könnte man einwenden, dass wir uns der Fanatik der Regeln schuldig machen, aber es gibt zwei gute Gründe dafür, so streng zu sein. Der erste ist konzeptionell und der zweite operativ.

Auf konzeptioneller Ebene sind Inhalt (Text, Bilder usw.) und Container (HTML-Struktur) zwei separate Einheiten mit einer sehr genauen Hierarchie, die erstere der letzteren untergeordnet sieht.

Tatsächlich sollte der Inhalt an den Behälter angepasst werden und nicht umgekehrt. Die Architektur der Kommunikation wird beim Schreiben des Codes konstruiert. Dadurch wird der Container definiert, und wenn er einmal geformt ist, bleibt der Container unabhängig vom Inhalt ein solcher, auch wenn die E-Mail responsive erstellt wurde.

Zusammenfassend – und Bruce Lee umschreibend – ist der Inhalt wie Wasser: Wenn Sie Wasser in eine Tasse geben, wird es zur Tasse; Wenn Sie Wasser in eine Flasche füllen, wird es zur Flasche; Wenn Sie Wasser in eine Teekanne geben, wird sie zur Teekanne.

Sie können nicht erwarten, dass eine Tasse zu einer Flasche wird, und eine Teekanne wird nie eine Tasse sein. Daher muss sich der Text (oder das Bild oder die Schaltfläche) an die Struktur anpassen, die ihn enthält, und nicht umgekehrt.

Der zweite Grund ist operativer. Wenn alle Parameter für die Gestaltung der Kommunikation a priori genau bekannt sind, kann nicht nur in der Entwurfsphase eine effektivere, sondern auch ausgewogenere Kommunikation geschaffen werden.

Nehmen wir ein konkreteres Beispiel: Angenommen, wir haben ein DEM mit zwei Produkten nebeneinander. Ein Produkt ist normalerweise verbunden mit:

• Ein Bild
• Der Name des Produkts
• Die Produktbeschreibung
• Der Preis
• Der CTA, der zur Produktseite führt

Da nun die Produkte nebeneinander liegen, müssen die Teile unbedingt ausgewuchtet werden.

Das heißt, die Bilder müssen die gleiche Höhe haben, die Beschreibungstexte müssen eine ähnliche Länge haben und die beiden CTAs dürfen nicht zu unterschiedlich sein.

Das Ignorieren oder Nichtbeachten dieser Grundprinzipien kann zu Fällen wie der obigen Abbildung führen.

Die Symmetrie zwischen den beiden Elementen wird gebrochen, weil der linke Produkttitel so lang ist, dass er drei Zeilen umfasst, während der rechte so kurz ist, dass er nur eine einzige Zeile ausfüllt. Es wurde eine Zwietracht eingeführt, die letztendlich die gesamte Kommunikation schwächt.

Die Einhaltung dieser Regeln wird umso wichtiger, wenn man an die mobile Welt denkt, in der all die verschiedenen Geräte sehr unterschiedliche Auflösungen haben: von den 1125 x 2436 px des iPhone X bis zu den 1440 x 2960 px des Samsung Galaxy S8, die durch die 768 x 1280 Pixel des Microsoft Lumia 1020.

Wenn sich diese enorme Vielfalt mit dem dichten Dschungel an E-Mail-Clients überschneidet, bedeutet dies, dass wir keine vollständige Kontrolle über die DEM-Darstellung haben, da es keinen definitiven Code gibt, der sich in jedem Fall an die Pixel anpasst. Wenn Sie dies also nicht per Code steuern können, müssen Sie versuchen, dies indirekt zu tun, indem Sie die anderen Teile einer E-Mail ändern, z. B. die Länge der Texte oder die Größe der Bilder.

Unsere Empfehlungen:

• Definieren Sie alle Teile der Vorlage
• Bleiben Sie konsistent zwischen den verschiedenen Teilen der Kommunikation
• Respektiere die Regeln, die du dir selbst gegeben hast
• Die Regeln können gebrochen werden, aber dies muss mit vollem Bewusstsein geschehen
• Wenn die Vorlage nicht Ihren Anforderungen entspricht, können Sie darüber nachdenken, eine neue zu definieren

Fehler 4. Interaktive Telefonnummern und Adressen falsch erhalten

Manchmal fügen E-Mail-Absender ihre Kontaktinformationen hinzu, insbesondere in der Fußzeile. Dazu gehören in der Regel eine Adresse und eine Telefonnummer.

Während eine Telefonnummer und Adresse Standardinformationen für Desktop-Client-E-Mails sein können, obwohl sie selten verwendet werden, sind diese Elemente besonders wichtig, wenn es um die mobile Seite geht.

Dies geschieht hauptsächlich aus zwei Gründen:

• Sie können mit einem Klick eine App öffnen, die die Daten verwaltet (Kalender, Telefon, Browser)
• Die Anzeigefläche wird reduziert und somit wird jede Information besser sichtbar, auch wenn sie sich in der Fußzeile befindet

Es ist daher wichtig, auch diese Details bei der Entwicklung der Kommunikation nicht zu vergessen, da sich ihr Verhalten bei den verschiedenen Geräten unterscheidet.

Nehmen wir uns einen Moment Zeit, um ein Beispiel zu betrachten, das durch eine Simulation ad hoc erstellt wurde. Beide Beispiele werden von iPhone 6+ iOS 9 angezeigt.

Das Bild links zeigt den vom Nutzer erhaltenen Newsletter mit dem direkt eingegebenen Text ohne Formatierung.

Aus technischer Sicht ist alles richtig, aber wir müssen berücksichtigen, dass der Code von der E-Mail-App selbst auf dem Handy interpretiert wird. Es „liest“ den Text der E-Mail, und wenn es Text in Form eines Datums, einer Adresse oder einer Telefonnummer erkennt, verknüpft es automatisch den aktiven Link mit der jeweiligen App, also dem Kalender, der Karte oder dem Telefon.

Das alles ist sehr praktisch, denn mit nur einem Klick können Sie telefonieren, eine Veranstaltung planen oder die Karte öffnen, um eine Route festzulegen. Die einzigen, die darüber traurig sein können, sind die Art und die Entwickler, die die blauen Links und die Unterstreichungen nicht sehen möchten. Also, was sollten wir tun? Wie sollen wir vorgehen?

Sie können einen kleinen Workaround oder Trick verwenden, um die Dinge wieder normal zu machen. Um es klar zu sagen: Obwohl sie die Regeln von gut formatiertem HTML brechen, sind Workarounds im riesigen Ozean der E-Mail-Clients unverzichtbar.

Wenn das Hauptziel eines Entwicklers darin besteht, die Kommunikation auf so vielen Clients wie möglich sichtbar zu machen, müssen sie Kompromisse eingehen und die Problemumgehungen annehmen.

Sehen wir uns also an, wie der Code geändert wurde.

Beim Telefon ist es ganz einfach: Da das Anchor-Tag die Definition einer Telefonnummer durch die Verwendung von tel in der Eigenschaft href ermöglicht , fügen wir die Telefonnummer ohne Leerzeichen oder Trennlinien hinzu.

Für eine Adresse oder ein Datum müssen wir jedoch anders vorgehen. Für diese ist es notwendig, eine Klasse (.address) zu definieren, die das Anker-Tag auferlegt, das die Farbe automatisch in den Client einfügt (color: #ffffff;). Vor allem sollte es die Unterstreichung entfernen, die eine Standardfunktion jedes Links ist (text-decoration:none;).

Beachten Sie, dass beide Attribute der Adressklasse !important haben , die vom Client unabhängig von der Eigenschaft angewendet werden müssen. Ohne sie gibt es keine Garantie, dass die Problemumgehung ihre Aufgabe erfüllt.

Unsere Empfehlungen:

• Achten Sie immer darauf, wie die Kommunikation auf dem Handy dargestellt werden kann (zB durch Tests)
• Verwenden Sie nach Möglichkeit Micro-Fixes, um die Kommunikation mobilfreundlich zu gestalten
• Gehen Sie nicht davon aus, dass das, was für den Desktop gut ist, auch für das Handy gut ist
• Kennen Sie Ihr Publikum: Welche Technologie verwenden sie? Welche Geräte? Welche Medien?
• Verwenden Sie interne Tests, um mit Ihrer eigenen Kommunikation zu experimentieren, insbesondere wenn umfangreiche Updates für E-Mail-Client-Apps vorliegen

Fehler 5. Verlassene oder leere Tags nicht bereinigen

Um das Gesamtgewicht der Kommunikation so gering wie möglich zu halten, müssen wir weiterhin auf die Teile des bestehenden Codes achten, die ihres natürlichen Inhalts entleert wurden.

Lassen Sie uns gleich ein konkretes Beispiel geben: ein <font> -Tag, vielleicht mit einer Reihe von Inline-Stilen, das keinen Text enthält. Offensichtlich kann die E-Mail-Seite nichts lesen, aber das Formatierungs-Tag <font> existiert weiterhin und belegt physischen Platz in der E-Mail.

Ein weiteres klassisches Beispiel sind die <a>-Anker-Tags, die kein verknüpftes Objekt haben, also etwa: <a href=“http://www.mailup.com“ style=“color:#00000;text-decoration:none“> </a>.

Normalerweise sind diese „Fehler“ in dem Code vorhanden, der überarbeitet oder mehrfach verwendet wurde, sodass verschiedene Teile wie Bilder, Links und Texte eingefügt, geändert oder gelöscht wurden. Alternativ könnte dies ein Hinweis auf eine falsche Verwendung eines WYSIWYG-Editors sein. Tatsächlich haben diese Editoren bei falscher oder unvorsichtiger Verwendung den Fehler, Code zum Code hinzuzufügen, da jedes vordefinierte Element normalerweise einen Teil des Codes enthält, der seit der Erstellung des Editors selbst definiert ist.

Das Programm wendet das Modell unkritisch jedes Mal an, wenn das ausgewählte Element eingefügt wird. Daher kann dieses Problem auftreten, wenn Sie denselben Teil der E-Mail ausreichend oft umschreiben.

Unser Rat:

• Achten Sie beim Schreiben des Codes immer darauf, dass keine verlassenen oder leeren Tags vorhanden sind
• Wenn Sie einen WYSIWYG-Editor verwenden und auf den Code zugegriffen werden kann, prüfen Sie, ob alles in Ordnung ist und keine derartigen Fehler vorliegen

Fehler 6. Verwenden von nicht validiertem HTML

Über die Validierung von E-Mail-Code zu sprechen, ist ein heikles Thema.

„Die meisten Seiten im World Wide Web sind in Computersprachen (wie HTML) geschrieben, die es Web-Autoren ermöglichen, Text zu strukturieren, Multimedia-Inhalte hinzuzufügen und festzulegen, welches Aussehen oder welchen Stil das Ergebnis haben soll.

Wie jede Sprache haben diese ihre eigene Grammatik , ihr eigenes Vokabular und ihre eigene Syntax , und jedes Dokument, das mit diesen Computersprachen geschrieben wurde, soll diesen Regeln folgen. Die (X)HTML-Sprachen für alle Versionen bis XHTML 1.1 verwenden maschinenlesbare Grammatiken, die DTDs genannt werden, einen von SGML geerbten Mechanismus.

Genauso wie Texte in einer natürlichen Sprache Rechtschreib- oder Grammatikfehler enthalten können, befolgen jedoch Dokumente, die Markup-Sprachen verwenden, (aus verschiedenen Gründen) diese Regeln möglicherweise nicht. Der Prozess der Überprüfung, ob ein Dokument tatsächlich den Regeln der verwendeten Sprache(n) entspricht, wird als Validierung bezeichnet , und das dazu verwendete Werkzeug ist ein Validator. Ein Dokument, das diesen Prozess erfolgreich besteht, wird als gültig bezeichnet .

Mit diesen Konzepten im Hinterkopf können wir „Markup-Validierung“ als den Prozess definieren, bei dem ein Webdokument anhand der Grammatik (im Allgemeinen einer DTD) überprüft wird, die es angeblich verwendet“.

Definition W3C

W3C hilft uns als Wächter und Garant des Codes, indem es ein Code-Validierungs-Tool bereitstellt, dessen Analyse Fehler aufzeigt und Wege zu deren Korrektur vorschlägt. Dank dieses Tools ist es möglich, größere Strukturfehler zu erkennen und zu korrigieren.

Es sei daran erinnert, dass E-Mail-Marketing eine zweifache Situation hat:

• Einerseits ist HTML eine standardisierte Sprache mit sehr genauen Regeln und Strukturen
• Auf der anderen Seite eine Reihe von Workarounds, die nicht standardmäßig und oft verpönt sind, aber gut funktionieren, wenn Sie eine korrekte Visualisierung auf E-Mail-Clients haben möchten

Diese beiden Aspekte sind wie bei einem alten Ehepaar, bei dem die Leidenschaft längst verpufft ist. Sie wissen nicht, warum sie zusammenleben, werden aber durch Kompromisse dazu gezwungen.

Warum also über Codevalidierung sprechen? Macht das Sinn? Welche Kompromisse gibt es?

Es ist sinnvoll, über Codevalidierung zu sprechen, wenn sie in eine breitere Perspektive gestellt wird, ohne zu weit ins Detail zu gehen. Daher ist es bei der Struktur, den Modulen, aus denen die E-Mail besteht, und den Tabellen, die das Rückgrat der Kommunikation bilden, absolut sinnvoll, einen Code zu verwenden, der so sauber ist und dem vom W3C diktierten Standard entspricht wie möglich.

Allerdings müssen wir uns der Realität bewusst sein, und so besteht der Kompromiss in der Schaffung einer soliden und funktionalen Struktur, zu der die Workarounds als eine Art Feintuning hinzugefügt werden, um die korrekte Visualisierung auf möglichst viele Clients auszudehnen.

Wir wissen bereits, dass Workarounds nichts weiter als Ausnahmen von der Regel sind oder nicht perfekt orthodoxe Techniken, die aus durch Erfahrung gesammeltem Wissen abgeleitet sind, aber ihre Existenz macht nur Sinn, weil sie es ermöglichen, den Code ohne Depagation korrekt zu visualisieren.

Unser Rat:

• Wenn Sie Zweifel am Code haben, kann die Validierung als schnelles und effektives Werkzeug für die Analyse dienen
• Die Codevalidierung kann ein gutes Werkzeug sein, um die größten Fehler in einer Codeliste schnell zu identifizieren
• Validierter Code ist immer ein hervorragender Ausgangspunkt, um die Kommunikation mit Workarounds später weiterzuentwickeln und anzupassen, um sie so universell wie möglich zu gestalten
• Validierung kann als „Service“ für den Code angesehen werden, insbesondere bei Modellen, die häufig manipuliert und überarbeitet wurden
• Bauen Sie mit zunehmender Erfahrung eine kleine Bibliothek mit Ad-hoc-Lösungen für verschiedene Kunden auf, um bei der Problemlösung Zeit zu sparen