Archiv für den Monat Juni 2012

Magento Responsive Design

Montag, 25. Juni 2012

  1. Fluid Grid
  2. Statisches Grid
  3. Breakpoints
  4. Media Queries
  5. lt IE9
  6. Brauche ich Responsive Design in meinem Magento Shop?
  7. Pros
  8. Cons
  9. symmetrics – Ihr Partner für Magento-Responsive Design


Fluid Grid

Nach Ethan Marcotte’s Ideologie, ist Responsive Design die Gestaltung der Website über flexible Weiten, um sie je nach Bildschirmgröße des Besuchers individuell anzupassen.

In der Praxis sieht das so aus, dass wenn ein Besucher mit FullHD Bildschirm auf eine Responsive Website kommt, kriegt er mehr auf einmal zu sehen, als ein Besucher mit nur 1024×768 Auflösung. Inhaltlich sind aber beide Seiten gleich. Schön zu sehen auf folgenden Seiten:

http://css-tricks.com/
http://www.smashingmagazine.com/

Seit längerem beschäftigen wie uns bei symmetrics mit Magento Responsive Design und arbeiten neben der theoretischen Grundlage aktiv an ersten Kundenprojekten und Magento Themes. In Magento sind Fluid Grids in einem bestehenden Shop unter hohem Zeitaufwand gegenüber statischem Grid umsetzbar. Beinah jegliche Weiten und Abstände müssen in Prozent angegeben werden. Intelligente Floatings sind u.U. neu zu erarbeiten. Gleiches gilt für Produktbilder und weitere andere Grafiken. All das müsste von Anfang an in einem Magento Projekt geplant werden oder in einem bestehenden Magento Template angepasst werden. Designvorlagen vorausgesetzt, denn man läuft Gefahr, dass sich das Erscheinungsbild des Shops mit flexiblen Weiten stärker verändert als mit festen Weiten. Plant man all das vor einem Projekt, fällt schnell der Begriff „Mobile First“ – die Erstellung einer Website beginnend mit dem nötigsten für einen Mobilen Shop, um den Kern zu erarbeiten und dann auf Desktopgröße hoch zu ziehen und mit Inhalten wie Upsells, Crosssells, Callouts und mehr zu füllen.


Statisches Grid

Wenn Sie gerade auf einem Desktoprechner unterwegs sind, ziehen Sie testweise einmal das Browserfenster zusammen und auseinander und sehen Sie, wie sich der Inhalt an die Weite des Fensters anpasst.  Eine weitere schöne Seite die das statische Grid veranschaulicht finden Sie unter http://framelessgrid.com/.

Die Vorteile von festen Weiten an bestimmten Breakpoints, Breakpoints werden im nächsten Abschnitt erklärt, sind daher in einen bestehenden Shop schneller und damit kostengünstiger umzusetzen. Das Design kann zu jedem Breakpoint festgelegt werden und man kann somit das Layout für jeden Step bestimmen. Das Design wirkt effizienter und bestimmender, denn während bei Fluid Grid der Inhalt prozentual gestaucht wird, reicht es auch oft aus einfach nur die font-size und die Weite einiger Elemente zu verringern.

Probleme kann es geben, wenn man die Seite speziell auf Mobile Devices anpassen will. Die feste Größe kann hier aufgrund der verschiedensten Auflösungen mehr Anpassungen benötigen. Ein Fluid Grid kann hier seine Vorteile ausspielen, da es sich genau an die Weite anpasst. Man kann also ein Mix aus Fluid und statischem Grid als Idee anbringen. Jedoch können z.B. gezielt iPhone und iPad  Auflösungen angesprochen werden und die User-Experience angehoben werden.


Breakpoints

Geht man von einem bereits bestehenden Magento Shop aus – egal ob Fluid oder Frameless Grid -  benötigt man festgelegte Breakpoints. Breakpoints können ganz einfach bestimmt werden – Browserfenster auf die maximale Weite bringen. Dann von rechts nach links das Fenster kleiner ziehen. Sobald die Seite horizontal anfängt zu scrollen, ist man am ersten nötigen Breakpoint angekommen.

Für gewöhnlich werden die Breakpoints 320, 480, 760, 1024 (Größen für z.B. iPhone/iPad Landscape und Portrait-Orientation) und aufwärts genutzt – wobei der Gedanke hinter Responsive Design nicht als die Anpassung einer Website an Mobile Geräte gedacht war, es ist nur ein positiver Effekt den man nutzen kann. Am Ende muss aber jede Seite speziell auf Breakpoints überprüft werden.

Diese Analyse unternehmen wir von symmetrics mit unseren Magento Kunden vor einem Projekt oder bei den zahlreichen Magento Shops, die zu uns umziehen im Rahmen der Weiterentwicklung.

In der Praxis konnten die sinnvollsten Breakpoints in der Kategorieansicht ermittelt werden. Geht man von FullHD Auflösung aus, so kann beispielsweise eine 8er Grid gezeigt werden. Staucht man das Browserfenster zusammen sollte jeder Breakpoint so gewählt werden, dass bei z.B. 1800px nur noch eine 7er Grid ist, bei 1600px eine 6er Grid und immer so weiter. Mit Hilfe dieser ermittelten Breakpoints aus der Kategorieansicht kann man weiterarbeiten. Danach folgen Header- und Footeranpassungen.


Media Queries

Um mit dem Magento Responsive Design zu beginnen wird zunächst ein Meta Template benötigt um das Viewport Scaling bei Mobile Devices zu unterbinden. Das automatische Zoomen auf den Websiten Container von iOS kann dazu führen, dass die Bildqualität sinkt und Größen, bzw. Proportionen verfälscht werden.

Der Block sowie die CSS werden wie folgt in die Module Layout XML eingebunden:

<layout version="0.1.0">
    <default>
        <reference name="head">
            <action method="addCss"><stylesheet>css/responsivedesign.css</stylesheet></action>
            <block type="page/html_head" name="responsive.head" template="page/html/responsive-head.phtml" />
            </reference>
    </default>
</layout>

In das Magento Template wird folgender Inhalt eingefügt:

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0" />

Als Alternative hier die Einbindung des Viewport Metas ausschließlich über Layout XML mit:

<layout version="0.1.0">
    <default>
        <reference name="head">
            <block type="core/text" name="responsive.viewport">
                <action method="setText">
                    <text>
                    <![CDATA[<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0" />]]>
                    </text>
                </action>
            </block>
        </reference>
    </default>
</layout>

In die CSS kommen dann die Standard und individuellen Breakpoint Media Queries.

/* Smartphones (portrait and landscape) ----------- */
@media only screen
and (min-device-width : 320px)
and (max-device-width : 480px) {
/* Styles */
}

/* Smartphones (landscape) ----------- */
@media only screen
and (min-width : 321px) {
/* Styles */
}

/* Smartphones (portrait) ----------- */
@media only screen
and (max-width : 320px) {
/* Styles */
}

/* iPads (portrait and landscape) ----------- */
@media only screen
and (min-device-width : 768px)
and (max-device-width : 1024px) {
/* Styles */
}

/* iPads (landscape) ----------- */
@media only screen
and (min-device-width : 768px)
and (max-device-width : 1024px)
and (orientation : landscape) {
/* Styles */
}

/* iPads (portrait) ----------- */
@media only screen
and (min-device-width : 768px)
and (max-device-width : 1024px)
and (orientation : portrait) {
/* Styles */
}

/* Desktops and laptops ----------- */
@media only screen
and (min-width : 1224px) {
/* Styles */
}

/* Large screens ----------- */
@media only screen
and (min-width : 1824px) {
/* Styles */
}
/* iPhone 4 ----------- */
@media
only screen and (-webkit-min-device-pixel-ratio : 1.5),
only screen and (min-device-pixel-ratio : 1.5) {
/* Styles */
}

Die Übergabe der Media Queries per CSS ist nur ein Weg um die Styles zu bearbeiten. Ein anderer Weg wäre, die Breakpoint Media Queries auf eigene CSS Dateien aufzuteilen, um bei großen Projekten Dateigrößen einzusparen.

<layout version="0.1.0">
    <default>
        <reference name="head">
            <action method="addCss">
                <stylesheet>css/filename.css</stylesheet>
                <params>media="screen and (min-width: 701px) and (max-width: 900px)"</params>
            </action>
        </reference>
    </default>
</layout>

Im Gegensatz zur Magento Community Edition ist bei der Magento Enterprise Edition zu beachten, dass mit dem CSS Merge die generierte media.css die Funktionalität der Ermittlung der Media Queries über das link-Tag unterbunden wird. Dies kann man umgehen, indem man entweder per Layout XML die CSS so einbindet:

<layout version="0.1.0">
    <default>
        <reference name="head">
            <block type="core/text" name="media.900">
                <action method="setText">
                    <text>
                        <![CDATA[<link rel="stylesheet" media="screen and (min-width: 701px) and (max-width: 900px)" href="css/filename.css" />]]>
                    </text>
                </action>
            </block>
        </reference>
    </default>
</layout>

Oder in die erstellte responsive-head.phtml unter dem Viewport Meta diese Zeile einfügt.

<link rel="stylesheet" media="screen and (min-width: 701px) and (max-width: 900px)" href="css/filename.css" />

lt IE9

Thema Internet Explorer. Für IE8 und darunter wird entweder respond.js oder media-queries.js verwendet. Falls Responsive Design im Shop ausschließlich für Mobile Devices genutzt werden soll, kann auf das Fallback-Script verzichtet werden, da IE8 und geringer dort keine Verwendung findet.

<layout version="0.1.0">
    <default>
        <reference name="before_body_end">
            <block type="core/text" name="lt.ie9.responsive" after="-">
                <action method="setText">
                    <text>
                        <![CDATA[<!--[if lt IE 9]><script src="http://css3-mediaqueries-js.googlecode.com/svn/trunk/css3-mediaqueries.js"></script><![endif]-->]]>
                    </text>
                </action>
            </block>
        </reference>
    </default>
</layout>

Brauche ich Responsive Design in meinem Magento Shop?

Für Shopbetreiber ist es nun schwer sich zu entscheiden, ob man Responsive Design braucht oder nicht. Daher eine erste Pro/Contra Liste, die bei der Entscheidungsfindung helfen soll.

Pros

  • Auflösungen von Handy bis FullHD können optimal dargestellt werden.
  • Technik wird großflächig unterstützt
  • Mehr mögliche Werbung auf Landing Pages / Homepage / Kategorie-Callouts
  • Der Kunde sieht mehr auf einmal und kann Produkte in der Grid besser vergleichen
  • Mögliches Alleinstellungsmerkmal – neuartige Technik im E-Commerce Bereich
  • Bei kleinen Screens ist kein horizontales Scrolling nötig und man verpasst somit kein Inhalt
  • Technik mit geringstem Aufwand, Webshops an jedes beliebige Mobile Device anzupassen
  • Keine großen Frameworks/Libraries nötig
  • Hoch- und Querformate von Mobile Devices können unterschiedlich genutzt werden
  • Inhalte umstrukturieren, nicht löschen
  • Geringer Testaufwand
  • Bessere Bedienbarkeit auf Mobile Devices
  • Ein Template, welches sich an alle Bildschirmgrößen auf Desktoprechner sowie an Mobile Devices wie Tablets und Smartphones anpasst
  • Kostenersparnis durch einmaliges Invest in ein Magento Responsive Theme anstatt mehrere optimierte Templates für verschiedene Geräte zu bauen
  • Conversionoptimierung durch zufriedene Kunden und geringere Kaufabbrüche im Shop

Cons

  • Gewöhnungsbedürftiges Layout in großen Darstellungen

symmetrics – Ihr Partner für Magento-Responsive Design

Als Europas größter Magento Gold Partner haben wir uns als erstes Unternehmen für Magento Shops  in der Magento Community und Magento Enterprise auf die Erstellung von Magento Responsive Designs fokussiert und hier umfangreiche Expertise aufgebaut, wir bieten Online Händlern jeder Größe hier:

  • Beratung bei theoretischen Grundlagen und Maßnahmen zur Conversionoptimierung und Umsatzsteigerung durch Magento Responsive Design
  • Analyse des Designs bestehender oder auch neuer Webshops
  • Konzepterstellung für Handy,Tablet bis hin zu FullHD Bildschirmen unter Einhaltung von Corporate Designs
  • Aussprache von Empfehlungen und Zusammenarbeit mit Designagenturen sowie agile Anpassungen von neuen Ideen während der Entwicklung
  • Umfangreiche Tests mit verschiedenster mobiler Hardware (Apple, HTC, Windows Mobile, Samsung)
  • Verringerung der Ladezeiten auf mobilen Geräten durch Anpassung medialer Inhalte
  • Sehr schnelle Umsetzungen möglich, da keine Frameworks oder starke Mobilanpassungen nötig sind. Allein die Auflösung bestimmt das Design der Seite
  • Verwendung neuester Möglichkeiten von HTML5 und CSS3
  • Anpassungen an verschiedenste Browser bis runter zu IE7 sind möglich und stellen kein Problem für symmetrics dar
  • Optimierung in Bereichen SEO und Usability

Für die kommenden Wochen sind neben Präsentationen und weiteren Beiträgen aus unserer neuen Abteilung rund um das Thema ebenso Schulungen sowie ein Magento Responsive Produkt geplant, welches wir in zur Verfügung stellen werden. Aktuell läuft die Schlussphase der ersten Kundenprojekte in denen das Verfahren eingesetzt wird, wir werden darüber berichten, sobald diese abgeschlossen sein werden. Stay tuned!

In Verbindung mit der Symmetrics-Magento Varnish- / ESI Lösung aus unserem Portofilio ermöglichen wir schnelle dynamische Online-Shops mit denen Sie Ihre Conversionrate und Umsatz steigern können.

Share and Enjoy

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS

Varnish-ESI Caching mit Magento

Montag, 18. Juni 2012

  1. Voraussetzungen
  2. Was ist ESI und wie funktioniert es?
  3. Wie funktioniert ein ESI-Request in Zusammenhang mit Magento?
  4. Was passiert, wenn ein ESI-Tag an den Browser gerät?
  5. Wie kann Magento einen ESI-Request erzeugen?
  6. Manuell
  7. Automatisiert
  8. Kann man die erzeugten ESI-Requests auch cachen?
  9. Welche Probleme können mit ESI auftreten?
  10. Was mache ich, wenn zu viele ESI-Anfragen entstehen?
  11. Was mache ich, wenn das Backend (Magento) nicht verfügbar ist?
  12. Wie verhindere ich das unnötige Erzeugen von Sessions?


Voraussetzungen

Um Varnish mit ESI betreiben zu können, muss man ein gewisses Grundwissen haben, wie die Konfiguration (VCL) von Varnish funktioniert. Zusätzlich sollte man Varnish 3 verwenden, da diese Version die Möglichkeit bietet eigene Module zu entwickeln. Dies sind sogenannte V-Mods. Für die lokale Entwicklung ist es ratsam sich Varnish aus den Sourcen selber zu kompilieren. Dies hat zwei große Vorteile. Erstens man kann sich mehrere Versionen parallel installieren und hält somit sein System sauber. Zweitens ist es dann auch einfacherer V-Mods zu schreiben und zu kompilieren. Dafür muss man aber eine entsprechende Umgebung haben, wie z.B. einen Mac mit installiertem XCode und den Compiler Commandline Tools. Dazu ist noch der Einsatz von Macports zu empfehlen. Dies ist aber auch problemlos mit einem Linux System, wie z.B. Ubuntu möglich. Es ist aber nicht unbedingt zu empfehlen dies unter Windows zu versuchen, da Varnish auf die POSIX system API calls verweist, welche unter Windows nicht standardmäßig verfügbar sind. Hierzu müsste man cygwin installieren.


Was ist ESI und wie funktioniert es?

ESI steht für Edge-Side-Includes, was auf Deutsch Quer-Seiten-Erfassung heißen würde. Technisch gesehen wird hier ein Bereich definiert, welcher bei dem Aufbau der Seite aus einer anderen Quelle bezogen wird. Dies ähnelt sehr den SSI (Server-Side-Includes). Die ESI-Tags sind reguläre XML Tags. Dies hat den Grund, dass diese einfacherer in ein XHTML-Dokument einzubetten sind und somit auch leichter zu verarbeiten. Zusätzlich erhöht es auch die Lesbarkeit des XHTML-Dokuments.

ESI selber wurde von Akamai spezifiziert und ist in Varnish nicht mit allen Features verfügbar. Derzeit wird von Varnish nur der include, remove und Kommentar Tag unterstützt.

Wie funktioniert ein ESI-Request in Zusammenhang mit Magento?

Um dies zu realisieren wird als erstes eine neue Route definiert. Am Besten macht man dies in einem eigenen Modul. Für die erstellte Route wird dann ein beliebiger Controller angelegt.
Beispiel:
- Route = varnish
- Controller = EsiController
- Dies würde dann folgende Route ergeben:

{BASE_URL}(/STORE_CODE)/varnish/esi/

Der Controller bietet dann eine beliebige Action, welche über einen zusätzlichen Parameter den gewünschten Block ausliefern kann. Als ESI-Tag würde das dann folgendermaßen aussehen:

<esi:include src="{BASE_URL}/varnish/esi/block/id/cart_sidebar" />

Dieser ersetzt dann den Block für die Darstellung des Carts in der rechten Sidebar. Zusätzlich ist noch zu empfehlen den esi:remove Tag zu verwenden, damit die Seite auch ohne Varnish oder deaktiviertem ESI noch lauffähig ist. Dies sähe in dem oben genannten Beispiel dann wie folgt aus:

<esi:include src="{BASE_URL}/varnish/esi/block/id/cart_sidebar" />
<esi:remove>
<div><p>This content will be removed by esi processing.</p></div>
</esi:remove>

Grundsätzlich kann man sagen, dass es zwei Möglichkeiten gibt ein ESI-Tag in Magento zu erzeugen. Dies wird im folgenden Absatz noch genauer beschreiben.

Was passiert, wenn ein ESI-Tag an den Browser gerät?

Der Browser wird die Tags ignorieren, da diese einen eigenen Namespace (esi) besitzen. Entwickler, die mit Java und Tapestry arbeiten, werden dies Verhalten bereits kennen. Dies hat zusätzlich auch als großen Vorteil, dass die Seite immer noch korrekt dargestellt werden kann, falls Varnish einmal ausfallen sollte. Hierzu muss aber dann richtig Gebrauch von dem esi:remove Tags gemacht werden.


Wie kann Magento einen ESI-Request erzeugen?

Um ein ESI-Request aus Magento heraus zu erzeugen gibt es zwei Wege.

Manuell

Dies ist für den Anfang und für erste Tests wohl der leichteste Weg. Will man aber mehrere Bereiche auf der Seite mit ESI abdecken, sollte man sich überlegen hier nicht einen Automatismus zu entwickeln. Dies senkt zu einem den Wartungsaufwand und minimiert auch die Fehleranfälligkeit.

Automatisiert

Bei einer automatisierten Lösung fängt man das Rendern der einzelnen Blöcke ab (core_block_abstract_to_html_after Event) und prüft ob dieser Block durch einen ESI-Request ersetzt werden soll. Ist dies der Fall, wird dann die Blockausgabe mit den entsprechenden esi Tags dekoriert. Dazu wird der Inhalt aus dem Block Transport Container modifiziert.


Kann man die erzeugten ESI-Requests auch cachen?

Ja es ist möglich, diese Requests auch in Varnish zu cachen. Eine Möglichkeit wäre hierfür einen zweiten Varnish zu verwenden, welcher nur für das Cachen der ESI-Anfragen zuständig ist. Hierbei muss aber beachtetet werden, dass die ESI-Anfragen für jeden Kunden individuell sind. Hier kann das Risiko bestehen, dass ein Kunde die Daten eines anderen Kunden sieht.


Welche Probleme können mit ESI auftreten?

Grundsätzlich gibt es drei Problem-Merkmale, die in Verbindung mit ESI auftreten können und zu beachten sind.

  1. Zu viele ESI-Anfragen
  2. Das Backend (Magento) ist nicht verfügbar
  3. Erzeugen ungenutzter Sessions

Was mache ich, wenn zu viele ESI-Anfragen entstehen?

Wenn zum Beispiel auf jeder Seite die rechte Sidebar inklusive aller Standardfunktionen verwendet wird, dann ist für jeden dynamischen Bereich ein ESI-Request auszulösen.
Dies wären dann folgende:

  1. Welcome Message im Header
  2. Minicart
  3. Zuletzt angesehen Produkte
  4. Vergleichsliste
  5. Umfragen
  6. Wunschliste
  7. Messages Block
  8. Global Messages Block

Dadurch werden acht Anfragen an Magento für den spezifischen Bereich durchgeführt. Dies kann unter Umständen eine höhere Gesamtlast erzeugen, als wenn man Magento ohne Varnish Cache betreiben würde. Eine Lösung die zu umgehen ist, dass man jede ESI-Anfrage für die gültige Session cached und diese dann nach Bedarf leert. Zum Beispiel wenn sich der Kunde einloggt, leert man alle Placeholder. Hierbei ist auch zu beachten, dass man die Messages Blöcke spezifisch behandelt.

Was mache ich, wenn das Backend (Magento) nicht verfügbar ist?

Hierbei ist zu empfehlen, dass, wie schon beschrieben, die ESI-Requests gecached werden. Dadurch hat man die Möglichkeit die Fehlerausgabe von Varnish zu nutzten. Dadurch merkt der Kunde vorerst nicht gleich, dass der Shop nicht funktioniert und kann weiterhin im Katalog des Shops blättern. Zusätzlich kann man sich ein Varnish V-MOD schreiben, welcher dann entsprechend des Requests bei einem Fehler eine Standardausgabe darstellt.

Wie verhindere ich das unnötige Erzeugen von Sessions?

Ein Weg dies zu verhindern ist, dass man prüft ob der Kunde bereits ein entsprechendes Session-Cookie ausliefert. Ist das nicht der Fall, muss dem Kunden eine neue Session zugewiesen werden. Dies kann man z.B. durch einen direkten Request an das Backend (Magento) veranlassen, oder indem man eine entsprechende Logik in Varnish implementiert. Wird diese Logik nicht implementiert, besteht die Gefahr, dass für jeden ESI-Request eine neue Session erzeugt wird. Hierbei ist auch zu beachten, dass die Response Header der ESI-Anfrage nicht an den Client weiter gegeben werden. Somit ist eine Session-Zuweisung über ESI nicht möglich.

Ein weiterer wichtiger Punkt bei der Session Prüfung ist, das Suchmaschinen-Bots keine Sessions annehmen oder ausliefern. Um diese korrekt zu behandeln muss eine Weiche in die VCL implementiert werden.

Share and Enjoy

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS