Responsive Webdesign, Teil 1: Layout- und Textdarstellung
Flexibles Webdesign auf verschiedenen Geräten.
Responsive Webdesign – Einführung
Die Entwicklung von Webprojekten hat bekanntermaßen ihre Tücken – besonders, wenn eine Website auch auf mobilen Geräten wie Smartphones oder Tablets dargestellt werden soll. Es gibt dazu verschiedene Ansätze wie „Mobile First“, „Adaptive Layout“ oder „Fluid Layouts“. Aus technischer Sicht kann hier zwischen JavaScript- und CSS-Lösungen unterschieden werden. CSS-Lösungen werden mit sogenannten Media-Queries umgesetzt, die sogenannte Breakpoints nutzen, um das Layout entsprechend einer Veränderung des Viewports anzupassen. Im Gegenzug dazu manipulieren JavaScript-Skripte vorwiegend das DOM selbst.
Frameworks
Die eingesetzten Technologien haben natürlich Vor- und Nachteile – Stichwort „kein JavaScript aktiviert“ beziehungsweise CSS-Macken in diversen Browsern. UI-Frameworks wie zum Beispiel Bootstrap oder Zurb Foundation unterstützen euch bei der mobilen Entwicklung und bieten Lösungen für die oben genannten Probleme. Besonders praktisch sind hier CSS-Klassen, die euch bestimmte DOM-Objekte auf gewissen Geräten automatisch ausblenden. Doch sollte so ein UI-Framework einen unnötigen Overhead darstellen oder ihr etwas abseits des Mainstreams suchen, gibt es noch andere Systeme, die euch nur die Basis, also die Funktionalität eines Rasters, zur Verfügung stellen.
Folgende Systeme sind absolut einen Blick wert:
- Skeleton
- Less Framework
- Responsive Grid System
- Gumby
- Base
- Semantic Grid System
- Responsive Grid System
- Frameless
- YAML
- Profoundgrid
Abseits des Mainstreams
Ein Beispiel wäre das von Joni Korpi entwickelte Golden-Grid-System. Es orientiert sich an Unigrid und besteht aus 18 Spalten. Die zwei äußersten Spalten dienen als Whitespace, womit 16 Spalten bleiben, die im Design effektiv genutzt werden können. Die Besonderheit: Das GGS ist proportional zum Viewport und die Breite der einzelnen Spalten verhält sich proportional zur Schriftgröße der Website. Dadurch wird ein „Zusammenquetschen“ beziehungsweise ein „Zerreißen“ des Textes bei einer Skalierung verhindert.
Isotope
Ihr wollt ein ähnliches Layout wie das von Pinterest umsetzen? David DeSandro hat mit Masonry.js die Grundlage geschaffen. Wenn ihr aber Masonry „on Roids“ – also mit einer Filter- und Sortierfunktion – haben wollt, ist Isotope genau das Richtige für euch!
Waterfall
Eine sehr schnelle und kleine Library mit ähnlichem Funktionsumfang wie Isotope und Masonry oder andere „Fluid-Column“-Skripte.
Responsive Darstellung von Text
Um die Ansprüche des Designs mit Funktionalität verbinden zu können, ist man als Entwickler oft mit herausfordernden Problemen konfrontiert. Eines davon: einen Text, der auch auf kleinen Auflösungen eine angemessene Anzahl an Zeichen pro Zeile haben sollte, in verschiedenen Auflösungen gut aussehen zu lassen. Wer kein Fan von Breakpoints ist oder dieses Problem automatisiert lösen lasen will, dem kann ich folgende Skripte ans Herz legen:
Fittext.js
Dieses Skript skaliert Textblöcke relativ zur Größe des Viewports. Trotz des Hinweises auf der Website funktioniert dieses Skript auch hervorragend für kurze Fließtexte – zumindest bis zu Tablet-Auflösungen.
TextFit.js
Samuel Reed hat mit TextFit ein jQuery-freies Plugin entwickelt, das sich – zumindest laut eigenen Angaben – durch eine hohe Geschwindigkeit auszeichnet. Auch dieses Plugin ermöglicht ein automatisches Skalieren von Texten.
Readmore.js
Das Vier-Kilobyte-Leichtgewicht Readmore kürzt eure Texte bei Bedarf und fügt einen „Read-more“-Link hinzu. Besonders praktisch für Blogs, die übersichtlich bleiben, aber auf eine Textvorschau nicht verzichten wollen.
FlowType
Mein Favorit ist FlowType. Neben der Anpassung von Textgrößen wird auch die Zeilenhöhe angepasst und somit der Lesefluss verbessert. Außerdem gibt es eine wirklich hübsche Demo.
Welche Skripte vermisst ihr? Habt ihr selbst Lösungen entwickelt? Lasst es uns wissen und schreibt einen Kommentar!
Die URL zu „Waterfall“ ist wohl kaputt gegangen.
Richtig wäre: https://github.com/dfcreative/jquery.waterfall
Schöner Artikel. Der Link bei Waterfall funktioniert allerdings nicht richtig.
Das ist ja erst Teil1. Vielleicht schreibt ihr in einem weiterem Teil auch mal was über Navigationsmenüs. Ein Problem ist da zum Beispiel das fehlen bzw. die Sinnlosigkeit der :hover-Pseudoklasse auf Touch-Geräten, die man am Desktop jedoch gut für Dropdownmenüs nutzen kann.
Mir gefällt da das Prinzip von MeanMenu noch am besten. Da hat mich nur was an der technischen Umsetzung gestört, aber das nachprogrammieren war auch recht simpel.
YAML ist schon ganz ok, die anderen kenne ich nicht oder nur sehr oberflächlich.
Oft kommt es aber vor, dass der Kunde sehr genaue Vorstellungen vom Layout hat, so dass ein responsive Design nicht immer einfach umzusetzen ist.
Ein separates Mobile Template ist zwar prinzipiell Mehraufwand, lohnt sich aber oft trotzdem.
waterfall link sitzt jetzt, danke für den Hinweis
Danke für den Hinweis wegen waterfall!
@Jupp
Du sprichst mir aus der Seele! Die Hoverproblematik geht auch mir auf den Senkel. Der nächste Teil wird von Navigationen handeln. MeanMenu ist mir bekannt, was hat dich an der Umsetzung gestört? Etwas allgemeines oder war es projektbezogen?
@Content Web Solutions
Responsive Design lässt sich meiner Meinung nicht einfach „so“ umsetzen, auch hier muss es eine Planung geben – aber Kunden sind manchmal auch sehr „beratungsresistent“ ;)
Bei dem ein oder anderen Framework/Script werde ich mal eine Review machen – aber einen Blick sind alle wert!
Die Artikelreihe finde ich gut.
Das oben genannte Framework „Skeleton“ ist allerdings nur für adaptive Seiten gedacht. Sollte auch keine Kritik an dem Beitrag sein, nur reagieren die Seiten dann anders, als sie es responsive tun würden.
was richtig kool wäre, ist ein Plugin Akkordeon zu tabs und umgekehrt. da sie Kunden häufig Tabs auf dem Desktop view haben wollen und das selbe Element dann ein Akkordeon auf einem smartphone werden soll. ansonsten toller Beitrag!
@little
Ich denke ich habe gerade deinen Tag versüßt:
https://github.com/samsono/Easy-Responsive-Tabs-to-Accordion
Sicherlich ein guter Artikel, wenn man nach einem Werkzeug sucht, dass einem beim Geplanten unterstützt. Irgendwie hätte ich bloß beim ersten Teil so einer Serie weniger eine Anregung zum „Womit“ erwartet, sondern erst einmal eine Einführung in das „Wieso“. Wieso sollte ich bestimmte Dinge grundsätzlich so und so designen? Von welchen Denkansätzen sollte ich ausgehen und welche Stolperschwellen berücksichtigen? Danach wäre ich auf das „Wie“ eingegangen und das dann vielleicht im Vorlauf oder in Verbindung mit dem „Womit“. Das Problem an diesen ganzen Libraries und Frameworks ist doch, dass sie völlig inflationär eingesetzt werden und auch viel zu häufig von Mitmenschen die gar nicht richtig verstehen was diese Werkzeuge eigentlich so wirklich tun. Und zack hat man eine völlig aufgeblähte Website oder App, einfach nur, weil der Produzent denkt, dass dieses und jenes Tool ja ganz toll sei und auf keinen Fall fehlen darf, obwohl es für dieses Projekt gar nicht notwendig gewesen wäre. Da sind Artikel wie dieser, wo dann nur stumpf gesagt wird „wenn du das und das erreichen willst, dann nimm Tool xy“, ohne die Feinheiten drum herum zu erklären, nicht sonderlich förderlich. Christian Heilmann hat dazu letztens einen guten Artikel in seinem Blog verfasst:
http://christianheilmann.com/2013/10/01/lets-explain-the-why-instead-of-the-how/
@Benjamin_Wagener
Erstmal Danke für dein Kommentar. Ich bin davon ausgegangen, dass man als seriöser Webentwickler solche Basics, wie von dir Angesprochen, wissen müßte. Folglich auch warum man X oder Y einsetzt und nicht blind Scripts/Plugins oder was auch immer „zusammenkopiert“. Deinen Frust kann ich irgendwie verstehen und teilweise auch nachvollziehen, ich kenne aber deinen Background nicht.
Das hier soll wirklich nur eine Toolsammlung werden, also ein Nachschlagewerk um schnell an gute Tools zu kommen ohne vorher 10 andere ausprobieren zu müssen um dann festzustellen, dass diese dann doch nicht so funktionieren wie beschrieben. Denn gerade in Kundenprojekten hat man oft nicht die Zeit selbst eine Funktionalität zu entwickeln und in weiterer Folge zu testen.
Wenn man aber die Feinheiten verstehen will kann man auch die Dokumentationen zu Frameworks/Skripten etc. lesen.
@Mario Janschitz: Ein seriöser Webentwickler tut so etwas hoffentlich, ja. Hier lesen aber eben nicht nur erfahrene Webentwickler. Hier lesen auch Anfänger die durch Google her gekommen sind oder weil sie auf die t3n zufälliger Weise im Zeitschriftenhandel gestoßen sind. Genauso lesen hier auch Leute, welche sich vor allem mit eCommerce und dem Betrieb rund um den technischen Teil einer Online-Plattform beschäftigen. Die lesen nur „ach du willst ein Design wie Pinterest, dann nimm doch Tool xy und es geht ganz einfach“. Da wäre ein Disclaimer nach dem Motto „Bevor man die hier besprochenen Tools einsetzt, sollte man immer erst die Grundlagen dazu verstehen.“ und dann auf WebPlatform.org oder dergleichen verweisen. Sonst kommt es halt doch dazu, dass ein Anfänger mal eben stumpf eine Bibliothek anwendet oder irgendein Geschäftsführer auf die Idee kommt seinen Webentwickler anzuweisen mal eben dieses oder jenes zu machen, weil es ja so einfach ist…
@Benjamin_Wagener
Du hast völlig recht, bevor man in Unkenntnis der Sachlage Werkzeug einsetzt dass man nicht versteht oder gar nicht korrekt handhaben kann, sollte man sich Grundlagen-Wissen aneignen.
+1 dafür.
Nur kann ein Artikel nicht jedesmal das Grundwissen zu jeweiligen Thema vermitteln – das verhindert die Endlichkeit des Zeitaufwands und des Formats. Abgesehen davon ist es nicht sinnvoll, einen Artikel an der Zielgruppe vorbeizuschreiben – manches darf man meiner Meinung nach durchaus voraussetzen. Sonst beginnt der Autor seine Leser irgendwann zu langweilen oder zu nerven. Und ich traue es unseren Leser mehr als zu, beim Lesen zu entscheiden ob Sie sich zu einem Thema erstmal mit Grundlagen-Wissen versorgen wollen oder gleich tiefer einsteigen können.
Ich bin hier bei t3n der E-Commerce-Fuzzi vom Dienst und bei einem kann ich dich beruhigen: wenn ich nicht gerade in einem früheren Leben mal Web-Entwickler gewesen wäre, hätte ich den Artikel mit keinem Auge gewürdigt. Die meisten E-Commerce-Entscheider dürften bei dem Thema ihren Haus-Entwickler um eine Meinung bitten. Jedenfalls die Entscheider, die ich kenne. Seine eigenen Kompetenzen zu kennen ist ein wesentliches Merkmal einer guten Führungskraft. ;-)
Just my2cents.
Mein Favorit ist auf jeden FAll YAML. Ich kenne es halt am besten – sage ich es mal so.
Es mit solch einem Artikel allen Lesern recht zu machen – halte ich für unmöglich.
Vielleicht würde es einfach reichen, ein paar Links, die Hintergrundwissen aufzeigen sollen, mit in den Artikel einfliessen zu lassen. Somit dürften dann wohl auch Quereinsteiger auf ihre Kosten kommen.
Vielen Dank für diese Serie. Sehr hilfreich.
@Peschi_70
Immer gerne doch! :)
Benjamin, besten Dank für den sehr hilfreichen Kommentar.
Ich denke auch, dass es das wichigste ist die Grundproblematik zu verstehen.
– Was ist das Problem
– Woher kommt es und warum?
– Welche Lösungen gibt es (Methoden, Tools, Frameworks)
Ob Mario diese Leistung der Problemdefinition und der Anamnese in seinem Artikel leisten will bleibt ihm überlassen. Er sagt ja ganz klar, dass sich der Artikel als Toolsammlung an erfahrene Entwickler richtet die sich der Grundproblematik bewusst sind (Entwicklung vom stationären zum mobilen Web).
Ein weiteres Problem sind auf jeden Fall die vielen Frameworks und Tools. Das überfordert einen Entwickler schnell, weil er nicht alle ausprobieren kann. Hier finde ich die Aufgabe des Journalisten eine Auswahl zu treffen und zu begründen warum welches Tool für welches Problem am besten geeignet ist. Denn „Das Beste Framework“ gibt es nicht. Es muss immer heißen „Das beste Framework für XY“.
Ich kann es nicht beurteilen in wie weit die Leser hier die Grundproblematik verstanden haben, ich würde mir wünsche es gäbe mehr „Grunsatzartikel“ die einer solchen Serie vorrausgehen bzw. den ersten Teil bilden.
@Contextoo: Genau das hätte ich mir auch gewünscht. Dann hätte man in diesem Artikel einfach kurz zu Anfang einen Disclaimer setzen können, nach dem Motto „Wenn du noch nicht so erfahren bist, dann lese doch erst einmal diesen Artikel.“ und man hätte schon mal was in der Hinsicht geleistet. Ansonsten kann ich deinen Ausführungen auch nur zustimmen.