Eine Website — viele Geräte

Roman Stranghöner: Ja hallo. Mein Name ist Roman Stranghöner, ich bin Berater und Entwickler bei der innoQ. Beschäftige mich da unter anderem mit den Themen Frontendentwicklung, Frontendarchitekturen, Usability und mobilem Webdesign. Und ja.

Till Schulte-Coerne: Wir hatten dich auch schon mal da, falls Leute noch mehr von dir hören wollen. Ich weiß die Folgennummer nicht, aber es ging um CSS-Architektur und um Präprozessoren.

Roman Stranghöner: Ganz genau, ja.

Till Schulte-Coerne: Was ja zu dem passt, was du gerade gesagt hast. Also unverdächtig. Robert.

Robert Glaser: Ja, ich bin Robert Glaser, ich beschäftige mich auch seit jetzt in den letzten Jahren überwiegend oder deutlich stärker, wie es halt immer so passt, mit der Frontendentwicklung, Frontendarchitekturen und bin allgemein auch sehr interessiert an User-Interface Design und User-Experience.

Till Schulte-Coerne: Ja, Thema heute habe ich ja schon gesagt, Responsive Design. Roman, eklär uns doch mal, was ihr euch darunter vorstellt und was das Thema so spannend macht.

Roman Stranghöner: Ja. Also das Thema an sich ist irgendwie ein bisschen ungewöhnlich vielleicht auf den ersten Blick, weil es ja irgendwie das Wort „Design“ im Namen trägt, ist aber eigentlich ein relativ technisches Thema. Der Ethan Marcotte hat im Jahre 2010 schon einen Artikel geschrieben – auf der Seite <alistapart.com> – und hat da drin beschrieben, wie man Webseiten im Prinzip so gestalten kann, dass sie halbwegs gut auch auf mobilen Endgeräten mit kleinen Viewports funktionieren. Und das quasi so technisch umzusetzen, dass man dafür nicht eine separate mobile Webseite braucht, sondern, dass quasi als eine eigenständige Anwendung im Prinzip Styles für verschiedene Viewports bereit stellt, dadurch quasi man nicht alles doppelt entwickeln muss.

Till Schulte-Coerne: Aber CSS war doch eigentlich immer schon dafür gedacht, dass man Dinge auch irgendwie adaptiv anpasst. Wieso, was ist daran originell gewesen?

Roman Stranghöner: Eigentlich, eigentlich beschreibt er in seinem Artikel drei grundlegende Techniken und mindestens eine davon ist gar nicht so neu. Das sind nämlich flexible Layouts. Und das hat man vielleicht irgendwie in den – ich weiß es gar nicht – 90er Jahren, 2000er, eigentlich vielleicht noch so halbwegs im Hinterkopf, da waren nämlich die Webseiten vornehmlich auf 100% der Breite. Und da konnte man an den Seiten ziehen und man hat quasi immer, also der Content hat sich immer über 100% der gesamten Bildschirmbreite erstreckt. Und das ist eine Zutat von diesem Responsive Webdesign, nämlich dass man eigentlich alle möglichen Viewports abfangen kann, dass man immer den Content auf 100% der Breite erstreckt.

Eine weitere Zutat sind Media Querys, da kann man im Prinzip in CSS sagen, dass bei bestimmten Viewportsgrößen, die man in Pixel oder em oder was auch immer angeben kann, bestimmte Dinge passieren sollen. Also man kann im CSS eine @media-Query hinschreiben.

Till Schulte-Coerne: Analog zu z.B. speziellen Querys für print- oder screen-Layout.

Roman Stranghöner: Genau, daher. Da kennt man das eigentlich her. Und dann kann man in den Bauch von dieser Query im Prinzip die Anpassung reinlegen, die man haben möchte. Und das kann man sich zu Nutze machen, um z.B. eben nicht dieses geile 90er-Design zu präsentieren, wo alles 100% der Breite hat, sondern da kann man ganz spezifisch für bestimmte Viewports entscheiden, was sich auf der Seite verändern soll. D.h. ich habe halt zum einen diesen Content und die Container, die über 100% der Breite gehen und kann dann feinjustieren zu bestimmten Breakpoint – nennt man die, also das sind die Punkte, an denen die Seite sich verändern soll, strukturell verändern soll – da kann man dann mit Media Querys im Prinzip die Seite so anpassen, wie man das gerne möchte.

Till Schulte-Coerne: Sachen weglassen, Sachen hinzufügen usw.

Roman Stranghöner: Genau, genau.

Till Schulte-Coerne: Quasi die Idee, die gab’s immer schon: flexible Breiten und die Technik.

Roman Stranghöner: Genau. Die dritte – um das der Vollständigkeit halber noch zu sagen – die dritte Zutat sind responsive images oder responsive media, um genau zu sein. Da bedient man sich der max-width-Property aus dem CSS, indem man im Prinzip allen Bildern oder sonstigen Video-Elementen oder Objekttags oder was auch immer quasi aufdrückt, dass sie maximal nur 100% des parent-Containers ausfüllen dürfen und somit verhindert man, dass im Prinzip die Bilder oder anderen Elemente ausbrechen aus diesem Layout.

Till Schulte-Coerne: Also ja. Jetzt haben wir schon ziemlich viele technische Details gehört, wahrscheinlich. Oder zumindet angesprochen. Ich denke mal, wir kommen später vielleicht nochmal im Detail darauf. Aber jetzt auch mal die Frage: wozu das ganze? Also unsere Nachrichtenmagazine leisten sich alle mobile Portale, wo m.xyz.de wird man jedes Mal drauf umgeleitet, wenn man mit seinem iPhone kommt. Offensichtlich scheint das ja kostenmäßig vertretbar zu sein, warum soll ich jetzt kein Mobil-Portal neben meine eigentliche Seite stellen?

Robert Glaser: Ja ich mein, den Grund hast du quasi schon impliziert, warum man das nicht tun sollte. Ich glaube jeder kennt das Spiel, man guckt unterwegs, ließt auf seinem iPhone unterwegs Spiegel Online mobil – also mobil.spiegel.de – oder sonst was. Es gibt ja noch mobil.zeit.de, es gibt m.newyorktimes.com, wobei die mittlerweile glaube ich auch ein bisschen weiter sind. Und das Problem ist halt einfach, du verschickst so einen Artikel dann von deinem Gerät an einen Kollegen, der guckt sich den aber, weil er gerade noch im Büro ist, auf dem Rechner an, also auf einem höheren Viewport, auf einem größeren Viewport, wenn man so will, und sieht dann halt so eine elend in die Breite gestreckte mobil Seite, wenn das denn nicht ganz sauber implementiert ist und das sind einfach so Sachen, die müssen irgendwie nicht sein.

Till Schulte-Coerne: Das sieht man bei Twitter, ne? Die meisten Leute, die ja einen auf einen Nachrichteneintrag hinweisen, twittern immer den mobilen Link, wobei das könnte man ja auch noch technisch umgehen. Dann macht man halt die Browserweiche wieder rein. Gibt es denn auch andere Gründe dafür? Also außer so technischen vielleicht?

Robert Glaser: Ja ich glaube vor vielen, vielen Jahren – nein es ist wahrscheinlich gar nicht so viele Jahre – da ging der Trend ja eher dahin, als das iPhone gerade aufgekommen war, dass man sagt „Wir liefern aus Serverseite mit unserem Webframework XY liefern wir verschiedenartige Templates für verschiedenartige Clients aus.“ Und da hat man halt gesagt, jetzt können wir endlich verschiedene Gerätetypen bedienen. Das hat sich ja so weit gestreckt, dass – irgendwie in Rails war das ja ganz kurz mal aufgeflammt z.B. – dass man halt hingegangen ist „So, meine index.html.erb-Datei nenne ich jetzt index.iphone.html.erb und liefere da meine iPhone Ansichten aus.“ Das hat auch, ich glaube gefühlte drei Monate ging sowas gut, dann kamen viel, viel mehr Geräte auf den Markt und da sieht man alleine schon, dass das überhaupt nicht skaliert.

Till Schulte-Coerne: Also einfach die Masse der verschiedenen Displayports lässt keine klare Unterteiltung in mobil und nicht mobil letztenendes mehr zu, ne?

Robert Glaser: Genau. Ich glaube wir haben den Begriff Viewport auch noch gar nicht erklärt, der fiel jetzt schon öfter. Im Prinzip ist das einfach nur, ja die Anzeigegröße des aktuellen Clients, was der dann darstellt.

Till Schulte-Coerne: Und bezieht sich das Thema vor allem auf Webanwendungen oder würdet ihr das noch weiter fassen?

Roman Stranghöner: Also mittlerweile geht ja der Trend zur App. Da kann man das mit Sicherheit aufwerfen, ob das denn – also früher hatte man vielleicht diese m. Seiten, die extra entwickelt wurden, jetzt sind es mittlerweile iPhone-Apps oder Android-Apps, die nebenher entwickelt werden oder parallel zum Webauftritt, zum eigentlich Webauftritt und die dann von irgendwelchen APIs bedient werden. Also ja, die Frage kommt jetzt erneut auf, es gibt ja die elendige Diskussion um mobil Web vs. App oder nativ oder wie auch immer. Es gibt mit Sicherheit für alles sinnvolle Anwendungsfälle und Pros und Contras, ich glaube, das muss man immer ganz, ganz von Usecase abhängig machen, was man da jetzt genau einsetzt. Aber ich würde mal behaupten, im Fall von einer klassischen Webseite, kann es sich schon empfehlen, einfach eine vernünftige Responsiveness hinzuzufügen und kann sich damit eigentlich viel Entwicklungaufwand sparen.

Till Schulte-Coerne: also einfach auch ein Kostenfaktor.

Roman Stranghöner: Ja, auf jeden Fall.

Till Schulte-Coerne: Dass man nicht zwei Teams hat, die ein und dieselbe Sache machen.

Robert Glaser: Genau. Und du machst dir halt auch viel mehr Gedanken darüber, dass du – also wenn du unter Umständen eine responsive Website entwickelst, dann gehst du ja ganz anders an das Thema ran „Wie stelle ich meinen Content denn nun dar?“ Also du gehst unter Umständen vielleicht sogar direkt von kleinen Geräten aus, das wäre – um mal wieder ein Buzzword einzubringen – dieser mobile first Ansatz, dass man halt anfängt, sein Design von kleinen Viewport herauf aufzubauen auf größere und sagt „Ich beschränke mich in der kleinsten Ansicht eben auf das Wesentliche, ich konzentriere mich darauf, wie ich den Content möglichst optimal darstelle und gucke dann, wie baue ich das Stück für Stück weiter nach oben.“ Und damit verhindert man halt auch oftmals Sünden, die in der Vergangenheit aufgekommen sind, wie z.B. „Ja, wir machen jetzt eine responsive Website oder wir machen stecken die nach und lassen dann einfach ganz viele Funktionen der eigentlichen Website weg, nur der Prämisse halber, dass mein Content in einer vernünftigen, lesbaren Größe auf dem Mobilgerät gerendert wird.“ Der User kann aber effektiv gar nicht mehr viel machen, außer irgendwas zu lesen oder vielleicht sogar dann zwangsweise den Button ganz unten zu klicken „Leiten Sie mich bitte zur Desktop-Website weiter, weil ich kann hier nichts tun.“

Till Schulte-Coerne: Das kenne ich auch zur Genüge.

Robert Glaser: Genau. Das sind auch so Sachen, die einem immer wieder begegnen. Leider immernoch und auch oft sehr ärgern.

Till Schulte-Coerne: Wir haben jetzt ja was die Beispiele angeht jetzt schon über diverse Nachrichtenportale und ähnliches diskutiert, aber wie sieht das aus? Also viele unserer Zuhörer haben vielleicht gar keine öffentliche Webseite, sitzen irgendwo in einem großen Unternehmen. Würdet ihr das trotzdem als sinnvoll erachten, so anzufangen von vornherein? Also gerade, wenn man neue Anwendungen baut?

Roman Stranghöner: Also ich würde ganz klar dazu tendieren. Ich habe das zumindest in der Wahrnehmung, dass es ja durchaus öfters Mal irgendwie so ein Projekt gibt, wo es eine interne Anwendung zu entwickelt gilt. Ob das jetzt für eine Bank oder eine Versicherung oder irgendeinen anderen Großen, also vielleicht nicht unbedingt üblichen Kunden für so eine Webseite. Und da macht es durchaus Sinn, weil die Anforderungen ja durchaus sein können, dass es Außendienstmitarbeiter gibt, die irgendeine interne Anwendung von außerhalb bedienen müssen und dann stellt sich ja durchaus die Frage: Lassen wir dafür jetzt eine App entwickeln oder nehmen wir die Webanwendung, die es schon gibt, und versehen die quasi mit den notwendigen Styles, um sie auch auf anderen Geräten optimal darstellen zu können. Und also ja, also ich würde sagen, das ist durchaus auch ein Anwendungsfall für Kunden oder generell für Webseiten oder Webanwendungen, die jetzt nicht unbedingt so die klassischen Webseiten im Netz sind, die jetzt vielleicht der normale User wie du und ich benutzen.

Till Schulte-Coerne: Das sehen wir ja an unserem Kundenstamm, ne? Also die iOS oder iPad Offensive wird ganz oben in der Geschäftsleitung in den obersten Etagen entschieden und kommt dann plötzlich unten an und dann hat man halt das Problem: Wie können die jetzt mit ihren iPads, von denen wir gerade eine halbe Millionen gekauft haben, ins Internet oder ins Intranet, auf unsere Seite.

Robert Glaser: Ja du weißt das ja im Vornherein teilweise auch gar nicht, wie Kollegen und Mitarbeiter im selben Unternehmen überhaupt arbeiten. Das kannst du ja nicht alles vorher wissen. Ich mein, du arbeitest vielleicht im ganz anderen Fachbereich oder machst die Dienstleistung für diese anderen Bereich und du weißt nicht, wie die in Gänze arbeiten. Wenn da eben 100 Leute sind im Unternehmen, für die das kritisch sein könnte, unterwegs mal beim Kunden vernünftig mit so einer Anwendung arbeiten zu können, wo vor drei Jahren mal jemand entschieden hat, dass eigentlich nur auf Laptops und im Büro gearbeitet wird, dann nimmst du den Leuten eben diese Möglichkeit sinnvoll mit dieser Anwendung zu arbeiten. Und ich glaube, man kann das nie im vorhinein wissen, wie User die eigene Anwendung benutzen. Und dann sollte man einfach nicht im vorhinein solche Entscheidungen treffen und den User derartig bevormunden.

Till Schulte-Coerne: Aber jetzt haben wir ja auch ganz viel tolles gehört und warum wir das alle machen sollten und zwar in jeder Situation. Gibt es denn auch Nachteile? Also würdet ihr auch an einer Stelle z.B. sagen, wir lassen das mal sein, aus Budgetgründen oder warum auch immer?

Roman Stranghöner: Ja also ich hatte ja eben schon die Vor- und Nachteile angesprochen. Also ich glaube das muss man wirklich immer vom Anwendungsfall abhängig machen. Also ich meine, wenn ich jetzt – ein Spiel ist vielleicht jetzt ein doofes Beispiel, aber wenn ich wirklich den Performancevorteil, den mir eine native App bietet, wenn ich den jetzt in meiner Anwendung unbedingt brauche, dann macht es vielleicht keinen Sinn.

Till Schulte-Coerne: Ja ok, das ist das Thema App vs. Web. Aber einfach die Responsivness wegzulassen und zu sagen, ich baue meine Webanwendung so, wie ich es die letzten 20 Jahre gemacht habe – gibt es dafür, also warum sollte ich, gibt es da Nachteile?

Roman Stranghöner: Also es ist auf jeden Fall komplexer, mit Sicherheit, weil man muss ja im Prinzip diese ganzen Fälle auch irgendwie testen. Also der gängigste Test ist da irgendwie manuelles Testen. Also dass man irgendwie im schlimmsten Fall an dem Browserfenster irgendwie rumzieht und dann gibt es irgendwie einen Tester, der sich das anguckt, ob das noch alles gerade ist oder ob da irgendwas auseinander platzt.

Dann gibt es mit Sicherheit den Nachteil des „Workflows“ – ich nenn in mal in Anführungsstrichen, weil ja bisher für solche Webanwendungen irgendwie irgendein Designer vielleicht engagiert wurde oder eine Agentur, die irgendwie ein Design über den Zaun geworfen haben und dann wird das quasi ausimplementiert. Und dieses einmal vorher das komplette Design machen und danach ausimplementieren funktioniert hier halt nicht so gut, weil man im Prinzip nicht sinnvoll für jede Viewportgröße eine Photoshop-Datei über den Zaun werfen kann, im schlimmsten Fall, sondern da muss man eigentlich iterativ dran arbeiten. Und im besten Fall – halt mobile first – wirklich mit dem kleinsten Viewport anfangen und dann sich da heran tasten und im Prinzip das Layout von da aus aufbauen.

Und ja, zu guter letzt mit Sicherheit, also neben den gegebenenfalls steigenden Kosten durch die Komplexität, die man sich da mit einkauft – also irgendjemand muss das ja auch bauen, ist ja jetzt nicht so, dass das einfach vom Himmel fällt – gibt es auch jetzt gerade eine Diskussion, ob den dieses Responsive Design eventuell zu aufgebläht ist und zu viel Performance Einbußen mit sich bringt.

Till Schulte-Coerne: Medie Querys sind teuer zu berechnen.

Roman Stranghöner: Ne, nicht die, sondern auch dass man doch mehr Pageload hat, also mehr CSS ausliefert oder mehr Javascript, was irgendwelche Polyfills oder was auch immer. Auf jeden Fall, dass der Footprint von so einer Seite merklich größer wird, als er vorher war.

Till Schulte-Coerne: Könnt ihr denn Zahlen nennen? Also was mich interessieren würde, wäre: wie schätzt ihr das ein, wie viel aufwendiger ist es, das zu entwickeln und vielleicht auch wie viel größer ist der Footprint?

Roman Stranghöner: Also einen Footprint kenne ich jetzt ehrlich gesagt so aus dem Kopf nicht, weil ich diese Milchmädchenrechnung noch nicht gemacht habe. Aber es gibt – der Dave Rupert, das ist ein amerikanischer Webentwickler aus Austin glaube ich, der hat jetzt gerade zwei sehr nette Artikel rausgebracht: RWD Bloat Eins und Zwei, wo er im Prinzip mal seinen eigenen Blog auseinander genommen hat und mal geguckt hat: wie viel mehr ist denn eigentlich der responsive Anteil von meinem Block? Und er hat halt irgendwie vorher einmal festgestellt, dass seine Pagespeed Ergebnisse und seine Webpage Testergebnisse halt ziemlich mau waren und hat dann haarklein aufgedröselt und hat dabei festgestellt, dass im Wesentlichen, also der Teil vom CSS, der für sein responsive Verhalten auf der Seite verantwortlich ist, dass es so ungefähr 10% beträgt – das ist jetzt wie gesagt nur für seinen Fall jetzt im Prinzip, aber ich würde auch dazu tendieren, dass der Anteil, der da irgendwie noch oben drauf kommt, vom Footprint her gar nicht so viel mehr ist. Ich glaube da fallen andere Dinge viel stärker ins Gewicht, wie z.B. Webfonts, die elendig groß sein können und langsam laden, die verschiedenen Javascript Dateien, die irgendwie im schlimmsten Fall konkateniert auf einen Schlag geladen werden usw.

Till Schulte-Coerne: Ja, wir haben das jetzt gekauft.

Robert Glaser: Sehr schön.

Till Schulte-Coerne: Ihr habt uns überzeugt. So schlimm sind die Gegenargumente nicht. Was mache ich denn jetzt, um meine Seite performant oder – nicht performant – responsive zu bekommen? Performant natürlich auch. Gibt’s da irgendwie so ein paar patterns, die man da anwendet, und dann geht der W3C-Check für responsivness auf grün oder wie mache ich das?

Roman Stranghöner: Von Google gibt es mittlerweile auch ein mobile Check auf dem Webpage Test oder wie er auch immer heißt. Der checkt mittlerweile auch, ob die mobile Styles so sind, wie sie sein sollten. Wobei sie es teilweise auch ein bisschen übertreiben. Aber egal.

Robert Glaser: Ja Patterns haben sie mit der Zeit glaube ich eine ganze Menge raus kristallisiert, ne?

Roman Stranghöner: Ja.

Robert Glaser: In den letzten Jahren, in denen man das schon so macht. Ich glaube, wir können mit den, wir können wahrscheinlich das bekannteste überhaupt, können wir wahrscheinlich direkt erwähnen: den sogenannten Hamburger-Button.

Till Schulte-Coerne: Also keinen Hotdog.

Robert Glaser: Genau. Ja ursprünglich hieß der Mal Hotdog-Button, nur – ich habe das auch lange so genannt – aber irgendwie scheint den heute keiner mehr so zu nennen, sondern mittlerweile heißt der halt Hamburger-Button. Das ist dieser Button, wo die drei Striche übereinander liegen. Das ähnelt halt wahrscheinlich wirklich einem Hamburger am ehesten und weniger einem Hotdog. Den kennt glaube ich jeder, dass ist dieser Button, den man häufig auf responsive Websites ganz oben recht oder halt auch links sieht und der einfach dazu dient, die Hauptnavigation aufzuklappen, die bei bestimmten kleineren Viewport einfach versteckt wird in so einem sogenannten Schieber. Und wenn man da halt drauf toucht oder klickt, dann rollt da was runter und die Navigation erstreckt sich dann halt vertikal in dieser Schublade, die da raus fährt, statt halt typischerweise horizontal. Ich glaube, das kennt jeder und hat das vielleicht schon mal gesehen auf irgendwelchen Websites. Das ist auch gewachsen, dieses Pattern, das kam sogar im letzten halben Jahr mal auf, die Diskussion, dass basiert auf irgendeiner statistischen Erhebung, die dann ergab, dass viele User gar nicht wissen, was denn dieser Button zu bedeuten hat. Da hatten also Designer und Entwickler impliziert, dass Leute da drauf klicken, weil sie eben das verstehen, dieses Symbol. Dass da etwas raus fährt. Aber ursprünglich stammt dieses Symbol sogar aus der iOS Iconografie, wenn ich mich da jetzt nicht um Kopf und Kragen rede. Aber ich glaube, ich hab es so verstanden und das diente ursprünglich dafür, ein Anfassen und Verschieben von UI-Elementen zu verbildlichen. Dass man Sachen anfasst und die Sortierung einer Liste ändert. Deswegen, diese drei Striche ähneln ja auch eigentlich mehr einer Liste, als einer eingeklappten Navigation. Aber wie auch immer, man hat sich dann…

Till Schulte-Coerne: Erst recht keinem Hamburger.

Robert Glaser: Es hat sich dann irgendwie eingebürgert, wie das halt so ist mit einigen Patterns, dass man das Symbol eben dafür benutzt. Und irgendwie ist es ja auch gut, dass sich Dinge einbürgern, weil irgendwann tritt halt ein Lerneffekt bei Usern ein und die erkennen solche Sachen wieder. Das nennt sich dann „gelerntes Verhalten“.

Till Schulte-Coerne: Haben wir es denen denn beigebracht, mittlerweile?

Robert Glaser: Ja wie gesagt, diese statistische Erhebung, die ich gerade mal angesprochen hatte.

Till Schulte-Coerne: Ist die hochaktuell noch?

Robert Glaser: Ne, ich glaube die ist auch schon wieder ein paar Monate oder ein halbes Jahr alt, oder? Da hat man halt rausgefunden, dass User eben nicht wissen, dass sie da drauf klicken sollen und hat dann angefangen, neben diese drei Striche, neben den Hamburger auch noch „Menü“ zu schreiben. Und das hat wohl dazu geführt, dass doch die User deutlich besser verstehen, dass die darauf klicken sollen. Und man hat halt auch gesehen, dass sie dann wirklich darauf klicken. Also das wäre halt so eine Interation innerhalb eines Patterns. Wir können das halt auch nochmal raussuchen und dann eventuell in den Shownotes verlinken.

Till Schulte-Coerne: Was gibt es noch so an Patterns? Klassischerweise in dem Umfeld?

Roman Stranghöner: Also um mit Content zu arbeiten, gibt’s die Möglichkeit eigentlich oder das ist auch relativ weit verbreitet, dass man – wie man das bisher so gewohnt war, hatte man meistens irgendso eine Art Grid auf der Seite, die für eine bestimmte Viewportgröße optimal ist. Und dieses Layout verändert sich dann irgendwie, wenn man auf kleinere Viewports geht, im besten Fall so, dass bestimmte Spalten dann auf einmal nicht mehr drei oder vier Spalten von einem zwölf Spalten Grid umfassen, sondern auf zwölf Spalten vergrößert werden. So hat man dann im Prinzip den Content immer gut lesbar auf der vollen Breite. Und alles schiebt sich quasi untereinander. Das hat natürlich zur Folge, dass man sehr viel scrollen muss, aber damit bekommt man zumindest seinen Content relativ gut auf die gesamte Seite verteilt.

Till Schulte-Coerne: Also das heißt, ich habe eine Tabelle.

Roman Stranghöner: Zum Beispiel.

Till Schulte-Coerne: Habe eine Zeile, da liegen dann fünf Blöcke drin in der normalen Auflösung.

Roman Stranghöner: Du hast keine Tabelle.

Till Schulte-Coerne: Jaah.

Robert Glaser: Bitte nicht.

Roman Stranghöner: Bitte nicht. Die Zeiten haben wir hinter uns. Nein, aber ja. Im Prinzip, genau, hat man eine Reihe oder Zeile, da ist Content aufgeteilt auf verschiedene Spalten und sobald ich nicht mehr genug Platz habe, um den Content vernünftig darzustellen, breche ich im Prinzip diese Spalten um und mache daraus eine einzelne Zeile. [Anmerkung: Natürlich wird die Zeile umgebrochen und eine einzelne Spalte entsteht.]

Das ist auch so ein weiterer Punkt, den man vielleicht nochmal hervorheben sollte. Diese Breakpoints, also diese Punkte, an denen Content umbricht, die sollten idealerweise nicht an irgendwelchen Devices oder Viewportgrößen hängen, sondern idealerweise hängen die am Content. Also ich breche dann eigentlich erst um, wenn der Content im Prinzip doof aussieht auf einer bestimmten Viewportgröße. Und nicht, weil das iPhone bei 480 Pixeln in der Breite irgendwie endet, also im Landscape-Modus.

Till Schulte-Coerne: Das heißt diese Steuerung kann ich nicht einfach irgendeinem Framework überlassen, dem ich sage: die und die Sachen…

Roman Stranghöner: Kann man schon, natürlich. Also Bootstrap macht das zum Beispiel. Der springende Punkt bei diesem Responsive Webdesign ist ja, dass man im Prinzip alle Punkte zwischen diesen Breakpoints ja mit den 100%, also den flexiblen Grids abfängt. Das heißt, sämtlicher Content, der irgendwie vielleicht bei 420 Pixeln oder mehr als 480 Pixeln liegt, der würde immernoch vernünftig dargestellt werden, weil das flexible Grid dafür sorgt, dass der Content immer auf 100% der Breite ist. Nur bei diesen Breaktpoints sorge ich im Prinzip dafür, dass das Layout angepasst wird, also ganz speziell angepasst wird. Z.B. dass irgendwelche Spalten umbrechen oder so. Genau, und das ist ein beliebtes Pattern, dass man die Breakpoints im Prinzip an Devicegrößen oder Viewportgrößen von verschiedenen Devices hängt, aber eigentlich sollte man das vom Content abhängig machen. Und das macht mal idealerweise auch wieder mobile first, man fängt mit dem Content auf dem kleinsten Gerät an und arbeitet sich dann nach oben.

Till Schulte-Coerne: Haben wir noch was?

Roman Stranghöner: Also viele weitere Pattern – also ich weiß nicht, ob wir jetzt unbedingt alle möglichen Pattern durchsprechen müssten – es gibt eine sehr schöne Übersicht von Brad Frost, der hat so eine Seite zusammen getragen, die nennt sich irgendwie „Responsive Design Resources“ oder so ähnlich. Und da gibt es auch jede Menge Pattern für verschiedenste Fälle, für verschiedensten Content, ob das jetzt Karussels sind oder – ah ne, Karussels macht man nicht – oder irgendwelche anderen Content-Elemente. Die kann man da wunderschön nachlesen und sich inspirieren lassen. Die sind auch aufgelistet mit Vor- und Nachteilen. Je nachdem, was man da jetzt genau mit erzielen möchte, kann man sich da das rauspicken, was man braucht und dann ausimplementieren.

Robert Glaser: Generell sind die Grids ein schon sehr, sehr wichtiges Pattern und helfen auch vielen Leuten dabei Responsive Websites zu bauen. Ich weiß nicht, da gab es einmal diese Website, auf der ganz cool in Schritten – ich glaube fünf Schritte waren das – dargestellt war, wie man selber ein Responsive Grid baut. Das hat man einmal sich durchgelesen oder sogar mitgemacht und dann hat man gesehen, das ist eigentlich total easy. Also das Thema ist gar nicht so kompliziert, wie es sich eigentlicht anhört. Man muss auch gar nicht so unbedingt ein Framework benutzen. Klar, es ist vielleicht besser, weil da diese ganzen Fallstricke schon abgedeckt sind, aber allein, um das zu verstehen, ist es vielleicht ganz gut, wenn man das ein Mal vielleicht selber baut, prototypisch.

Roman Stranghöner: Man kann ja auch, es gibt ja auch verschiedene Arten von Grid-Frameworks. Es gibt ja einmal diese out-of-the-box / alles-ist-am-Start Frameworks, wie Bootstrap oder Foundation oder so. Man kann aber auch sehr minimalistische Frameworks benutzen, die wirklich nur das nötigste mitbringen. Und vielleicht sogar auf Basis von Präprozessoren arbeiten, sodass man semantisch sinnvolles Markup auch erhält und nicht überall coll-5 dran schreiben muss. Da wäre Susy z.B. so ein Kandidat, es gibt aber auch inuit z.B. Oder diverse andere, die wir vielleicht auch alle noch verlinken oder einige.

Till Schulte-Coerne: Die Liste der Shownotes wird lang.

Roman Stranghöner: Ja.

Robert Glaser: Ich habe halt die Erfahrung gemacht, dass diese Grids vielen Leuten, die vielleicht gar nicht so aus der Ecke kommen, z.B. Print-Designer, also Leute, die eher so in Richtung Print jahrelang gearbeitet haben, die tun sich auf einmal viel leichter mit Webdesign, weil die sind das halt gewohnt, in Grids zu arbeiten. Und wenn – die Terminologie ist halt auch sehr ähnlich. Es handelt sich ja nicht um ein festes Grid, sondern um ein Responsive Grid. Und dann verstehen die auf einmal viel intuitiver, dass man Sachen auf ein Grid aliniert und dieses Grid kann halt verschiedene Größen haben. Also in Print Begriffe übertragen, hätte man halt verschiedene Grids, unterschiedlich groß. Und da tun sich viele Leute halt auch deutlich leichter mit, da jetzt auch einzusteigen in das Thema.

Till Schulte-Coerne: Ja gut. Wenn ich jetzt auf der grünen Wiese sitze und mein neues Enterprise-Projekt starten möchte, mit einem halbwegs modernen Webframework: Was muss ich denn jetzt tun, um responsive zu werden? Muss ich zu einer Agentur gehen oder was schlagt ihr genau vor?

Robert Glaser: Ja, idealerweise kommst du zu uns.

Till Schulte-Coerne: Aber ansonsten? Also gibt es eine – die Frameworks hast du jetzt ja schon ein bisschen gerade genannt.

Roman Stranghöner: Genau, das ist mit Sicherheit so eine der ersten Abwägungen, die man vielleicht – also rein technisch betrachtet – sich überlegt, ob man, also wie viel Arbeit man sich jetzt abnimmt. Also erstmal natürlich, abhängig vom Usecase, entscheidet, was irgendwie das Beste ist, was zu einem passt. Also Bootstrap oder Foundation sind nicht immer die besten Kandidaten. Die sind halt ziemlich überladen, da muss man gucken, dass man Zeug wieder rauswirft. Andererseits, wenn man sehr minimalistisch startet und später merkt, dass man mehr Zeit braucht, zum Prototypen oder so – wie gesagt, das muss man halt abwägen. Aber dann, also sagen wir mal, man hat irgendeine Art von CSS-Grid gewählt, dann hat man ja im Prinzip erstmal ein gutes Fundament für das eigentliche Layout und dann gibt es halt abhängig davon, was man da so darstellen will, sehr viele Tools, die man benutzen kann, um sehr spezifische Probleme zu lösen. Wie z.B. wenn man eine Seite hat, die sehr Bildlastig ist, die mir im Prinzip Bilder vernünftig zusammen rechnet, also ideal zusammen rechnet für verschiedene Viewportgrößen, die mir dann abnimmt, diese Bilder auszuliefern, z.B. nur an mobile Endgeräte oder an Desktopgeräte. Es gibt neben…

Robert Glaser: Das mit den Bildern war auch so ein Problem bei den ganzen News-Seiten, dem die sich stückweise genähert haben. Ich glaube, als diese Retina-Displays aufkamen, haben viele Leute dann auch gesehen, weil die Nachrichten Vorschaubilder, die ja nun mal bei jeder Headline, wo eins dran klebt, die sehen auf einemal so verwaschen aus. Das lag halt einfach daran, dass sie in einer niedrigeren Auflösung für viel niedrigere Displayauflösungen gedacht waren.

Till Schulte-Coerne: Wieso auf einem Retina-Display? Also Retina-Displays sind hochauflösende Displays und wo ist jetzt genau das Problem, wieso muss da irgendetwas unscharf aussehen?

Robert Glaser: Ja, weil ein Retina-Display eigentlich da, wo ein normales Display, wenn man das heute überhaupt noch sagen kann, ein altes Display ein Pixel pro Bildpunkt darstellt, stellt halt ein Retina-Display dann zwei Pixel dar, pro Punkt.

Till Schulte-Coerne: Vier, oder?

Roman Stranghöner: Oder noch mehr.

Robert Glaser: Oder vier, weil das ist ja immer weiter gewachsen. Und mittlerweile sind diese Aufteilungen auch nicht mehr mit fixen Zahlen zu erschlagen. Also am Anfang gab’s ja in CSS die Sachen, dass man einfach anhand dieser Pixelaufteilung pro Punkt gesagt hat: Dann rendere ich das Hintergrundbild und dann das. Aber das skaliert halt überhaupt nicht mehr, weil diese Spezifikation sich immer weiter auseinander entwickeln und es gibt immer viel mehr auch noch, genauso wie mit den Displaygrößen an sich. Und deswegen kommen jetzt in letzter Zeit verstärkt, wird wieder der Fokus auf dieses picture-Element oder generell das img-Tag in HTML gelegt, dass der ein neues Attribut kriegt, nämlich das source-set-Attribut. Ich glaube, diesen img-Tag kennt jeder, der hat ein src-Attribut, wo ich einfach die Bild-URL reinschreibe, die angezeigt werden soll. Und demnächst kommt ein sogenanntes src-set-Attribut dazu und da kann ich in einem bestimmten Pattern kann ich halt sagen: Für die Displayweite nimm bitte das Bild und für die andere bitte das. Ich kann das aber auch in diesen „Pixel auf Punkt“-Werten definieren. Dann gibt es verschiedene Syntaxen, wie ich das benutzen kann. Das picture-Element bietet dann nochmal viel mehr Möglichkeiten, aber die sind halt noch nicht in allen Browsern umgesetzt. Also in ziemlich wenigen Browsern bisher zur Gänze. Da gibt es aber schon Polyfills in Javascript implementiert, unter anderem Picturefill, womit ich das heute eigentlich schon nutzen kann – mit kleinen Seiteneffekten.

Roman Stranghöner: Da haben wir gerade noch so einen weiteren Punkt, von dem grüne Wiese Oberpunkt etwas abgewichen, aber die Polyfills, die man zum Teil braucht, um dieses…

Till Schulte-Coerne: Polyfills sind? Um das nochmal zu erklären.

Roman Stranghöner: Das sind im Prinzip Javascript-Patches, die Funktionalität nachliefern, die der Browser nicht hat. Also Robert hat es gerade schon genannt: dieser Picturefill Polyfill sorgt zum Beispiel dafür, dass Browser, die dieses Picture-Element oder auch das src-set-Attribut nicht kennen, dass die im Prinzip über Javascript nachgepatcht werden, sodass sie damit etwas anfangen können. Und das ist halt, sowas braucht man nicht nur für Bildern, sondern sogar für sowas wie Media Querys, wenn man z.B. den Internet Explorer 8 bedienen muss. Das ist gar nicht so unüblich. Dann sollte man sich Gedanken machen, ob man sowas wie respond-js für den Internet Explorer z.B. ausliefert, was dann dazu führt, dass man seine Media Querys auch im Internet Explorer vernünftig…

Till Schulte-Coerne: Das parst dann das CSS im Internet Explorer? Ist ja heiß.

Roman Stranghöner: Ein weiterer Punkt, den man auf der grünen Wiese vielleicht noch beachten sollte, wo viele Leute dann vielleicht auch das erste Mal rein rennen, ist dieses media-Tag, was dafür sorgt, dass die Device-Größe als Maximalbreite festgelegt wird und nicht die…

Robert Glaser: Den meta-Tag meintest du.

Roman Stranghöner: Äh, den meta-Tag.

Robert Glaser: Meta-name-viewport, wo man das einfach einstellt.

Roman Stranghöner: Genau, genau. Da muss man dann auch ein bisschen im Markup drauf achten. Also man kann sich nicht nur auf sein CSS-Framework der Wahl verlassen, sondern muss auch an diversen anderen Stellen ein bisschen gucken.

Till Schulte-Coerne: Wir hatten ja jetzt schon tausend kleine Dinge, wo man überall drauf achten muss. Jetzt habe ich vielleicht nicht darauf geachtet, bin aber trotzdem der Meinung, dass ich fertig bin, wie kann ich dass denn nachher alles testen? Also wie stellt ihr euch so den normalen Arbeitsablauf eines Frontend-Entwicklers, wie das ja immer so schön heißt, vor?

Robert Glaser: Ja idealerweise gehst du halt nicht hin und hast deinen Chrome, deinen Firefox, deinen Safari, was auch immer auf, und ziehst dann einfach immer nach einem Page-Reload das Fenster in der Weite größer oder kleiner, um die Dinge zu testen. Das tut man wahrscheinlich in sehr großem Umfang seiner Zeit, aber das verdeutlicht eben auch, wie viel man da eigentlich manuell noch machen muss. Und da haben sich halt ein paar Tools in dieser Situation etabliert, z.B. Browser-Sync hab ich letztens entdeckt erst, gibt’s wahrscheinlich schon ein bisschen länger. Das macht sowas, wie live reload und macht denkt das noch ein bisschen weiter. D.h. ich spare mir einfach eben diesen refresh-Aufruf in meinem Browser, wenn ich in meinem Editor eine Änderung mache. Das ist gerade bei Responsive Entwicklung nimmt das einem schon ganz viel lästige Klick- oder Tastaturarbeit ab. Und dieses Browser-Sync geht halt auch soweit, dass das sich vor meinen lokalen Entwicklungsserver hängt, auf einem anderen Port z.B., und wenn ich diesen Port, also diesen Host mit dem Port dann auf verschiedenen Geräten, mit verschiedenen Browsern öffne, diese Seite, dann werden Tätigkeiten, die ich in einem Client ausführe, in den anderen gespiegelt. Z.B. ein Scroll.

Roman Stranghöner: Oder ein Klick auf einen Link.

Robert Glaser: Oder ein Klick auf einen Link. Oder der Refresh. Und das ist einfach ganz toll, wenn man dann irgendwie neben seinem Schreibtisch, wo das große Display steht, noch sein iPhone und sein iPad hinlegt und ja dann einfach nur am PC diese Testvorgänge, die man halt braucht, durchführt und sich das auf den Geräten automatisch spiegelt dann, live quasi. Das finde ich immer ganz hilfreich.

Till Schulte-Coerne: Klingt auch ziemlich cool.

Robert Glaser: Ja.

Roman Stranghöner: Ja, ist es auch.

Till Schulte-Coerne: Kann man seine Kollegen aus dem Backend mit beeindrucken.

Robert Glaser: Ja man sollte sich wahrscheinlich auch sofort ein Responsive Test Büro etablieren, wenn man ein Zimmer zu viel hat und da möglichst alle Geräte ein Mal kaufen und an die Wand nageln, wie Audi das glaube ich gemacht hat, jetzt für ihre Website. Ich habe das irgendwo mal gesehen.

Roman Stranghöner: Es gibt auch natürlich noch ganz viele andere Alternativen zum Device Lab. Also es gibt da auch offene Device Labs hier in Köln z.B. – oder nicht hier in Köln, in der Nähe in Köln zum Beispiel. Und bestimmt auch in Düsseldorf und in vielen anderen großen Städten, gibt es – je nachdem, es können Agenturen sein, es können aber auch einfach Privatleute sein, die diese Devices sammeln und dann der Öffentlichkeit zur Verfügung stellen, dass wenn man mal nett fragt: „Kann ich mal Nokia Was-weiß-ich-was haben?“, um das zu testen, dann kann man in der Regel das über solche Device Labs bekommen. Es gibt aber auch die Möglichkeit das in Simulatoren laufen zu lassen, für Android und iOS gibt es da welche, die meistens sogar direkt mit an Board sind, in den Entwicklertools.

Es gibt auch so Services, wie Browserstack oder – wie heißt dieser andere nochmal? – irgendwas mit Soup (Anmerkung: gemeint war Sauce Lab, siehe Shownotes), da kann man sich im Prinzip ein, also man bekommt von denen quasi eine fertige VM im Browser hochgefahren und dann kann man auf beliebigen Betriebssystemen in verschiedenen, für verschiedene Geräte im Prinzip sich den Kram simulieren lassen. Da gibt es halt auch verschiedenste Pakete, die man dann auch benutzen kann. Es geht sogar soweit, dass man User-Agent Tests darin laufen lassen kann, wenn man denn welche hat.

Und dann gibt es halt noch neben dem Browser Auf- und Zuschieben, wenn man denn tatsächlich in den Dev-Tools unterwegs ist, mittlerweile sogar die Möglichkeit, diesen Device-Mode anzumachen – also im Chrome ist er glaube ich noch im Canary Build vorhanden, aber ich glaube im Firefox ist er mittlerweile drin. Da kann man sich im Prinzip das Browserfenster Auf- und Zuschieben sparen, da gibt es ein speziellen Modus, den man in den Entwicklertools anklicken kann und dann simuliert der – also kann man oben eingeben, ich möchte jetzt eine Breite von Galaxy 4 haben oder so, dann kann man sich neben diesem Browserfenster Zu-/ Aufschieben auch noch simulieren lassen, wie das denn so ist, wenn ich verschiedene Netzwerkbreiten habe. Also ich kann 3G simulieren oder E oder was auch immer. Und dann sehe ich halt, wie sich meine Seite nach und nach aufbaut und im schlimmsten Fall, wie sie halt auseinanderplatzt, wenn ich nicht genug Bandbreite habe und mein Medie Query Polyfill halt noch auf der Leitung hängt und alles andere schon explodiert. Ja, sowas kann man dadrin ganz schön sehen.

Also es gibt eine Reihe von sehr nützlichen Tools, die man benutzen kann.

Till Schulte-Coerne: Die kommen alle in die Shownotes.

Roman Stranghöner: Bestimmt, ja.

Robert Glaser: Ja.

Till Schulte-Coerne: Mal gucken, ob unsere Website responsive genug ist, um die ganzen Links anzuzeigen.

Roman Stranghöner: Wenn die Links lang genug sind.

Till Schulte-Coerne: Ja, ihr habt ja die Webseite gerade gemacht, von uns. Da ward ihr ja hauptsächlich dran beteiligt. Die soll auch responsive sein, also wenn jemand sieht, dass sie an eine Stelle nicht responsive ist, dann kann er uns gerne eine Mail schicken. Aber was waren denn so die Hauptherausforderungen, als ihr das gemacht habt? Also ihr scheint ja so getestet zu haben. Warum musstet ihr das? Was war so kompliziert an der Sache? Warum hat das Framework es nicht von vornherein alles gekonnt?

Robert Glaser: Ja ich glaube, wir haben – ein Schwerpunkt an der Sache war, dass wir gesagt haben, wir wollen jetzt nicht die ganze Website <innoq.com> in einem Schlag neu bauen und launchen. Wir fangen mit einem neuen, für uns wichtigem Feature an, nämlich dieser Artikelansicht, wir wollten nämlich Artikel bei uns auf der Website veröffentlichen und haben gesagt, wir etablieren anhand dieser Artikelansicht auch mal das neue CI, wenn man so will. Das upgedatete CI. Und arbeiten uns dann weiter auf den Rest der ganzen Website. Und wie das immer so ist, kennt man das ja, dass dann die Stilregeln hochgradig, also auf einem bestimmten Level spezifisch auf diese Artikelansicht gemünzt sind und wir mussten das dann immer wieder nachziehen und auf die Hauptseite überführen und im Prinzip mussten wir einfach viel aufräumen.

Till Schulte-Coerne: Es ist glaube ich das Dritte Plädoyer dafür, dass wenn man responsiv sein will, man das von vornherein einplant.

Robert Glaser: Genau.

Roman Stranghöner: Genau. Schön iterativ am besten auch mit dem kleinsten Viewport anfangen.

Robert Glaser: Ja.

Roman Stranghöner: Dann spart man sich sehr viel Ärger später.

Till Schulte-Coerne: Was gab es noch für Probleme? Oder gab es überhaupt keine Probleme?

Robert Glaser: Ja generell Dinge auch zu testen. Also auch automatisiert vor allem.

Roman Stranghöner: Eine der großen Herausforderungen von Responsive Webdesign ist ja immer wieder die Markup-Reihenfolge. Also man will ja z.B., dass aber einer bestimmten Viewportgröße irgendwas auf ganz an das Ende der Seite rutscht. Und das klappt meistens nicht so richtig sauber, weil dieser Content irgendwo im Markup in der Mitte steht oder ganz oben oder so. Oder ein übliches Pattern ist auch, dass man das Hauptmenü nach ganz unten schiebt zum Beispiel. Also neben dem Hamburger gibt es halt auch das Ding, dass man halt unten eine Liste mit den ganzen Links hat, weil man da sowieso landet, wenn man den Content quasi durchgescrollt hat. Und das ist halt, also man kriegt das irgendwie schon hin mit absoluter Positionierung, aber das ist halt nicht so ganz sauber und da bremst einen so ein bisschen die Markup-Reihenfolge und dafür gibt es jetzt erst so nach und nach auch im CSS im Prinzip Möglichkeiten, diese Markup-Reihenfolge aus den Angeln zu heben. Etwas, was man jetzt schon ganz gut benutzen kann, ist z.B. Flexbox. Damit kann man zumindest – also eigentlich ist es dafür gedacht, dass man auf einer Zeile im Prinzip Spalten im Prinzip in der Reihenfolge ändern kann, die sich automatisch vernünftig alinieren. Also sowohl horizontal, als auch vertikal. Da hat man unendlich viel Einstellungsmöglichkeiten. Und damit kann man sehr viel machen und das kann man eben auch in Media Querys benutzen und dann halt z.B. sagen, dass sich die Reihenfolge verändern soll von verschiedenen Spalten oder ganz viele anderen Dinge, die ich gerade gar nicht alle auswendig aufzählen kann. Da gibt es eine ganz nette Übersicht auf <css-tricks.com>, glaube ich. Die können wir auch mal in die Shownotes packen, wenn man da an der Flexbox interessiert ist.

Die Flexbox ist aber eigentlich nur, wie ich gerade sagte, für Zeilen gedacht. Also für das Layout einer Zeile. Für Spalten oder generell Grids gibt es auch schon was in der Pipeline, nämlich das CSS-Grid Layout-Module. Das ist aber noch sehr, sehr bleeding edge. Ich glaube der einzige Browser, der es momentan implemtiert hat, ist der IE 11.

Robert Glaser: Wow.

Till Schulte-Coerne: Das ist tatsächlich dann ein W3C-Standard?

Roman Stranghöner: Ja.

Till Schulte-Coerne: Ok. CSS3.

Roman Stranghöner: Ja. Und da hat man dann tatsächlich ein echtes – also man konfiguriert in CSS quasi das Grid. Also man braucht dann kein Framework eigentlich dafür.

Till Schulte-Coerne: Cool.

Roman Stranghöner: Das ist schon ziemlich gut. Und damit kann man dann – genau – natürlich das machen, was wir jetzt gerade als Herausforderung betrachtet haben.

Robert Glaser: Jetzt so als nicht-technische Herausforderung kann man vielleicht noch anführen, generell diesen Workflow: Wie erarbeitet man sich so eine Responsive Website, so ein Responsive Design? Man kann ja nicht mehr hingehen wie früher, in Photoshop was malen, was vielleicht einem Pixel-genauem Layout recht nah kommt oder sogar eins ist, das dann mit den Entscheidern und den Marketing-Kollegen abnicken und es dann implementieren. Das geht halt nicht mehr. Man kann das jetzt mal n nehmen, aber das sollte man halt nicht tun. Und dann n viele Pixel-genaue Layout malen, die alle abstimmen und die alle implementieren, sondern man muss sich halt irgendwie wahrscheinlich – also bei uns, wir haben uns dem recht untechnisch am Whiteboard genähert. Wir haben in verschiedenen Viewports bestimmte Komponenten identifiziert und isoliert – z.B. eine Hauptnavigation. Dann Teaser für bestimmte Sachen, für Inhaltselemente und ganze Inhaltselemente und haben dann stückweise einfach mal, wirklich mit dem Whitsboard-Marker und auf dem Whiteboard aufgemalt, wie die sich denn verhalten. Und was denn da so überhaupt rein gehört. Und das Styling haben wir erst viel weiter nach hinten gestellt. Und wenn man das grob abgestimmt hat, wie die sich verhalten und wo es hingeht, fällt es einem auch leichter, das hinterher abzumalen.

Roman Stranghöner: Es ist auch – es ist wirklich sehr hilfreich, wenn man sich vorher quasi so ein Inventar macht, von allen Dingen, die man so auf der Seite hat und welche quasi in anderen – also Komponenten, die in anderen Komponenten drin stecken und wie die sich quasi verhalten. Und man kann eigentlich, wenn man nicht unbedingt so Whiteboard-affin ist, kann man das ganze auch schon direkt im Browser machen und der Einfachheit halber nur mit grauen Blöcken arbeiten. Also wenn man so eine Hauptnavigation und ein Artikelintro und vielleicht noch irgendwelche Bilder und dann den Text und vielleicht unten eine Summary oder so hat, dann kann man das erstmal ganz grob als graue Box sich stylen und dann im Prinzip ausprobieren, was mit diesen Boxen passiert, wenn man das Browserfenster groß zieht, oder so. Je nachdem, was man da benutzt. Und das kann man halt erstmal mit grauen Boxen machen, ohne dass man irgendwas implementiert hat. Das kann man relativ schnell und das ist auch gar nicht so schwer. Die Herausforderungen kommen dann, wenn man die Boxen mit Leben füllt. Aber auch dafür gibt es ganz nette Hilfsmittel. Brad Frost – mal wieder – hat ein sogenanntes Pattern Lab entwickelt, wo man im Prinzip – also im Prinzip ist es so ein riesiger Living Styleguide, wo ich alle meine Komponenten, die ich so habe auf der Website, einzeln betrachten kann und dann im Prinzip auf verschiedenen Viewportgrößen testen kann. Und wenn man so ein Ding nimmt, um damit anzufangen, ist das auch schon relativ hilfreich, weil man am Ende im Prinzip nur noch die fertigen Komponenten, von denen ich weiß, dass sie sich vernünftig verhalten auf verschiedenen Viewportgrößen, die muss ich nur noch aneinander stecken und dann geht das alles ein bisschen leichter von der Hand.

Till Schulte-Coerne: Gut. Wir haben jetzt eine ganze Menge erfahren, denke ich mal. Habt ihr noch irgendwelche letzten Worte? Etwas abschließendes zum Thema? Oder nicht zum Thema?

Roman Stranghöner: Also ich finde das eine super Sache. Ich glaube, dass man damit auf jeden Fall auch anspruchsvolle Anwendungen auf mobile Endgeräte bringen kann und ich glaube auch, dass mobile Endgeräte sowieso eine viel größere und bedeutendere Rolle spielen werden in der Zukunft, als sie das bisher schon sind. Und es gibt mit Sicherheit noch einige technische Unzulänglichkeiten, die jetzt aber nach und nach – wie z.B. dieses picture-Element – aber nach und nach glaube ich jetzt technisch gelöst werden und dann glaube ich, dass man in zwei bis drei Jahren sehr, sehr coole Sachen damit bauen kann.

Robert Glaser: Genau. Machen, machen, machen.

Till Schulte-Coerne: Ja, sehr gut. Schönes Schlusswort. Vielen Dank euch beiden.

Roman Stranghöner: Gerne.

Till Schulte-Coerne: Und bis zum nächsten Mal.

Roman Stranghöner: Tschö.

Robert Glaser: Tschö.