Fallstricke im Responsive Webdesign

Was Responsive Webdesign (RWD) meint, ist klar: Ein Layout, das sich flexibel an die Bildschirmgröße des Clients anpasst – für einen perfekten Auftritt auf dem Smartphone ebenso wie auf dem UltraHD-TV.

Doch was so schön klingt, birgt auch viele Fallstricke: “Welche Eigenschaften sind bei Responsive Newslettern zu beachten?”, “Wie gehe ich mit der Einbettung von iFrames um?”, “Gibt es unterschiedliche Bedienung von dynamischen Inhalten?”, etc. fragt sich der Entwickler.

In diesem Beitrag stelle ich einige Problemstellungen und deren Lösungsansätze vor.

Embeded Code: iFrames

Embeded Code, der beispielsweise von Video- oder Social Media-Plattformen kopiert und in die Website eingefügt wird, beinhaltet oft eine vordefinierte Höhe und Breite in Pixel. Bei RWD passen sich diese nun an die Bildschirmgröße des Clients an. Um das zu erreichen, könnte man clientseitig die Größe mit JavaScript dynamisch anpassen. Es wird funktionieren, wäre jedoch nicht so flexibel wie folgender CSS basierte Ansatz:

Im ersten Schritt werden die Größenangaben aus dem Embeded Code entfernt:

<!-- original -->
<iframe
src="http://player.vimeo.com/video/32071937?title=0&amp;byline=0&amp;portrait=0"
width="400"
height="225"
frameborder="0"
webkitAllowFullScreen mozallowfullscreen allowFullScreen>
</iframe>

<!-- removed width/height -->
<iframe
src="http://player.vimeo.com/video/32071937?title=0&amp;byline=0&amp;portrait=0"
frameborder="0"
webkitAllowFullScreen mozallowfullscreen allowFullScreen>
</iframe>

Im nächsten Schritt wird ein Container um den Embeded Code gelegt, welcher später die Größe regulieren soll:

<div class="embed-container">
<!-- embed code goes here-->
</div>

Nun folgt das Styling des Containers und dessen Inhalt:

.embed-container {
    position: relative;
    padding-bottom: 56.25%; /* 16/9 ratio */
    padding-top: 30px; /* IE6 workaround*/
    height: 0;
    overflow: hidden;
}

.embed-container iframe,
.embed-container object,
.embed-container embed {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
}

Das wars schon. Beispiele hierzu findet ihr auf jsFiddle:
– Vimeo Video
– Youtube Video
– Slideshare Präsentation

Thierry Koblentz berichtet auf alistapart.com ausführliche zu diesem Ansatz.

Responsive Newsletter

Wer kennt es nicht: Man ruft nichtsanehnd seine E-Mails ab und stößt auf schrecklich dargestellte Newsletter. Zunehmender kommt es vor, dass auch Newsletter dabei sind, die sich der Bildschirmgröße anpassen und so aufbereitet sind, dass man sie entspannt lesen kann: simpel aufgebaut und gegliedert, angenehm zu lesen und einspaltig in einer Tabelle aufbereitet.

HTML-Newsletter sind und bleiben ein beliebtes Kommunikationsmittel, um Informationen zu transportieren. Wie im Webdesign geht auch hier der Trend in Richtung Responsive E-Mail.

Der Großteil der E-Mail-Clients versteht HTML, jedoch weitab von modernen Webstandards. Als Tenor bei der Umsetzung gilt „Code like 1999“: verschachtelte Tabellen, Font-Tags und Inline-CSS, keine CSS-Positioning über floats. Um den Frust durch „Learning by failing“ zu reduzieren, empfehle ich, sich im Vorfeld über Tools, die CSS Unterstützung von E-Mail-Clients, Top-Listen und How-To Guides zu informieren:

• Email Client Popularity
• CSS Guides: The Ultimate Guide to CSS
• How-To Guide: Responsive Newsletter
• HTML E-Mail Boilerplate
• CSS Inline-Style-Konverter

Media Queries

So obstrus „Code like 1999“ und Media Queries (MQ) klingt, es lässt sich dennoch vereinbaren. Die gängigsten mobilen E-Mail Clients unterstützen MQ. Eine Auflistung dieser ist hier zu finden. Um sich möglichen Frust zu sparen, sollte man die Umsetzung nach dem „Mobile First“ Prinzip erledigen. Hier werden im Vorfeld viele Probleme, im Hinblick auf das Verhalten, auf mobilen Geräten entschärft.

Testing

Um das Testen auf unterschiedlichen E-Mail-Clients zu beschleunigen, wurden bereits zahlreiche (zum Teil kostenpflichtige) Tools entwickelt: Litmus, Email on Acid, Puts Mail, Mailchimp. Campaignmonitor oder ActiveCampaign. Bei diesen Testing-Tools wird der Newsletter an verschiedene Clients gesendet. Resultat dieser Tests ist ein Screenshot vom Newsletter im jeweiligen Client. Erfahrungsgemäß gibt es bei älteren Clients (z.B. Outlook 2003) die meisten Schwierigkeiten. Zum schnelleren Testen auf diesen Clients ist es hilfreich, diese zusätzlich auch lokal zur Verfügung haben.

Konvertieren von alten Websites mit fester Breite

Eine große Herausforderung stellt die Migration einer Website mit fester Breite zu einer Responsive Website dar.

Da die Code-Basis dieser Websiten auf einer fixen Breite basiert, ist man mit der Frage konfrontiert, ob der bestehende CSS und HTML Code angepasst werden soll (Reverse Engineering), oder die Website von Grund auf neu zu schreiben ist.

In der Regel wurden die Inhalte und Layouts von alten Websiten nicht auf die mobile Nutzung ausgelegt. Im Zuge der Konvertierung müssen diese Inhalte ebenso angepasst werden, wodurch sich die Arbeit nicht ausschließlich auf die technische Umsetzung beschränkt.

Bei kleineren Webseiten macht Reverse Engineering durchaus Sinn. Das Risiko von Seiteneffekten ist geringer, der Aufwand zum Testen der Anpassungen ebenfalls.

Bei größeren Seiten hingegen ist das Risiko, dass Seiteneffekte entstehen, erheblich größer. Laut einer Umfrage von James Young empfiehlt sich hier eine von Grund auf neue Umsetzung unter Beachtung des responsive Workflows.

Adaptive Maps

Nicht nur das Layout einer Website lässt sich mitunter schwer für die mobile Darstellung optimieren, auch verschiedene Inhalte sorgen regelmäßig für Unmut. Hierzu zählen beispielsweise Tabellen, Videos und Bilder oder auch eingebettete Google Maps. Viele Websiten verwenden diese Maps. Sie informieren darüber,  wo ein Veranstaltung stattfindet, wo ein Unternehmen ansässig ist, bieten die Möglichkeit eine Route zu planen oder zeigen die nächstgelegenen Händler auf.

Um eine Google Maps einzubinden gibt es viele Varianten. Die einfachste ist die Einbindung mittels iFrame. Die Einbindung kann weiters auch mittels Google Maps Javascript API oder den Google Static Maps erfolgen.

Die iFrame Variante sieht nicht nur gut aus, sondern lässt sich auch einfach bedienen. Bis zu dem Zeitpunkt, zu dem die Map auf einem Mobilen Gerät genutzt wird. Zwar wird die mobile Bedienung unterstützt, jedoch lässt die Bedienbarkeit der Website zu wünschen übrig. Scrollt man die Website und berührt dabei mit dem Finger die Map, navigiert man plötzlich in der Map und nicht mehr auf der Website.

Ein Lösungsansatz hier ist, auf der Desktopvariante die Google Map mittels iFrame einzubinden und auf der mobilen Version die Static Map anzuzeigen. Nützt man die Einbindung mittels der Javascript API, ist diese Entscheidung natürlich von der Funktion und dem Umfang der Map abhängig.
Eine Beispiel dazu findet ihr hier

Fazit

Neben den hier dargestellten Beispielen gibt es noch viele weitere Fallstricken. Für viele dieser Herausforderungen finden sich etablierte Lösungsansätze. Basierend auf dem Motto “Warum das Rad neu erfinden?” empfehle ich, sich zunächst bestehende Lösungsmuster anzusehen, diese bei Bedarf einzusetzen, sich dabei inspirieren zu lassen oder auch neue Lösungen zu etablieren.