Deswegen behaupte ich lieber Content First, statt mobile First.

Mobile First?

Mobile First bedeutet beim Konzept einer Webseite die kleineren Auflösungen (Smartphone) mit Priorität 1 in den Vordergrund zu stellen. Im Hinblick auf responsive Webdesign ist dies ein durchaus professioneller Ansatz. “Was brauchen wir wirklich und worauf könnten wir verzichten, was ist 2.rangig und kann auf dem Desktop jedoch ausgespielt werden”. Es sind andere Grundüberlegungen notwendig und man reduziert gerne aufs Wesentliche. Hört sich gut an, oder? Wenn man aber genauer hinsieht, gibt es dabei ein paar wichtige Fragestellungen.

• Ist weniger wirklich mehr?  Es gibt unterschiedliche Zielgruppen. Ein wiederkehrender Besucher benötigt etwas andere Features wie der Neubesucher. Warum sollte ich mich mobil nicht auf dem Newsletter anmelden können oder ein Kontakformular abschicken?
• Wurde die Entscheidung dieses oder jenes Element auszusparen auch wirklich im Testverfahren berücksichtigt, vielleicht ist das Newsletterformular im Kontext zum Inhalt wichtig (Call2Action)?
• Meist wird bei diesem Konzept ein Smartphone in den Vordergrund gerückt, es gibt aber vielzählige Auflösungen dazwischen, wie sieht es mit Tablets oder horizontalen Smartphones-Displays aus?
• Der mobile User ist auch gleichzeitig Desktop User. Es kommt oft vor, dass bei Wechsel auf das kleine Device, Elemente vermisst werden.

Content First

Ein viel bedeutsamer Trend für ein Webprojekt ist der Marketingaspekt einer Content Strategie, wo es darum geht den Content zielgruppengerecht aufzubereiten. Content ist King ist bei weitem nichts neues, aber eine Content Strategie ändert viel eher die gesamte Ausrichtung eines Webkonzeptes und Screendesigns, als Mobile First. Wenn es darum geht die richtigen Inhalte dem User auszuliefern wird der übergeordnete Blick auf mobile Devices nicht mehr so wichtig, sondern ist eher ein weiterer Bestandteil von responsive Webdesign.

Der Marketingtrend Mobile First ist imho überbewertet denn meiner Meinung nach gibt es kein mobiles Web. In weiterer Folge gibt es auch kein mobiles Webdesign. Das Web besteht aus Content, egal mit welcher Bildschirmauflösung der User daherkommt. Deswegen sollten wir die Konzepter und Designer Hand in Hand mit einer Content Strategie gehen lassen und mehr mit den Redakteuren zusammenarbeiten und nicht nur mit den Technikern. Jawohl, Content First, der Rest ist dann die Umsetzung :)

Dem nicht genug verhält sich fast jede neue “Major”-Version eines Browsers anders als dessen ältere Vorgänger – Support für neue Features werden hinzugefügt oder wieder weggenommen. Um diese unglaubliche Diversität in Bahnen lenken zu können und um sicher zu gehen, dass eine Webseite auf allen oder zumindest einer Vielzahl der Browsern gut dargestellt werden kann, gibt es schon seit langem zwei verschiedene Ansätze: Feature-Detection und Browser Detection.

Browser Detection

Browser Detection bezeichnet den Vorgang, Regeln (z.b. CSS-Werte) basierend auf dem eingesetzten Browser zu schreiben. Ein Beispiel: Im IE7 ist eine Box zu breit. Im Header kann mittels Conditional-Comments ein zusätzliches CSS Skript für den den IE7 eingebunden werden, welches das Problem behebt:

<!--[if IE 7]>
CSS oder andere Angaben können hier stehen.
<![endif]-->

Der Aufwand für Browser Detection hält sich in überschaubaren Grenzen. Wird die Webseite auf dem spezifischen Browser getestet kann parallel dazu ein CSS geschrieben werden, dass die gefundenen Fehler ausbessert. Dabei wird das Haupt-CSS meist durch einfache Ausrichtungs- und Größenregeln überschrieben.

Browser Detection hat leider auch einige Nachteile. Zwar funktioniert die Webseite nach der Implementierung der Fixes auf den getesteten Browsern, die unglaubliche Vielzahl an Browsern, Geräten und Render-Engines macht einen Test auf allen gängigen und exotischen Setups aber nicht möglich und vor allem kaum bezahlbar. Weiters kann mit dieser Methode nicht gewährleistet werden, dass auch zukünftige Generationen von Browsern und Devices die Webseite wie gewünscht darstellen werden.

Feature Detection

Der zweite Ansatz, die Feature Detection, zielt auf spezifische Unterstützung (oder Nicht-Unterstützung) des jeweiligen Browsers ab. Dementsprechend ist der Ansatz auch ein anderer: Statt nur das Problem mittels einfacher Änderung von CSS Regeln zu beheben muss man bei der Feature Detection die Frage gestellt werden: Warum verhält sich der Browser wie er sich verhält? Ist dieses Verhalten auf ein spezifisches Feature zurückzuführen, welches der Browser nicht unterstützt, kann mit Feature Detection gearbeitet werden.

Ein konkretes Beispiel dafür ist z.B. das CSS Attribut box-sizing. Wird die Webseite unter Einsatz des Attributs box-sizing entwickelt kann das signifikante Auswirkungen in Browser haben, die dieses Attribut nicht unterstützen (z.B. IE7). Das Layout verrutscht und sprengt dadurch das Aussehen der Webseite. Ein Fix für den jeweiligen Browser ist zwar schnell geschrieben, andere Browser die box-sizing nicht verstehen können damit aber auch leider wenig anfangen. Hier kommt die Feature Detection ins Spiel. Anstatt einen Browser anzuvisieren kann mittels verschiedener Methoden (z.B. über Modernizr) die generelle Fähigkeit des Browsers abgefragt werden, bestimmte Attribute zu verstehen. Für alle Browser die dies nicht tun, kann damit eine globale Ausnahmeregelung gefunden werden.

//Beispielhaftes CSS
html.no-boxsizing .elementA {
  Angaben für Browser ohne Box-Sizing
}

.elementA {
   Generelle CSS-Attribute
}

Diese Herangehensweise hat wie beschrieben einige Vorteile: Zukünftige und exotische Browser die durch Tests nicht abgedeckt werden können, werden ebenfalls erfasst und zeigen die Webseite richtig bzw. wie gewünscht an.

Natürlich ist diese Methode nicht immer anwendbar. Darstellungsunterschiede oder sonstige Fehler müssen auf spezifische CSS-Regeln rückführbar sein. Handelt es sich um einen simplen Bug bzw. einer Abweichung vom Standard ohne erkennbaren Grund muss auf die gewohnte Browser Detection zurückgegriffen werden.

Browser vs. Feature Detection

Welche der beiden Methoden besser ist, kommt natürlich immer auf den Fall an. Generell sollte man natürlich den Feature Detection Approach bevorzugen  wo er anwendbar ist, weil dadurch generell größere Kompatibilität mit Browsern gesichert werden kann. Bei vielen Problemen kommt man um den Einsatz von Browser Detection aber sowieso nicht herum.

Eine generelle Regel gibt es dabei zu beachten: Da das Web so unglaublich vielseitig ist und von jedem Menschen anders aufgerufen wird, sollte man nicht (und braucht auch nicht) versuchen, Webseiten in ein Korsett zu stecken. Pixelgleiches Rendering über alle Systeme, Devices und Engines ist und bleibt unmöglich (und oft auch nicht wünschenswert).

Browser-Check

Um Darstellungs- und anderen Fehlern besser auf die Spur zu kommen, haben wir für unsere neue Webseite ein Tool entwickelt, das Statistiken über den eigenen Browser sowie die darin unterstützten Features bereitstellt und im Bedarfsfall an uns übermittelt. Der Browser-Check ist über www.liechtenecker.at/browsercheck erreichbar.

Die Kombination von einer Online-Aktion und einer Offline-Reaktion ist nicht ganz neu, aber bei weitem noch nicht oder vielleicht auch einfach nicht mehr ein alltäglicher Bestandteil im Portfolio von digitalen Kampagnen.

Wir haben uns nach weiteren Beispielen dafür umgesehen und sind auf ein paar tolle, wenn auch leider nicht ganz neue Beispiele gestoßen.

Für Ariel wurde am Hauptbahnhof in Stockholm schon 2011 ein Roboter entwickelt, der die High End Designer Klamotten auf Anweisung der Facebook Community in Skandinavien beschmutzte. Schwierige Flecken, wie z.B. Marmelade oder Schokolade wurden erst auf die Shirts geschossen, diese wurden anschließend mit Ariel gereinigt und per Post an die ausgelosten Gewinner geschickt:

Auch Vodafone lies bereits 2010 in Australien eine Online-Acton-Offline-Reaktion Maschine entwickeln – mit der man mittels Facebook App eine riesige Pinata zerstören sollte. War die Pinata endlich geknackt, gab es jede Menge Preise zu gewinnen und somit einen großen Anreiz, an der Sache dranzubleiben.

Im Behind the Scenes Video wird der Roboter und die Technik dahinter noch etwas detaillierter erklärt:

Auch das Twerrible Towel der Steelers für die Super Bowl 2011 fanden und finden wir genial. Über den Hashtag #Steelersnation wurde das Handtuch von einer Roboter-Hand geschwungen. Ziel war es, bis zum Superbowl durchgehend das Handtuch in Bewegung zu halten.

Apropos: Durch diese Idee entstand dann auch unser Cheer Em Up  - eine App bei der sich die Football-Helme zwar nicht offline aber online vorwärts bewegen und in der die lautesten Fans das Spiel für ihre Mannschaft gewinnen konnten.

Und dann gab es natürlich noch die per Like zu weinen beginnende Marienstatue oder Nike’s Chalkbot, der auf den Straßen der Tour de France das Thema Krebs Bewusstsein in den Vordergrund rückte.

Wirklich neue Beispiele sind uns bei unserer Recherche aber nicht aufgefallen, vom Blaulicht Büro, dass uns das Thema wieder entdecken lies, einmal abgesehen.

Kennt ihr neue, aktuelle Beispiele von solchen Robotern oder ähnlichen Installationen?

ExpressionEngine unter die Lupe genommen

Im folgenden soll euch ein kurzer Einblick in unsere persönlichen Erfahrungen mit EE gegeben werden – natürlich werde ich hier nicht einmal ansatzweise auf alle Features eingehen können – trotzdem seid ihr dann vielleicht motiviert euch das System mal anszusehen.

Die wichtigsten Vor- und Nachteile

Nun aber zu den harten Fakten und warum ExpressionEngine toll bzw warum es teilweise auch ziemlich zum Heulen ist:

Ein ganz großer Vorteil von EE ist die Möglichkeit sich seine Content Typen selbst zusammen zu stellen. Rezepte benötigen beispielsweise andere Felder als Events. Mit den eigenen Typen (Channels genannt) kann der Autor also einen Eintrag des Typs Rezept erstellen und hat in der Eingabemaske im Backend die passenden Felder dazu (Zutaten, Mengenangaben, Beschreibung, Galerie etc) – wenn er nun ein Event erstellen möchte muss er hierzu ganz andere Felder ausfüllen (Locations, Start- Enddatum, Beschreibung, etc). Im Allgemeinen ist es für Autoren durch wenige Klicks ganz einfach Einträge zu publizieren oder zu editieren. Auch ist es super, dass man sich im System relativ schnell zurecht findet und das ganze somit viel mehr Spaß macht. Es ist sicherlich genauso übersichtlich und fancy wie WordPress. Einige der negativen Punkte lassen sich darauf zurückführen, dass die EE Community eigentlich vergleichsweise klein ist. Was unter anderem auch dazu führt, dass einige AddOns keine vergleichbare Konkurrenz haben und somit unverschämt teuer sein können und/oder programmiertechnisch nicht gerade das gelbe vom Ei sind.

Templating

Da EE auf dem PHP Framework CodeIgniter basiert hat man den Vorteil, dass es relativ einfach und bequem ist sich eigene AddOns zu programmieren. Beim Templating hingegen sieht es nicht so einfach aus. EllisLab wirbt zwar damit, dass das Templating super einfach ist und auch gar keine Programmierkentnisse erfordert, aber so einfach ist es dann doch nicht. Eigentlich ist es manchmal so richtig zum aus der Haut fahren, was unter anderem an der komplizierten Template Parsing Reihenfolge liegt (Cheat Sheet) Außerdem muss bei großen Seiten aufgrund etwaiger Performance Probleme sehr auf das Templating geachtet werden.

Fazit

ExpressionEngine ist im Grunde ein tolles System (als gute Alternative zu Typo3) zu empfehlen. Es ist wie gemacht für große Webprojekte mit besonderen Anforderungen. Die Bedienung des Backends ist recht intuitiv und schnell zu erlernen. Auch für Developer stehen dank CodeIgniter viele Türen offen. Leider ist die Community recht klein und das Templating System kann einen so richtig den letzten Nerv kosten. Natürlich gibt es nicht DIE perfekte CMS Lösung, denn kein System kann von vornherein alle Funktionaliäten bieten die eine Webseite vielleicht benötigen könnte. ExpressionEngine bietet auf jedenfall schon mal eine gute Basis und den Rest muss man sich einfach selber zaubern.

Für ein paar Auserwählte wurden vor kurzem Brillen zum Testen verteilt. (Wie gerne hätte ich auch schon eine:) Diese Personen haben über die Video- und Fotomöglichkeiten berichtet. Heute sind erstmals passende Twitterbilder, die direkt mit der Brille gemacht wurden, aufgetaucht:

Damit erschliessen sich die wichtigsten Haupteinsatzgebiete von Google Glass, Fotos und Videos. Mit einer hochauflösenden Kamera ausgestattet (5 Megapixel für Bilder und 720p für HD Videos) lässt sich das ganz gut bewerkstelligen. Derzeit ist die Brille natürlich nur mit Android Endgeräten kompatibel, angeblich soll sich das bei weiter Verbreitung noch ändern.

Auf engadget ist vor ein paar Tagen ein lesenswerter Alltagsbericht von einem Tag mit Google Glass aufgetaucht.

Anfang 2014 soll die Brille am Markt erhältlich sein, bin gespannt was sie kosten wird. Es gibt ja Gerüchte, dass sie mit Werbeeinblendungen gratis sein könnte?

Erstellung eines responsive Newsletter Designs für LG Partner Net, angepasst an das Corporate Design von LG. Der Newsletter besteht aus einem modernen und flachen UI Design mit Icons und Call to Action, um den Newsletter ansprechender zu machen und längerfristig mehr Open Rates zu generieren.

Die Umsetzung

Für den Newsletter wurde ein HTML Template erstellt, welches für alle gängigen Mailprogramme getestet wurde. Das Design ist an den Metro Style angelehnt und lebt von Flat UI Elementen. Besonders viel Wert wurde auf die Kompatibilität mit Microsoft Outlook gelegt, da es eine vergleichsweise hohe Nutzungsrate hat, aber besondere Hürden in der Entwicklung mit sich bringt.

Der Newsletter passt sich jeder Größe optimal an und sichert so eine ausgezeichnete Lesbarkeit, auch für mobile Endgeräte. Der Newsletter bietet für jede Bildschirmauflösung ein gelungenes Leseerlebnis. Über die Erkenntnisse aus der Konzeption und Erstellung gibt es auch einen Artikel auf unseren Blog.

Sehr selten, aber doch manchmal, kommt es vor, dass ich von einem Newsletter begeistert bin: Zum Beispiel wenn das Design sich an meine Bildschirmgröße anpasst und so aufbereitet ist, dass ich gespannt weiterlesen will. Der Smashing Newsletter ist eines dieser positiven Beispiele. Er ist simpel aufgebaut und gegliedert mit Ankerlinks, Überschriften und Listenelementen. Das ganze ist einfach zu lesen und einspaltig in einer Tabelle aufbereitet – so wie es Standardmäßig für einen HTML Newsletter empfohlen wird.

Responsive Newsletter

Was aber wenn man ein etwas aufwendigeres mehrspaltiges Layout in einem Newsletter transportieren will & diesen trotzdem in jeder Auflösung darstellen will? Kein Problem, es gibt nur ein paar Dinge die man dabei beachten sollte. Man sollte auf alle Fälle trotzdem immer Bei HTML tables bleiben, da teilweise <div>,< p>, sowie margins und paddings in den verschiedensten Mail-Programmen nicht unterstützt werden. Vollkommen verzichten sollten man auf floats für Elemente. Außerdem sollte man sich für ein Layout entscheiden: Eine Liste mit Produkten sollte zum Beispiel immer gleich dargestellt werden – 1 Zeile mit 2 Zellen. Die erste Zelle für das Produktfoto und die zweite Zelle immer für die Produktbeschreibung. Das macht die Darstellung am mobilen Endgerät danach leichter – dort wird die Tabelle dann nämlich nur mehr 1-spaltig angezeigt & so zuerst das Produktfoto und darunter die Beschreibung – gefolgt vom nächsten Produktfoto und so weiter.

Ein wechselndes Layout ist auch möglich, aber nur wenn man das Bild nicht unbedingt mit dem Beitrag verknüpfen muss und auch vom Bild zu mehr Informationen kommt.

Media Query

Um eine Tabelle von einer 2-spaltigen Ansicht in eine 1-spaltige Ansicht zu bekommen, muss man eigentlich nur eine Kleinigkeit ändern, alle Zellen in einer Zeile müssen zu einem Block Element gemacht werden. Das wars, alle Zellen werden so untereinander dargestellt und können dann individuell angepasst werden.

 @media only screen and (max-width: 500px) {

table.content td { display:block;}

}

Support

Fast jedes Mail Programm unterstützt diesen einfachen Aufbau und die Mediaqueries. Werden Mediaqueries nicht unterstützt, wird einfach die 2-spaltige Version angezeigt, was auch kein Problem sein sollte. Alle aktuellen Android und iOS Phones unterstützen Media Queries. Klingt alles fast zu schön um war zu sein – so ist es auch, natürlich gibt es ,wie immer, einen Haken & diesmal hat es nicht, wie vermutet, mit dem Internet Explorer zu tun. Als ich das erste mal über das nachfolgende Problem stolperte, wünschte ich mir zum ersten mal den Internet Explorer zurück. Testet man seine E-Mail Templates vor dem Versand in allen Programmen (Campaignmonitor bietet einen sehr umfangreichen Test um nur 5$) so stellt man fest das der Newsletter in Outlook bis 2003 perfekt angezeigt wird, aber ab Outlook 2007 gehörige Probleme macht. Der Grund? Bis Outlook 2003 wird der Newsletter im Internet Explorer gerendert, aber ab der Version 2007 wird er über Microsoft Word gerendert. Damit wird das Problem offensichtlich, Microsoft Word unterstützt unzählige HTML und CSS Attribute nicht, wie zum Beispiel:

• background, background-image, background-position
• margin: margin-top, margin-bottom
• padding für <p> und <div> Tags
• width für inline Elemente, <div>,< p>
• list-style-type, list-style-position, list-style-image

Hier eine Übersicht der unterstützten/nicht unterstützten Attribute.

Bevor man ein HTML Template erstellt sollte man also ganz genau bedenken welche Elemente und Attribute man verwendet, da der Anteil an Outlook Usern laut einer Statistik (September 2012) bei 20% liegt und mehr als die Hälfte davon arbeiten mit einem Outlook der Version 2007 oder neuer. Mit Windows 8 kommt auch die neue Outlook Version 2013 auf den Markt, und obwohl das ganze System sehr modern und innovativ ist, wird für Outlook weiterhin Word als Rendering Engine verwendet – zum Leid der Newsletter Templates.

VML Hack

Natürlich gibt es aber schon einige Workarounds mit denen man die Tücken des Outlook -Renderings umgehen kann. So gibt es beispielsweise die Möglichkeit Hintergrundbilder mittels eins VML (Vector Markup Language) Hacks anzuzeigen:

<!--[if gte mso 9]>
       <v:rect style="width:400px;height:287px;" strokecolor="none">
          <v:fill type="tile" color="#DDDDDD" src="https://i8.createsend1.com/ti/r/73/0F1/E56/012449/images_css/images/news3_bg.png" /></v:fill>
       </v:rect>
    <![endif]-->

Zu aufwändig sich die ganze VML Einführung von Microsoft durchzulesen? Good News – Es gibt endlich einen Generator für den Hack.

Alles beachtet? Dann steht einem fancy mehrspaltigen responsive Newsletter ja wohl nichts mehr im Wege!

Mittlerweile zähle ich den 5. Relaunch seit Bestehen der Domain und bin wie immer ganz stolz auf unseren neuen Webauftritt. Gemeinsam im Team haben wir in den letzten Wochen daran gearbeitet. Jeder hat bei unserem Relaunch seine Talente eingebracht.

Das Ziel war ein sehr aufgeräumtes und modernes Interface, wo wir unsere Stärken ausspielen können. Speziell auf tadellose Webtypografie, Animationen und hohe User Experience haben wir gesetzt. Waren wir mit unserem vorigen Webauftritt bereits Pioniere im responsive Webdesign, haben wir das flüssige Konzept ausgebaut und spezialisiert, dazu meint Stephan:

Bei der Umsetzung wurde darauf geachtet, dass nicht für bestimmte Devices optimiert wurde, sondern Breakpoints an den für die Elemente passenden Stellen (dort wo es Contentmäßig auch wirklich Sinn macht) erstellt wurden. Dadurch ist gesichert, dass die Seite nicht nur auf gängige & populäre Devices sondern auf alle Devices optimiert ist.

Wir sprechen hier von einem Fortschritt von unserem responsive Ansatz mit Media Queries. Die Technik ist hier grundsätzlich die selbe, aber wir achten hier nicht nur auf populäre Deviceauflösungen, sondern brechen dort auf ein neues Design um, wo es auch für den Gesamtkontext besser Sinn macht.

Technische Aspekte und UX

Bekannt sind wir auch für unsere subtile User Experience durch Animationen, welche komplett mit HTML5 und CSS3 realisiert sind. Die Animationen auf der Startseite wurden mit Tumult Hype umgesetzt und funktionieren auf allen von uns unterstützten Browsern (IE7 +, …). Diese Animationen benutzen das Format SVG mit einem Fallback auf PNG. Da Hype dies nicht Standardmäßig unterstützt, wurde ein Custom-Loader für die Hype-Animationen erstellt.

Dass SVG die Zukunft von Grafiken auf Webseiten ist, haben wir zuvor schon erwähnt. Deswegen  war es eine frühe und wichtige Entscheidung, alle Elemente, Grafiken & Icons nach Möglichkeit mit SVGs umzusetzen und nur für ältere Browser einen Fallback auf PNG zu implementieren. Dadurch sind alle grafischen Elemente auf der Seite auch auf hochauflösenden Displays (Stichwort: Retina) exakt und besonders scharf.

Alle Webseiten wurden mit Fokus auf moderne Browser entwickelt, jedoch ohne ältere Browser aussen vor zu lassen. Es gibt z.B. keine IE7, IE8 oder sonstigen, browser-spezifische CSS Files. Das funktioniert über Feature Detection im Browser. Für jedes CSS-Feature (SVG, Opacity ,…), welches auf älteren Browsern nicht supported wird, gibt es alternative CSS-Regeln, die eine ähnliche bzw. gleichwertige Implementation auch auf diesen Browsern sicherstellt.

Das Konzept

Unser Hauptaugenmerk beim neuen Konzept war bessere Lesbarkeit (gegenüber der Vorversion) der Contenttexte, da unser Blog ein wesentlicher Bestandteil unserer Webseiten ist. Hierbei haben wir mit unserer Typografieexpertin Lisa ein passendes Fontskonzept entwickelt.

Als Webfont haben wir unsere CI Schrift Neo Sans verwendet, die eine sehr ausgeprägte Persönlichkeit hat und dazu die Open Sans (sans-serife Schrift) in verschiednen Schnitten, die zwei Schnitte harmonisieren sehr gut miteinander! Open Sans ist eine sehr leserliche und moderne Schrift fürs Web. Punkto Lesbarkeit wurde versucht nicht mehr als 45-70 Zeichen in einer Zeile anzuzeigen und je nachdem die Zeilenhöhe anzupassen. Auch die Überschriften stehen proportional zu dem Fließtext. Um das ganze zu Testen wurde zu Beginn ein Typography Prototyp erstellt.

Genug ist mehr

Wir wollten bei unserem Relaunch mit gezielter Call2Action den User dazu einladen interaktiv zu werden. Ob es jetzt ein Quick Check der digitalen Strategie ist, unser Newsletter oder spezielle Anfragen. Zum Beispiel Buttons mit einem sehr subtilen 1.5 Sekunden Fade unterstüzten den Webseitenbesucher dabei.

Getreu unserem Motto “GENUG IST MEHR” (nicht weniger ist mehr) haben wir alles auf unsere wichtigen Kernaussagen reduziert.

Unser CMS ist nach wie vor WordPress, in der neuesten Version (der neue Medien-Uploader ist sexy:) Sarah, unsere Developerin im Relaunch Team, hat sich bei der Programmierung der Designs auf ein kleines Helferlein gestützt:

Für das Erstellen des Themes habe ich  http://underscores.me/ verwendet. Das ist ein ganz simples designfreies HTML5 Template mit allen elementaren Files, dass man dementsprechend erweitert. So kann man auch zum Beispiel auf eine 404 Seite nicht vergessen ;)

Fazit

Ich freu mich sehr wieder einen Schritt in Richtung Liechteneckers Zukunft getan zu haben, schließlich sind wir mit unserer Agentur richtig erwachsen geworden und haben ein perfektes, hochprofessionelles Team beieinander, für Ihre digitale Strategie :)

Mit einem neuen Webkonzept, das gezielt auf Motion Experience und Plattformunabhängigkeit dank Responsive Webdesign setzt sowie starker Call to Action, um online Leads zu generieren, zeigt Liechtenecker wie ein moderner Webauftritt für ein innovatives Unternehmen aussehen kann.

Die Umsetzung

Subtile Animationen und Effekte beim Scrollen über die Seite mit HTML5 und CSS3 erhöhen die User Experience auf ionit.at. Die Inhalte sind zudem im Infografik-Stil aufbereitet, sodass die Informationen auf einen Blick leichter erfasst werden können und die Vorteile des Produkts für die Gesundheit der Anwender bestmöglich aufgezeigt.

Frei nach dem Motto: Many Interfaces, one Brand wurde für die gesamte Seite das Prinzip des Responsive Webdesigns eingesetzt. Sie wurde also auflösungsunabhängig konzipiert, wodurch sich das Design den unterschiedlichen Endgeräten – seien es Smartphones, Tablets oder HD Bildschirme – fließend anpasst, ohne dabei das Look & Feel der Seite zu verlieren.

Scalable Vector Graphics (SVG) ist ein auf XML basierte und vom W3C empfohlene Spezifikation, um zweidimensionale Vektorgrafiken im World Wide Web darzustellen.

Vektorgrafiken sind, vereinfacht ausgedrückt, Beschreibungen von zweidimensionalen Objekten wie Kreisen, Rechtecken und Pfaden. Ein Dreieck kann z.B. über die Koordinaten der drei Eckpunkte definiert werden. Bei den stärker verbreiterteren Rastergrafiken (z.B. Fotos, Bilder) werden je nach Auflösung Bildpunkte (Pixel) gespeichert.

Der Große Vorteil von Vektorgrafiken gegenüber Rastergrafiken wird mit folgender Grafik deutlich:

Werden Rastergrafiken über ihre eigentliche Auflösung vergrößert, müssen Zwischenpunkte für neue Pixel berechnet werden. Dieses Verfahren nennt man Interpolation. Je nach Interpolationsmethode ergeben sich entweder große Pixel mit harten Kanten, oder das Bild wird matschig und unscharf. Ganz im Gegenteil zur Vektorgrafik: Sie wird je nach benötigter Größe berechnet und kann daher ohne weiteres vergrößert werden.

Wann benötigt man SVG?

Hätte jemand diese Frage vor mehr als zwei Jahren gestellt, hätte die Antwort wahrscheinlich ‘kaum bis gar nicht’ gelautet. Bis zu diesem Zeitpunkt hatten Webseiten und alle Elemente darin fixe Größen und damit Auflösungen. Und weil nahezu alle Bildschirme die selbe Pixeldichte hatten, konnte man auch getrost davon ausgehen, dass die eigene Webseite auf 99,99% aller verfügbaren Bildschirme qualitativ hochwertig und scharf angezeigt wurde.

Seit dem sich Responsive Webdesign etabliert hat, werden jedoch ganz neue Anforderungen an Webseiten und deren Inhalte gestellt: Alle Objekte müssen sich flüssig an Bildschirmgrößen vom kleinsten Smartphone bis zum größten Widescreen-Monitor anpassen. Elemente auf der Seite müssen problemlos schrumpfen aber auch größer werden können.

Neben verschiedenen Größen von Displays haben sich in den letzten Jahren vor allem bei mobilen Devices hochauflösende Displays verbreitet. Das stellt noch größere Anforderungen an die Assets einer Seite. Grafiken, die auf einem handelsüblichen Computer-Monitor scharf aussehen, sehen auf hochauflösenden Smartphone- und Tabletdisplays matschig und unscharf aus.

Unter diesen Bedingungen kann SVG glänzen.

Die Herausforderungen von SVG

Alle Vorteile kommen natürlich mit einem gewissen Preis. Wer Grafiken in Zukunft in SVG statt in GIF/PNG/JPG auf seiner Webseite einbinden will, muss einiges beachten:
Alle grafischen Elemente (z.B. Icons, Pfeile usw.) müssen als Vektoren vorliegen. Auch der Workflow des Exports kann sich je nach eingesetzter Software verkomplizieren – Adobe Photoshop unterstützt das Speichern in SVG z.B. nicht.
Daneben ist natürlich auch zu beachten, dass möglichst alle Assets auch wirklich als Vektoren vorliegen. Hat der Kunde das eigene Logo nicht in einem Vektorformat zur Verfügung, können zwar die restlichen Assets als Vektoren gespeichert werden, dennoch bleibt das schlechte Gefühl, ein zentrales Element der Webseite nicht auflösungsunabhängig implementieren zu können.

Die Nachteile von SVG

Wie immer gibt es kleinere Schattenseiten. Neben den nötigen Adaptierungen des Workflows im Bereich Design muss natürlich auch einiges beim Development beachtet werden.
Gewohnte Workflows mit automatischer Image-Sprite erzeugung (durch z.B. SASS + Compass) funktionieren mit SVGs (noch) nicht.

Neben der Einbindung die größte Herausforderung ist aber natürlich wie immer der Browsersupport. Generell wird SVG in vielen Browsern unterstützt, Probleme machen nur der Internet Explorer 8 und darunter sowie Android 2.3 und darunter. Daher kommt man nicht herum, für diese Browser alternative PNG-Versionen der Bilder zur Verfügung zu stellen.

Weitere Vorteile von SVG
Neben generellen Vorteilen von Vektorgrafiken gegenüber Rastergrafiken hat SVG noch einige besonders nette Features zu bieten.
So kann SVG z.B. inline in CSS eingebunden werden:

 .class {
     background-image: url(“data:image/svg+xml;utf8, ... ”);
 }

Das macht zwar die .css-Datei größer, spart bei vielen einzelnen Datein aber auch enorm viele HTTP-Requests.

Auch Animationen einzelner Objekte im SVG ist möglich. So kann bei einer SVG-Grafik, die z.b. einen Kreis und ein Rechteck beeinhaltet, der Kreis unabhängig vom Rechteck bewegt werden.

Das Fazit

SVG ist keine neue Technologie und wurde bereits 2001 vom W3C standardisiert. Gerade in den letzten Jahren hat sich allerdings gezeigt, wie wichtig SVG für die Zukunft von Webseiten sein wird. Über kurz oder lang werden alle Displays unterschiedlichste Pixeldichten aufweisen und die Anforderung, dass Grafiken auf allen Webseiten perfekt aussehen, wird ganz normal sein.

Mit zunehmender Popularität wird sich mit Sicherheit auch viel aktive Entwicklung auf SVG konzentrieren, was vor allem die bisher von Rastergrafik bekannten Workflows auf SVG ausweitet.

Eines ist sicher: Der Vektorgrafik gehört die Zukunft.