Responsive ist nicht gleich responsive: Optimierung von E-Mails für Mobilgeräte

Über 50% der Öffnungen von E-Mails erfolgen heute auf Mobilgeräten. Einen guten Grund, E-Mails nicht für diesen Gerätetyp zu optimieren, gibt es nicht mehr. Diese Erkenntnis hat sich in den vergangenen Jahren glücklicherweise fast überall durchgesetzt. Aber: Responsive Design für E-Mails ist nicht mit responsive Design für Webseiten zu vergleichen.

Als «Responsive Design» wird der Ansatz bezeichnet, eine Webseite – oder in unserem Fall eine E-Mail – so aufzubauen, dass sich die Darstellung automatisch der Bildschirmgrösse des empfangenden Gerätes anpasst. So werden beispielsweise die gleichen Elemente auf einem Desktop Computer nebeneinander und auf dem Smartphone untereinander angeordnet.

Responsive DesignBei Webseiten lässt sich dank modernen Web-Browsern und einheitlichen Standards (HTML 5 / CSS 3) ein hohes Mass an Flexibilität in der Darstellung erreichen. Von Desktop-Bildschirmen mit Auflösungen von 2560×1440 Pixeln bis zu Smartphones mit 320×40 Pixeln können die Elemente möglichst optimal angeordnet und skaliert werden.

Limitierte Möglichkeiten auf Desktop E-Mail Clients

Von E-Mail Clients werden die gängigen Web-Standards leider nur sehr beschränkt unterstützt und der verfügbare Platz für die Darstellung der E-Mails lässt sich oft nicht ermitteln. Zudem kann keine Programmlogik (JavaScript) in eine E-Mail eingebaut werden. Als Best Practice hat sich eine Breite des E-Mail Inhaltes von circa 600 Pixeln durchgesetzt. Diese Breite wird auf den meisten Webmail-Clients (wie GMail, Bluewin oder GMX) sowie in der Vorschau von Desktop-Programmen wie Outlook meist vollständig angezeigt und kann bei Standardeinstellungen auf eine A4 Seite ausgedruckt werden.

«Liquid» auf Mobilgeräten

Responsive-Design iPhone-AndroidBei Smartphones ist in den vergangenen Jahren eine unüberschaubare Zahl an Bildschirm-Abmessungen entstanden. Die Breiten reichen dabei von 240 bis 480 Pixeln, was einer Bandbreite von 100% entspricht. Um mit diesen grossen Unterschieden umgehen zu können, setzt man heute vorwiegend auf die sogenannte «Liquid»-Variante des Responsive Designs, bei welcher die Elemente nicht anhand vordefinierter Schwellenwerte (sog. Break-Points) schrittweise skalieren, sondern sich «flüssig» der Bildschirmbreite anpassen.

Der Nachteil dieser Variante ist, dass Bilder vom Endgerät skaliert werden. Das hat eine etwas schlechtere Qualität zur Folge, als wenn die Bilder über eine leistungsfähige Software wie z.B. Photoshop skaliert und in allen benötigten Grössen anhand der Schwellenwerte bereitgestellt werden. Ebenso ist eine Absatzkontrolle in Fliesstexten dadurch nicht möglich.

Diese Nachteile werden jedoch durch die bessere Ausnutzung des verfügbaren Platzes auf dem Bildschirm und somit weniger Scrolling, sowie dem geringeren Aufwand bei der Erstellung der Mailings (weniger Aufwand bei der Bildproduktion) mehr als aufgewogen.

Neue Einschränkungen auf Google Plattformen

Für die Umsetzung der Responsiveness haben sich so genannte «CSS Media Queries» durchgesetzt. Diese werden von Apple-Geräten (iPhone/iPad) in der nativen Mail-App gut unterstützt. Auf der Android Plattform sowie verschiedenen Apps wie GMail, GMX oder auch Bluewin ist deren Unterstützung jedoch sehr uneinheitlich. Während die bei Android standardmässig installierte Mail-App bis Version 5 Media Queries noch unterstützt hat, werden diese von der neusten Version auf Android 6 wie auch von der GMail App, Inbox by GMail, Bluewin und der GMX-App komplett ignoriert. Löbliche Ausnahme ist hier für einmal Microsoft. Die Outlook Mobile App für Android und iOS unterstützt Media Queries einwandfrei.

Wie soll man damit umgehen? Die skalierte Desktop-Ansicht ist auf Smartphones in der Regel unbrauchbar. Der «Mobile First» Ansatz, bei welchem E-Mails primär auf Mobilgeräte optimiert werden, führt auf klassischen Desktop-Clients, wie dem nach wie vor sehr weit verbreiteten Outlook, zu unschönen Darstellungsfehlern oder – im besten Fall – zu übergross angezeigten Bildern auf grossen Bildschirmen.

Der goldene Mittelweg: Hybrid-Coding

Mitte des letzten Jahres tauchten erste Ansätze des sogenannten «Hybrid-Codings» auf. Dabei wird der HTML Code so aufgebaut, dass auf Mobilgeräten und Apps ohne Unterstützung von Media Queries die Elemente wenigstens untereinander geschoben werden und somit der Inhalt der E-Mail auch ohne manuelles Skalieren lesbar ist. Hybrid DesignAuf Webmail- und Desktop-Clients werden die Elemente wie gewohnt nebeneinander angezeigt und auf mobilen Geräten mit Unterstützung von Media Queries greift die Liquid-Variante. Letztere beinhaltet sämtliche Optimierungen für den mobilen Medienkonsum wie alternative, optimierte Bilder, grössere Schriftarten, auf Touch-Bedienung optimierte Schaltflächen sowie mehr Abstand zwischen den klickbaren Elementen. Somit wird auf jedem Gerätetyp die bestmöglich optimierte Variante angezeigt.

Und der Nachteil? Der Hybride Code wird noch einmal komplexer. Es müssen im Grunde drei unterschiedliche Ansätze der HTML-Entwicklung mit stark abweichenden Anforderungen in einem Quellcode zusammengeführt werden. Denn der Quellcode lässt sich, ist die E-Mail einmal versandt, nicht mehr verändern. Ein komplexer Code erhöht die Anforderung an den Entwickler, an das Testen und an die Wartung. Selbst hoch qualifizierte Web-Entwickler beissen sich an den Anforderungen von einem E-Mail Code die Zähne aus. Viele Designs lassen sich nur mit aufwändigen Tricks (sog. «Tweacks») umsetzen. Zum Testen müssen spezielle Plattformen sowie eine Auswahl an physischen Endgeräten eingesetzt werden.

Hybrid-Design iPhone-AndroidWird eine Software wie das auf Campaign Monitor aufbauende MayorisEASY verwendet, kann in der Regel auf eine umfangreiche Bibliothek von Templates (Vorlagen) zurückgegriffen werden, welche nach neusten Coding-Standards entwickelt oder auf diese aktualisiert wurden. Werden jedoch Enterprise Systeme eingesetzt oder erlauben CI/CD Guidelines und Branding keinen Einsatz von Standard Templates, führt oft kein Weg an der Umsetzung eines Individual-Templates durch eine spezialisierte Agentur – mit entsprechenden Kosten – vorbei. Dafür ist aber auch garantiert, dass die Darstellung auf allen Clients soweit wie technisch möglich, optimiert und getestet wurde.


Zurück zur Übersicht

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>