Archiv für die Kategorie: "Technik"
Die Breite und Länge eines Newsletters – Weniger ist oft mehr!
Internet wird immer öfter mobil genutzt und die Endgeräte, welche hierfür zum Einsatz kommen, sind ebenso oft Smartphones, Pocket-PCs oder Mininotebooks. Auf der anderen Seite werden die Monitore immer größer, also für welches Gerät sollte nun der Newsletter optimiert werden?
Internetseiten kann man so programmieren, dass sie sich dem Bildschirm des Nutzers anpassen aber E-Mails bieten solche Möglichkeiten nicht. E-Mails (auch Newsletter) werden oft überflogen und schnell gelesen. Darüber hinaus lesen viele ihre E-Mails im Vorschaufenster ihres E-Mail Clients. Ein Newsletter dürfte daher nicht länger als 1024 Pixel sein. Der Versand eines Newsletters mit 2000 Pixel ist oft reine Informationsverschwendung! Auch die Breite spielt eine große Rolle. Nicht zu schmal aber auch nicht sehr breit! 600 bis 700 Pixel sollten nicht überschritten werden. Wenn möglich sollte man aber bei 600 Pixel bleiben.
600 x 1024 Pixel ist also eine gute Universalgröße und so können auch die mobilen Nutzer den Newsletter ziemlich gut lesen.
Navigationsleiste in HTML-Newsletter funktioniert nicht immer! Es gibt aber eine Lösung!
Gerade bei etwas umfangreicheren Newsletter ist es sinnvoll eine Navigations- bzw. Menüleiste anzubieten, um dem Empfänger einen besseren Überblick zu verschaffen aber…
In Lotus Notes funktionieren diese sogenannten Anker-Links nicht. Auch bei diversen anderen Webmailern kommt es immer wieder zu Problemen. Diese Verweise sind jedoch sehr wichtig, denn ohne sie muss der Empfänger die ganze Zeit hin und her scrollen und verliert irgendwann die Lust am Lesen. Also wie kann man das Problem umgehen?
Ganz einfach! Über die Webversion des Newsletters kann man dieses Problem lösen, in dem man den Empfänger mit dem Klick auf den Menülink direkt auf die Webversion weiterleitet.
Hier ein Beispiel:
Quellcode der HTML-E-Mail
<a href=”http://www.muster-webversion-newsletter.de/#Anker1″>Link1</a>
Quellcode der Webversion des HTML-Newsletters
<a name=”Anker1″>Ziel1</a>
So wird der Empfänger mit dem Klick direkt auf die Webversion des Newsletters und genau auf die gewünschte Stelle geleitet und kann weiterhin den Newsletter ohne Einschränkungen weiterlesen. Das funktioniert aus jedem E-Mail-Clint und Webmail heraus!
Ein richtig gewähltes Character-Set (Zeichencodierung) ist für HTML E-Mails sehr wichtig
Zeichencodierungsfehler in HTML E-Mails gefährden auch den Erfolg einer Kampagne!
Jeder hat schon einmal diesen Effekt gesehen. Die E-Mail sieht plötzlich nicht mehr so aus, wie sie aussehen sollte. Bindestriche werden als Quadrate angezeigt und aus “ß” wird “?” usw. Aber woran liegt das? Schließlich am eigenen Bildschirm sah alles ganz gut und fehlerfrei aus!
Dieses Problem taucht auf, wenn z. B. E-Mail-Programme wie Outlook oder Lotus Notes empfangene E-Mails decodieren und anzeigen möchten und dabei keine Zeichencodierungsvorgaben vorfinden. Somit kann die Darstellung der Sonderzeichen fehlschlagen!
Zeichencodierungstabellen
Um das Problem besser zu verstehen, gehe ich an dieser Stelle kurz auf “Character-Set” ein. Jeder Buchstabe und jedes Zeichen ist in einer bestimmten Codierung hinterlegt und wird auch danach angezeigt. Im Laufe der Zeit kamen aus diversen Gründen (Sonderzeichen, Sprachen usw.) verschiedene Codierungstabellen zustande und damit ist auch ein neues Problem geboren! Wenn ein Zeichen in einer Tabelle nicht definiert ist, kann es auch nicht nach der Codierung dieser Tabelle dargestellt werden! Wenn man einen Text verfasst und die Codierung nicht vorgibt, können andere Programme und Server, die eine andere Codierung als Standard benutzen den Text unter Umständen nicht fehlerfrei anzeigen. Die am meisten verbreiteten Codierungen sind ISO-8859 und UTF-8.
Wie kann man das Problem vermeiden?
Der E-Mail-Server muss richtig konfiguriert sein und die E-Mails mit der richtigen Codierung verschicken. Natürlich kann man im Quellcodebereich “<head>” mit der Angabe der Meta-Tag eine Codierung vorgeben, jedoch viele E-Mail-Server überschreiben den Bereich “<head>” mit eigenen Angaben! Daher sollte die Konfiguration unbedingt auf der Server-Ebene vorgenommen werden.
Hier sind zwei Beispiele für die Meta-Tag-Angabe:
Für HTML
<meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1″>
Für XML
<?xml version=”1.0″ encoding=”utf-8″?>
target=“_blank“ und andere Sorgen - Wie programmiert man einen Newsletter?
Man trifft im Netz oft den Hinweis, „setzt bitte target=“_blank“ für alle Links, damit sie in ein neues Fenster aufgehen“ aber ist es wirklich so wichtig?
Das mag wohl für die Webversion des Newsletters (Landingpage) wichtig sein jedoch E-Mail Clients wie Outlook oder Lotus Notes öffnen automatisch ein neues Fenster und viele Webmails ebenfalls.
Wenn man einen Newsletter programmieren möchte, hat man ganz andere Sorgen! Viele CSS-Befehle werden von diversen Clients oder Webmails nicht korrekt interpretiert. Man kann sagen, dass die Programmierung einer HTML-Email sich von Webdesign komplett unterscheidet. Die Technik kommt hier zuerst. Daher sollte man ganz genau prüfen, welche Befehle unterstütz werden, dann wird schnell deutlich, dass die Möglichkeiten begrenzt sind.
Design-Probleme sollte man aber auch nicht immer mit Bildern lösen. Wenn das Bild-Text-Verhältnis zu groß wird, könnte die Email auch als Spam markiert werden.
Die ganze Sache kann also schnell ins Auge gehen. Nicht selten bekommen wir Newsletter, die mit Microsoft Word erstellt und dann als Webseite gespeichert wurden. Viele denken, dass sie so Geld sparen und damit argumentieren, dass sie auch früher Newsletter und E-Mails über Outlook verschickt haben. Auf die Frage ob sie jemals gesehen haben, wie sie beim Empfänger ankamen, erfolgten nicht selten Sekunden der Stille. Nicht immer bekommt man eine Reaktion vom Empfänger. Viele löschen einfach die E-Mails (falls sie überhaupt ankommen sollten) oder bestellen den Newsletter ab. Also wenig oder gar keine Beschwerden heißt nicht automatisch, dass alles in Ordnung sein muss. Hier ist es wieder die Kommunikation gefragt. Auch mal nachfragen, wie die Newsletter beim Empfänger ankommen.
Anmeldungen für einen Newsletter sind wichtig. Noch wichtiger ist es aber sie auch zu behalten!
Darstellung von HTML-Newsletter in IBMs Lotus Notes
Ein wirkliches Problem, womit alle E-Mail Marketer und Dienstleister zu kämpfen haben ist die Darstellung in IBMs Lotus Notes.
Warum sich IBM nicht zumindest an die Mindestanforderungen wie Microsoft mit Outlook 2007 hält ist unbegreiflich. Ändert jedoch nichts daran, dass in der Finanzbranche überwiegend Notes im Einsatz ist.
Um sich von vorne herein viel Ärger zu sparen, empfehlt es sich erst einmal anzuschauen was Notes wirklich unterstützt und was nicht. CSS-Anweisungen werden nur zum Teil unterstützt. Eine gute Übersicht bietet daher die Webseite email standards project. Da sieht man unter anderem auch, dass Befehle wie „Margin“ und „Padding“ nicht unterstützt werden.
Bewegt man sich jedoch überwiegend in B2C Bereich, muss man sich eher Outlook 2007 und die Webmailer unter die Lupe nehmen. Aber meistens wenn eine E-Mail in Lotus Notes gut aussieht, wird zu 99% überall anders auch eine gute Figur machen.
Danke an allen Kommentatoren, die diesen Beitrag mit wertvollen Hinweisen ergänzt haben!
Hier finden Sie weitere sehr nützliche Links zum Thema HTML-Newsletter Programmierung:
- CampaignMonitor: Guide to CSS support in email clients
- sitepoint: How to Code HTML Email Newsletters
- 24 ways: Rock Solid HTML Emails
E-Mail Zustellung, Behinderungen und Maßnahmen
Was ist das richtige Rezept um die E-Mails an den Mann zu bringen?
Spam nimmt immer stärker zu und so treffen Provider und auch viele Unternehmen immer drastischere Maßnahmen, um sie zu stoppen. So bleiben aber auch viele gute E-Mails auf der Strecke. Also was kann man unternehmen?
SPF (Sender Policy Framework), SRS (Sender Rewriting Scheme), CSA (Certified Senders Alliance) oder SSC (Sender Score Certified) oder auch alle zusammen? Aber bringen sie auch wirklich was oder am Ende hat man nur sehr viel Geld für diverse Dienste ausgegeben, die alle noch nicht richtig ausgereift sind und mal hier und mal da eingesetzt werden?
Fakt ist, dass sich auch ISP’s darüber nicht einig sind, was man nun als Standard nehmen sollte. Auf Vor- und Nachteile der Einzelnen möchte ich hier nicht näher eingehen aber eine richtige Lösung bieten sie alle (noch) nicht an! Man muss zusätzlich noch zwischen B2B und B2C unterscheiden! Die obigen Maßnahmen bringen nicht viel, wenn man viel in B2B Bereich unterwegs ist. (noch nicht!)
Richtig konfigurierte E-Mail-Server, korrektes Bounce-Handling und die Überprüfung der Texte auf Spamwahrscheinlichkeit, da sollte man ansetzten und sicherstellen, dass alles vorschriftsmäßig läuft.
Testen, testen, testen! Die Bestimmungen der ISP’s beachten und die Server dementsprechend konfigurieren. Sich gut beraten lassen oder Kunden immer über die Schulter schauen und sie gut beraten und auf Gefahren aufmerksam machen.
Wer das alles tut, kann auch gute Ergebnisse erwarten!








