» Publishers, Monetize your RSS feeds with FeedShow: More infos (Show/Hide Ads)
Am gestrigen Dienstag durfte ich auf der Jax in Mainz einen Vortrag über die Modularisierung von Webseiten halten. Ich habe beschrieben, dass ich Webseiten als eine Zusammenstellungen einzelner Module begreife. Ich zeigte, wie ich einen Klickdummy mit einzelnben HTML-Modulen aufbaue. Parallel dazu modularisiere ich mein CSS mittels Sass. Ein wichtiger Aspekt war auch der Blick auf das CSS. Ich habe OOCSS, SMACSS und BEM kurz vorgestellt, bewertet und meine Schlüsse daraus gezogen.
Mindestens die halbe Miete eines responsiven Projektes ist die richtige Herangehensweise. Im Rahmen einer internen Veranstaltung bei “Die Firma” in Wiesbaden richtete ich meinen Vortrag vor allem an Designer, Konzepter und Berater. Neben guten Gründe für responsives Webdesign präsentierte ich Ihnen die Konsequenzen, die ich für unsere Arbeit in Agenturen und für Kunden sehe.
Vor kurzem ist die zweite Auflage von Softwarequalität in PHP-Projekten
Der Hauptfokus des Buches liegt zwar auf PHP-Projekten, die zahlreichen begeisterten Kritiken sprechen aber auch davon, dass die Erkenntnisse generell für Softwareentwicklung gelten.
Für die zweite Auflage konnten wegen eines Zeitdrucks bei der Planung nur wenige Kapitel inhaltlich überarbeitet werden. Allerdings kam sogar ein neues Kapitel hinzu: Judith Andreesen, früher wie ich bei SinnerSchrader tätig und jetzt freie Beraterin, schreibt darüber, wie man “Testbasierte Entwicklung verkaufen” kann.
Interessant finde ich, dass Hanser offenbar jedem Buchkauf eine ebook-Version (in PDF-Format) mitgibt. Das hat mir schon bei dem empfehlenswerten Buch über Responsive Webdesign
Es ist sehr schwer, immer auf dem neuesten Stand in Sachen Webentwicklung zu bleiben. Mir helfen dabei Twitter, Newsletter und ein paar Linkseiten. Immer wieder aktualisierte Linktips finde ich einen sehr schönen Service. Hier sind ein paar interessante Quellen:
- CSSWeekly (Newsletter bestellen)
- HTML5Weekly (Newsletter bestellen)
- Web Design References (Newsletter bestellen)
- Twitter-Account von Christian Heilmann
- Twitter-Account von Smashing Magazine
- Open Web Platform Daily Digest (neu und vielversprechend)
Der australische Verlag Sitepoint ist jetzt auch mit einem Buch zu Responsive Webdesign auf den Markt gekommen: “Jumpstart Responsive Webdesign” von Craig Sharkie und Andrew Fisher. In gewohnt ansprechendem Layout wird das Thema auf knappen 140 Seiten abgehandelt. Dabei nutzen die beiden Autoren beispielhaft die Seite der Konferenz “Web Directions Sout 2012” zu Demonstrationszwecken. Das Buch kostet als ebook (in den Formaten PDF, epub und mobi) 19 Dollar.
Das Buch ist in sechs Kapitel aufgeteilt. Der Inhalt geht zur Hälfte um das Thema Responsive Webdesign (RWD). Der Rest geht um moderne Webentwicklung, Frameworks, Vorlagen usw. Die Kernherausforderungen von RWD werden meist ignoriert. Die wichtigsten Fragen werden nicht gestellt. Es gibt kaum echte Hilfestellung, Tips, Tricks. Ein Detail wie anpassbare Tabellen wird komplett ignoriert. Performance, unterschiedliche Layouttypen werden nicht erwähnt. Auch unterschiedliche Navigationstypen bleiben aussen vor.
Mich schockiert immer wieder, wieviele Autoren nicht sauber zwischen den Standards trennen können. Die Autoren packen Mediaqueries mal eben zu HTML5. Sie sind aber ein Designpart und gehören deshalb zu CSS (CSS3). Solche Fehler lassen in mir die Erwartungen immer schon gleich sinken.
Es wird zu Beginn des Buches viel Platz damit verschwendet, das alte Thema der relativen Schriftgrößen noch einmal zu behandeln. Ein Verweis auf drei gute Artikel hätte genügt. So verheddern sich die Autoren in Randthemen. Zudem wissen sie offenbar nicht, dass es mittlerweile Endgeräte gibt, deren Standardschriftgröße nicht mehr 16px sondern 20px ist.
Bei der Diskussion responsiver Bilder ignorieren die Autoren komplett, dass wir für Hintergrundbilder sehr viel weniger eine moderne Lösung benötigen, als für redaktionelle Bilder. Die Möglichkeit, mittels Media-Queries unterschiedliche Hintergrundbilder zuzuweisen, wird leider nicht erwähnt. Zumindest das Problem der Codereihenfolge wird kurz angesprochen.
Das Buch ist rein inhaltlich nicht schlecht, aber es ist nicht rund. Und es passt nicht zum Thema. Es ist mehr “moderne Webentwicklung in Schlaglichtern”. Das Buch kommt inhaltlich weder an das schmale Buch von Tim Kadlec noch an das umfangreiche von Christoph Zillgens ran.
Deutschland ist in Sachen Internet ein Entwicklungsland. Das liegt u.a. an unseren technikfeindlichen Eliten. Thomas Knüwer gibt viele Linktips, die das Grauen identifizieren helfen. Ich habe wenig Hoffnung, dass sich daran etwas in naher Zukunft ändern wird. Zu sehr schielen die meisten Innenpolitiker auf die Möglichkeiten der EDV, mehr über die Bürger zu erfahren. Und zu wenig Einfluss haben die Netzpolitiker der Parteien.
Dazu wird womöglich in Zukunft ein unsicherer E-Mail-Transportweg benutzt. Dabei ist es nicht so wichtig, dass wir Bürger die unsägliche DE-Mail nutzen. Es reicht, dass Behörden dies untereinander tun und somit ihre Übertragungen unsicher machen. Und um allem die Krone aufzusetzen wird jetzt einfach auf dem Verwaltungswege die Unsicherheit zur Sicherheit erklärt und rein formal ist alles okay.
Bei der medialen Vermittlung des Themas Internet konzentriert sich unsere Presse im Wesentlichen auf Risikoaspekte. So wird sich die ARD kommenden Mittwoch dem Identitätsdiebstahl widmen, die Frankfurter Allgemeine Sonntagszeitung widmete gestern zwei Seiten sexueller Belästigung von Kindern in Chats.
Ich warte noch auf ähnliche gross aufgemachte Berichte über die weitaus häufiger anzutreffenden positiven Aspekte digitalen Fortschritts. Wie wäre es mit neuen Arbeitsweisen, schnellere Kommunikation, einfacher Zugriff auf Informationen, örtliche Unabhängigkeit der Kommunikation u.v.m.. Aber da werde ich wohl noch länger warten dürfen. Skandalisierung war schon immer verkaufsfördernder, als richtige Information.
Es ist so traurig.
Ich durfte auf den JavaScript Days Anfang März in München zwei halbtägige Schulungen halten: eine über Responsive Webdesign und eine über CSS3. Am Morgen meines zweiten Tages – kurz vor der CSS3-Session – wurde ich vom Veranstalter kurz interviewt. Das Interview gibt es auf Youtube oder hier eingebunden.
In den letzten Monaten habe ich in einem größeren Projekt gearbeitet, in dem wir leider keinen Präprozessor einsetzten. Ich habe so ein halbes Jahr lang studieren können, welchen Spass die Arbeit mit einem Präprozessor machen könnte, wie effektiv man damit arbeiten könnte. Nun versuche ich gerade meine gesammelten Ideen zur Effektivierung mittels Sass in die Tat umzusetzen.
Eine Arbeit, die mir Sass (nur mit diesem Präprozessor kenne ich mich aus) abnehmen soll, ist die Verteilung von IE-spezifischem CSS. Transparenz mittels rgba, Boxschatten und ähnliche CSS3-Eigenschaften kann man mittels alter IE-Filter nachahmen. Doch möchte ich den dafür notwendigen Code in spezielle CSS-Dateien für IE 8 und älter (oldIE) ausgelagert wissen. Leider bietet mir Sass so etwas nicht direkt an. Wenn man aber sein Projekt passend aufbaut, dann klappt das auch mit dem alten IE.
Eine Frage des Aufbaus
Die Lösung des Problems liegt im Aufbau meines Projektes. Ich mache mir den @import-Befehl zu nutze. Entscheidend ist aber die Variable zu Beginn des Files. Sie definiert, ob das Stylesheet Code für oldIE ausgeben soll oder nicht.
Ich importiere dann zwei Arten von mixins, die für alle gültigen und diejenigen, die Code für “Legacy-Browser”, also die alten IE beinhalten. Danach importiere ich alle einzelnen Codeschnipsel für meine Module.
Das Stylesheet für die alten IE ist im Normalfall als Ergänzung zu dem anderen Stylesheet zu sehen. Im Normalfall deshalb, weil ich auch bei intensiver Arbeit mit Mediaqueries eine komplette Alternativversion für oldIE schaffen könnte – aber das ist ein anderes Thema.
Als Ergänzung zum allgemeinen Stylesheet füge ich also nun eines für die alten IE-Versionen hinzu. Es hat beispielsweise folgenden Aufbau:
Die wichtige Variable ist diesmal auf true gesetzt. Bei den importierten Partials könnte man nun entscheiden, welche Regeln für den IE eingefügt werden sollen und welche nicht. Denn eine unnötige Dopplung gilt es zu vermeiden.
Abfrage in den Mixins
Nachdem nun die wichtige Variable $isoldIE eingeführt wurde, nutze ich sie in einigen Mixins. Mittels @if .... @else lasse ich die Mixins unterschiedlichen Code ausgeben.
Die unterschiedlichen Ausgaben kann man schnell und einfach mittels Sassmeister ausprobieren. [Es gibt übrigens auch ein Bookmarklet für Sassmeister, das man auf Gist-Seiten aktiviert und dann mitsamt dem Gist zu Sassmeister gelangt.]
Opera hat heute eine mittelgroße Bombe gezündet: künftige Versionen werden nicht mehr durch die eigene Presto-Engine, sondern die Webkit-Engine und die JavaScript-Engine V8 angetrieben. Genauer gesagt wechselt Opera zu Chromium.
Als ich die Nachricht las, war ich hin- und hergerissen. Ist das nun eine gute oder schlechte Nachricht? Auf alle Fälle war es unterhaltsam, Twitter zu beobachten. Auch einige interessante Blogbeiträge wurden geschrieben. Ich finde es noch immer interessant, wieviele positive Betrachtungen Presto bekommen hat. Chris Heilmann stilisierte Opera zur ultimativen Testplattform, zum “Crockford unter den Browsern“.
Lobeshymnen
Die Lobeshymnen mögen alle ihre Berechtigung haben. Vielleicht bin ich zu sehr pragmatisch denkend. Vielleicht liegt es aber auch daran, dass ich im Gegensatz zu den vielen Lobhudelern auch praktische Arbeit im Web verrichte und nicht nur Schulungen und Vorträge mache. Denn für mich hat Opera bislang keine praktische Bedeutung.
[Anmerkung: Dieser Absatz scheint genügend Raum für Missverständnisse zu bieten, wie die Reaktion von Chris Heilmann in meinen Kommentaren zeigt. Ich möchte weder arrogant noch abwertend verstanden werden, einfach nur neutral beschreibend. Wie ich in meinen Kommentaren unten ausführe geht es mir nur um die Diskrepanz zwischen Theorie und Praxis, die besteht und bestehen muss. Und in meiner Praxis habe ich kein Budget und keine Zeit für Opera. Die könnte ich mir nehmen, wenn ich mehr forschen würde. Tue ich aber nicht. Nur das ist mein Punkt.]
Natürlich habe auch ich Webseiten immer mal wieder in Opera betrachtet. Doch für Kunden war dieser Browser uninteressant. Opera ist ein Nischenbrowser. Testen in Browsern bedeutet Aufwand. Dieser will bezahlt werden. Doch Kunden wollen nicht für Tests in Browsern zahlen, die nur in homöopathischen Dosen in ihren Statistiken auftauchen. Für mich waren zudem Tests immer schwer, weil es eigentlich keine Dokus über Bugs gibt. Und die immer wieder behauptete Unfehlbarkeit kaufe ich nicht.
Mobil
Auch die Info, dass Opera auf mobilen Endgeräten bedeutend ist, interessiert meine typischen Kunden nicht. Denn für Deutschland gilt dies nicht. Vielleicht für Afrika, Russland oder Asien. Aber nicht für Deutschland. Da dominiert Webkit. Und in den Gedanken der Verantwortlichen gibt es sowieso hauptsächlich iPhone und iPad.
Entwickler scheinen da nicht anders zu funktionieren. Das haben wir gemerkt, als Mozilla und Opera verkündeten, auch das “-webkit”-Prefix in ihre (mobilen) Browser zu implementieren. Denn leider waren immer mehr Entwickler in den letzten Jahren zu faul, CSS3 für alle Browser zu schreiben. So wie wir früher für den IE “optimierten” kümmerten sich viele Entwickler nicht mehr um Nicht-Webkit-Browser. Entwickler schufen aus Faulheit und Ignoranz einen Quasi-Standard. Das kann man gerne kritisieren, aber es ist ein Fakt mit dem wir umgehen müssen.
Apple
Obwohl Apple schon länger kein für mich sichtbares Engagement bei Webkit mehr zeigt, so hat doch gerade diese eine Firma den Boden für die starke Bedeutung der Engine bereitet. Apple verbietet die Installation einer anderen Browserengine auf seinen iOS-Geräten. Apple kommt mit dieser Haltung seltsamerweise durch. Microsoft wäre mit einer ähnlichen Haltung vor diverse Gerichte gezogen worden. Die Konsequenz ist aber, dass auf dem kommerziell so wichtigen iOS nur Webkit läuft. Und dank der Marktmacht von Google wird Chrome sowohl auf dem Desktop, als auch auf Androidgeräten beliebter.
Viele Projekte
Webkit treibt zudem viele weitere Projekte an, wie node.js oder Phantom.js. Neben Adobe arbeitet sogar Microsoft ein wenig an der Weiterentwicklung der Browserengine mit. Neben den grossen drei Microsoft, Mozilla und Webkit konnte Opera auf dem Desktop einfach nicht reüssieren und wurde von iOS ferngehalten. Ich finde den Schritt mutig und konsequent.
Gut oder schlecht?
Ist es nun gut oder schlecht, dass Presto nicht weiterentwickelt wird?
Ich denke, es ist eine gute Entscheidung. Die Existenz von Opera auf dem Desktop war für mich als Entwickler und für meine Kunden quasi egal. Meine Erwartung ist nun, dass die Weiterentwicklung von Webkit noch schneller vorangetrieben wird. Meine Hoffnung ist, dass sich die Unterschiede zwischen den unterschiedlichen “Geschmacksrichtungen” von Webkit nach und nach verschwinden.
Chris Heilmann und andere heben hervor, dass der Wettbewerb für die Weiterentwicklung des Web ganz wichtig sei. Die Vergangenheit hat uns exakt das gelehrt. Da hat Chris recht. Denn erst durch Mozilla wurde Microsoft aus dem Schlaf gerissen und zur Innovation gezwungen. Ich behaupte sogar, dass nur durch Mozilla das moderne Web wie wir es geniessen möglich geworden ist. Wenn ich Recht habe ist das ist umso spannender, weil Opera schon lange vor Mozilla existierte. Doch Opera hatte nie den entscheidenden Einfluss, den Mozilla hatte. Ich spreche dabei nicht von der Ansicht von Entwicklern, sondern vom Endanwender. Wir können froh sein, wenn dieser den Browser kennt, mit dem er surft.
Fortschrittshemmnis Microsoft
Ich freue mich darauf, dass dank Opera nun noch mehr Entwickler an Webkit arbeiten. Innovation passiert hier durch die unterschiedlichen Firmen, die alle ihre eigene Agenda verfolgen. Bleiben noch Microsoft und Mozilla als Wettbewerber. Technisch ist dabei nur Mozilla interessant. Denn obwohl Microsoft offenbar nun endlich auch richtige Browser herstellen will, sind sie doch einfach zu langsam. Zudem sind Microsoft-Browser im wesentlichen in Firmen und Behörden wichtig. Doch da sprechen wir nicht von der neuesten Version. Wir sprechen auch nicht von einer Umgebung, die alle sechs Wochen ein wichtiges Update der Rendering-Engine erlauben würde.
Webkit und Mozilla können also so schnell voranschreiten, wie sie wollen. Wir als Frontendentwickler werden leider immer mit uralten Browsern kämpfen müssen. Wir werden sicher keine monolithische Browserlandschaft bekommen.
Ein paar interessante und lesenswerte Betrachtungen zur Causa Opera:
- Opera and WebKit: a personal perspective (Bruce Lawson)
- I will miss the “Douglas Crockford of browsers” (Chris Heilmann)
- The WebKit Culture & Web Rendering Engine Diversity (Robert Nyman)
- Jake Archibald auf Google+
- WebKit is the jQuery of Browser Engines (John Resig)
Vom 18. bis 20. März findet mal wieder ein PHP-Summit in München statt. Die im wesentlichen von den PHP-Größen Sebastian Bergmann, Stefan Priebsch und Arne Blankerts bestrittene Veranstaltung bietet 18 Workshops und zwei Vorträge. Normalerweise drehen sich die Workshops um PHP, erfreulicherweise öffnen sich die Veranstalter thematisch. Deshalb darf ich einen halbtägigen Workshop zu Responsive Webdesign anbieten. In dreieinhalb Stunden werde ich einen Einblick in das Thema geben, Beispiel zeigen und Problemfelder identifizieren. Mal schauen, wieviele der Teilnehmer schon praktische Erfahrung mit Responsive Webdesign sammeln durften.
- Weenudge.com ist eine kleine, übersichtliche Linkliste. Inhaltliches Ziel ist, den (potentiellen) Kunden von gutem Webdesign zu überzeugen. Also, einfach mal die Links abgrasen und dabei ausblenden, dass die Schrift zu klein ist und alles nach einer Flashseite des Jahres 2002 ausschaut.
- Dave Methvin schreibt im jQuery-Blog über die nähere Zukunft des Projektes. Durchaus lesenswert.
- Tommi Kaikkonen hat eine interessante Testseite für CSS-Columns aufgesetzt. Man kann mittels JavaScript die Spalten ein- und ausschalten, ebenso Blocksatz und Silbentrennungen. Der Inhalt der Seite ist netterweise kein Blindtext, sondern sehr lesenswerter, informativer Inhalt.
- Andrew Searles schreibt leidenschaftlich gegen Slider an und versucht dann zu erklären, wie man sie erträglich realisiert.
- Die Animation unterhalb des Anmeldeformulars bei CSS-Weekly ist nett gemacht. Die Figuren jubeln sogar, wenn man sich angemeldet hat!
- The Accessibility Project ist mal wieder ein Versuch, Barrierefreiheit in den Köpfen der Entwickler, Designer und Entscheider zu verankern. Diesmal ist es “community driven”. Warum man für diese Seite das in Sachen Zugänglichkeit nicht wegweisende Bootstrap als Basis nutzt, bleibt das Geheimnis der Macher. Ich wünsche ihnen viel Glück, schaue aber sicher häufiger im Accessibility-Blog von Yahoo vorbei. Das hat schon inhaltliche Masse.
Robert Lippert hat in seinem Artikel “Wer hat Angst vor Usability?” ein Plädoyer für eine bessere, nutzerorientierte Usability gehalten. Er ging von der These aus, dass oft nicht die Bedürfnisse des Nutzers im Mittelpunkt stehen, sondern die des Auftraggebers oder des Systemintegrators. Zu Beginn seines Artikels wies Robert kurz darauf hin, dass Frontendentwicklung oft nicht als eigene, anspruchsvolle Dispziplin anerkannt wird – insbesondere von Backendentwicklern. Ich beleuchte an gleicher Stelle – im Blog von Mayflower – diesen Aspekt aus Sicht eines Frontendentwicklers genauer.
Responsive Webdesign ist sicherlich das größte Thema der letzten zwei Jahre im Bereich Frontendentwicklung. Endlich setzt sich die Erkenntnis durch, dass die Stärke des Webs in dessen Anpassungsfähigkeit liegt. Doch wir haben alle zu lange diese einfache Wahrheit ignoriert. Wir müssen neue Sichtweisen und Herangehensweisen lernen. Und wir müssen lernen, unsere Umgebung mit neuen Augen zu sehen.
Viele Artikel und bislang nur ganz wenige Bücher haben sich dieser Aufgaben angenommen. Webkraut Christoph Zillgens hat das erste deutschsprachige Buch zum Thema
Sein Stil ist klar, schnörkellos und sehr gut zu lesen. Angesichts der thematischen Breite des Themas ist es sehr wohltuend, dass Christoph die Einzelaspekte nicht unnötig aufbläht. So bekommt man alle wesentlichen Informationen und hat ein breites Themenspektrum.
Themen wie “anpassungsfähige Bilder” gibt es in kompakt und ausführlich. Im ausführlichen Kapitel diskutiert Zillgens die Haken und Ösen der Bildeinbindung. Am Anfang des Buches handelte er das Thema pragmatisch kurz ab. So kann man anfangs schnell mit einem ersten Erfolg in das Thema eintauchen um dann Schritt für Schritt zu lernen, dass die Thematik wesentlich komplexer als angenommen ist. Ein in meinen Augen sehr guter didaktischer Kniff.
Sehr gut finde ich, dass in dem Buch auch Formulare sowie die Performance von Webseiten diskutiert werden. Formulare sind als Interaktionsschnittstelle sehr wichtig und der falsche Umgang mit zusätzlichen Bildern und Skripten kann zu einer Performancebeeinträchtigung führen.
Weitere Themen sind “reaktionsfähige Typographie”, Mediaqueries, mobile Navigationen. Sehr wichtige Kapitel sind in meinen Augen die über die “Gestaltungsphase” und über den notwendigen neuen Workflow. Hier hat der Autor weiter gedacht, als einfach nur ein paar Techniken zu beschreiben. Das finde ich sehr gut. Denn responsive Webdesign fordert uns nicht nur rein technisch oder gestalterisch heraus. Unser Workflow, unser Annahmen und Erwartungen müssen sich ändern.
Das Buch ist wunderschön gestaltet und macht deshalb nicht nur inhaltlich sondern auch formal viel Spass beim Lesen. Sehr gut ist die Bündelung von gedrucktem Buch und ebook. Noch besser wäre es, könnte man nur das ebook kaufen und das noch zu einem attraktiven Preis. Doch die deutschen Verleger sind in diesem Punkt leider noch weit hinter ihren amerikanischen und britischen Kollegen. Der Hanser Verlag bietet zwar das Buch als ebook an (was in diesem Falle nur ein PDF ist), verlangt aber den Preis des gedruckten Buches. Warum sollte man nur ein PDf kaufen, wenn man ein gedrucktes Buch und ein PDF zum gleichen Preis erwerben kann?
Für mich ist dieses Buch das aktuell beste und umfassendste Buch zum Thema, auch im Vergleich zu den jeweiligen amerikanischen Büchern. Es ist seinen Preis wert.
WebPlatform.org ist eine relativ neue, offene Entwicklercommunity mit dem Ziel, eine umfassende Dokumentation für Webentwickler, unabhängig von Marken, Browsern oder Plattformen, aufzubauen. WebPlatform.org wird vom W3C zusammengerufen und durch die Unterstützung der Web Platform Stewards möglich gemacht, darunter sind alle Browserhersteller, Nokia und Adobe.
WebPlatform.org ist ein Wiki, und als solches lebt es von aktuellem und möglichst umfassendem Inhalt. Um die Dokumentation schnell gemeinsam auf- und auszubauen gibt es sogenannte Doc Sprints. Bei diesen Dokumentations-Hackathons gibt es eine Einweisung in die Mechanik des Wikis sowie Inspiration und Ansatzpunkte zum Losdokumentieren.
Hierzu stehen Euch versierte Experten von den Web Platform Stewards bzw. aus den Reihen der Community mit Rat und Tat zur Verfügung. Neben der Arbeit fürs Gemeinwohl soll der Spass nicht zu kurz kommen. Und selbstverständlich ist auch für das leibliche Wohl gesorgt. Es gibt eine kleine Party, Giveaways und das Netzwerken kommt ebenfalls nicht zu kurz.
Nach den beiden ersten Veranstaltungen dieser Art bei Adobe in San Francisco und zuletzt bei Google in Mountain View findet am 8. und 9. Februar 2013 der erste europäische Web Platform Doc Sprint in Berlin statt. Die Location wird Mitte Januar nach den tatsächlichen Anmeldungen ausgewählt. Es sollfür möglichst ideale Verhältnisse gesorgt werden.
Wer nun also Lust bekommen hat, an der Dokumentation der Webtechniken aktiv mitzuwirken, der sollte sich bei Eventbrite anmelden – und bei Lanyrd seine Teilnahme bekanntgeben.
Vom 6. bis 8. März 2013 finden zum dritten Mal die JavaScript Days in München statt. Veranstaltet wird das Trainingsevent wird vom Entwickler Magazin in Kooperation mit der Entwickler Akademie.
Diesmal darf auch ich den versammelten (JavaScript-)Entwicklern aktuelle Themen in kompakter Form präsentieren. Meine beiden Workshops drehen sich um “Responsive Webdesign” und “CSS3″. Ich habe vor, einiges Live und kleinen Codebeispielen zu zeigen. Neben meinen Themen wird es auch um Web-Apps, Sencha Touch, Funktionen & Scopes, Prototypen & Closures, Ext JS, Three.JS, Canvas, Git, CouchApps, jQuery Mobile, Node.js u.v.m. gehen.
Innerhalb von drei Tagen werden 18 Workshops von bekannten Entwicklern wie Thorsten Rinne, Kore Nordmann und Jakob Westhoff gehalten.
Ende letzten Jahres interviewte mich der Journalist Henry Steinhau für das Annual Multimedia. Er schrieb einen längeren, sehr lesenswerten Artikel über “Responsive Webdesign” und wollte ein paar Statements von mir. Meine Antworten waren teilweise recht lang, sodass ich darum bat, das Interview abdrucken zu dürfen. Anbei also das von Herrn Steinhau leicht überarbeitete schriftliche Interview, das er auch in seinem Blog veröffentlichte.
Was meint „Responsive Design“?
Responsive Webdesign heisst nicht mehr und nicht weniger, als dass sich die Webseite dem Nutzer anpasst und nicht umgekehrt. Es ist die Umsetzung der Eigenarten und Stärken des Internet, mit den jeweiligen Inhalten variabel umzugehen, sie den Geräten und Nutzungssituationen entsprechend angepasst darzustellen. Man darf Responsive Design jedoch nicht auf mobiles Web reduzieren, da es unter anderem auch die Fenstergröße stationärer Internet-Browser berücksichtigt.
Worauf müssen sich denn die Web-Designer Ihrer Meinung nach hinsichtlich „Responsive Design“ gefasst machen?
Wie gesagt ist Responsive Webdesign nur die lange erwartete Umsetzung der Eigenschaften und Stärken des Internet in einem Designansatz. Theoretisch wissen wir seit Jahren, dass das Internet flexibel ist. Aber viele Designer und vor allem sehr viele Auftraggeber haben diese Tatsache noch immer nicht richtig begriffen.
Es ist für viele offenbar schwer zu akzeptieren, dass eine Webseite auf unterschiedlichen Bildschirmen anders aussehen kann. Die Auswahl an möglichen Endgeräten, Bildschirmauflösungen und Browsern ist heute schon sehr hoch, die technischen Fähigkeiten der Browser und Endgeräte sind bereits jetzt sehr vielfältig. Diese Vielfalt wird in den nächsten Jahren noch mehr zunehmen. Kein Designer, kein Entwickler, kein Kunde kann deshalb ernsthaft alle Möglichkeiten testen und so lange bearbeiten, bis alle Endgeräte identische Ergebnisse zeigen.
Für Designer und ihre Auftraggeber ist also die größte Herausforderung „loszulassen“. Sie müssen akzeptieren, dass sie „nur“ Hinweise geben können, wie etwas aussehen soll. Abweichungen – auch mittelgroße – müssen sie als Ergebnis eines nicht enden wollenden technischen Diversifizierungsprozesses akzeptieren.
Müssen sich Entwickler und Programmierer für das Responsive Design mehr Gestaltungskompetenzen aneignen – oder die Designer mehr Codier-Fähigkeiten?
Vor allem müssen alle Beteiligten lernen, frühzeitig und gleichberechtigt miteinander zu kommunizieren. Es war schon immer ein Fehler, dass Entwickler erst am Ende die Ideen anderer umsetzen sollten, ohne jemals vorher gehört worden zu sein. Bei Responsive Webdesign sind allerdings tatsächlich technische Kompetenzen gefragt, die Designer nicht so einfach erwerben werden wollen. Es bedeutet aber auch für sehr viele Entwickler eine intensive Fortbildung in Richtung Gestaltungswissen. Ich bin mir relativ sicher, dass dies viele Entwickler und Agenturen jedoch nicht erwerben wollen.
Könnte der Einsatz von Responsive Design eine Entwertung der Gestalter-Leistungen zur Folge haben – weil es den Gestaltern den Aufbau, das Layout einer Webseite ein Stück weit aus der Hand nimmt?
“Webseiten sind keine Gemälde”, diesen Titel habe ich vor fast genau acht Jahren einem Artikel über Webdesign gegeben. Der war damals wie heute richtig. Wer sich als Web-Designer als Künstler betrachtet, der hat schon verloren. Kunden interessieren sich nicht für künstlerische Webseiten. Sie wollen benutzbare Webseiten. Je künstlerischer sich ein Designer austobt, desto unbenutzbarer werden die Seiten. Das fängt bei kontrastarmen Schriften an und endet bei unverständlicher Navigation.
Eine Webseite will benutzt werden. Dafür ist sie da. Sie soll auch attraktiv aussehen, keine Frage. Aber sie ist kein Kunstwerk. Eine Entwertung der gestalterischen Leistungen kann ich jedoch nicht sehen. Zudem müssen Designer bei Responsive Webdesign viel komplexer denken, als bislang. Sie müssen nicht nur ein Design erstellen, sondern mehrere – das wertet ihre Arbeit eher auf.
Die eigentliche Herausforderung für die Designer liegt meines Erachtens in der frühzeitigen und intensiven Kommunikation ihrer gestalterischen Ansätze und Vorschläge. Dazu müssen im übrigen alle Beteiligten in der Lage und Willens sein.
Was bedeutet das Konzept des Responsive Design Ihrer Ansicht nach für Werbebranche und Werbetreibende?
Es bedeutet, dass sie endlich die Eigenarten des Webs akzeptieren und begreifen. Und es bedeutet, dass sie sich Gedanken über die passenden Werbeformen machen müssen. Vor allem aber müssen auch die Werbetreibenden endlich mal fähige Entwickler beschäftigen, die guten Code ausgeben. Mit den aktuellen Codemonstern, aus denen ihre Banner und Fenster bestehen, kann man in anspruchsvollen Layouts wenig anfangen.
Welche technischen Hürden gibt es beim Responsive Webdesign?
Die wegweisende, zum Standard avancierende Methode für Responsive Design sind derzeit eindeutig die „Media Queries“. Dies sind Codes, die in Form vorprogrammierter Abfrage- und Einstellprozeduren die Anpassung der Webinhalte auf das Gerät beziehungsweise die Browser/-Fenster steuern. Bestimmte Browser, speziell ältere Versionen des nach wie vor weit verbreiteten Internet Explorer, können jedoch nicht mit Media Queries arbeiten.
Das ist einerseits nicht weiter schlimm, weil diese Browser sowieso nur auf dem Desktop existieren und keine Umformatierung für sehr kleine Displays benötigen. Aber leider stehen sie auch im Weg für den sogenannten „mobile first“ Ansatz.
Dabei wird ein Layout erst für kleine Displays entworfen und ihm dann peu à peu Komplexität hinzugefügt. Möchte man diesem Ansatz folgen, muss man wegen der alten Internet Explorer (IE) auf JavaScript zurückgreifen oder viel Arbeit in komplexe und IE-spezifische CSS- Dateien investieren.
Viel schlimmer ist allerdings der Umgang mit Bildern und Videos. Aktuell können Browser keine umgebungsabhängigen Bilddateien laden, also Bilder und Filme, die eine dem Endgerät passende Größe und damit auch “Gewicht” haben. Das wird sicher bald kommen.
Aber wenn die populären Browser Chrome, Firefox, Safari und Opera dies in vielleicht zwei Jahren prima beherrschen, wird es noch immer etwa 50 Prozent Nutzer geben, die den Internet Explorer in unterschiedlichen Versionen einsetzen und die dann damit nicht umgehen können. Leider wird der Explorer nur alle paar Jahre modernisiert und verschwinden alte Versionen nur sehr langsam.
Ich fürchte, dass wir in zwei oder drei Jahren eine noch viel größere Schere zwischen sehr fähigen Browsern und dem Gros der Internet Explorer sehen werden. Das Fatale dabei ist, dass die Kunden, die gerne technisch anspruchsvolle Seiten haben möchten, fast ausnahmslos alte Internet Explorer nutzen. Und das wiederum spricht dafür, dass die Schere zwischen Anspruch und Wirklichkeit noch weiter aufgehen könnte.
Ist „Responsive Design“ endlich mal ein Schlagwort, dass aus Nutzersicht gedacht ist – oder doch wieder primär den Fantasien der Werbewirtschaft entspricht?
Responsive Webdesign ist weniger ein Schlagwort als ein Designansatz. Er hat seine Berechtigung, macht aber weder allein seelig noch ist er der Weisheit letzter Schluss. Aber er kann endlich das lange gehegte Versprechen des flexiblen Internet einlösen. Die Werbewirtschaft ist für eine solch gute Idee mit Sicherheit nicht verantwortlich. Ich bin mir auch nicht sicher, ob die Werbetreibenden die Tragweite, die Bedeutung und die Chancen des Responsive Design bislang begriffen haben.
Unter der verbindenden Frage “Welchen Tipp hast du für Webworker, die
gerade neu im Beruf anfangen oder eine Ausbildung machen?” findet ihr heute bei den Webkrauts eine bunte Sammlung an Empfehlungen.
Da ich heute keine Zeit oder Lust auf Recherche habe, empfehle ich jedem Interessierten, einen eigenen Blick in die von mir besuchten Adventskalender zu werfen:
Bei den Webkrauts beschreibt Nicolai Schwarz heute, wie er den Adventskalender visualisiert und umgesetzt hat. Bei 24ways rantet Andy Clarke ein wenig über Preisverhandlungen. Der MDN-Adventskalender entführt uns zu einem vor Kurzem viel zitierten Artikel von Anil Dash. Der UXMas-Kalender präsentiert uns das Video eines Vortrags über Sitenavigation.
Bei den Webkrauts schreibt Kerstin Probiesch über OpenAccess. Anna Debenham schreibt bei 24ways über den Browser der Spielkonsole Wii U. Der MDN-Kalender führt uns zu einem jQuery-Plugin, das die Nutzung der Webcam mittels navigator.getUserMedia erleichert.
Der Performance-Kalender widmete sich gestern A/B-Tests im Zusammenhang mit Frontend-Optimierungen. Im UXMas-Kalender schreibt Derek Featherstone über einen alternativen Ansatz zu UX. Das Kalendertürchen von Mayflower steht heute im Zeichen von MongoDB. Bei Digitpaint geht es heute um die Drag and Drop-API von HTML5.
Bei den Webkrauts schreibt Konstantin Käfer heute über Backbone.js. Bei 24ways beschreibt Nathan Peretic einen Ansatz, wie wir mit horizontalem Blättern das Internet ein bischen mehr nach Printpublikation aussehen lassen können – wenn wir unbedingt wollen. Der MDN-Kalender entführt uns zu einem Dienst, der den Umgang mit extrem grossen (und detailgetreuen) Bildern ermöglicht. Im Performance-Kalender zeigte gestern Jake Archibald, wie man mittels Canvas Schneeflocken erzeugen kann. Auch bei Mayflower geht es heute um Canvas, in diesem Falle um “HTML5 Canvas mit KineticJS“. Bei Digitpaint kümmerte man sich gestern um HTML5-Formularelemente.