<picture>
        <source src="high-res.jpg" media="min-width: 800px" />
        <source src="mobile.jpg" />
        <!-- Fallback content: -->
        <img src="mobile.jpg" />
</picture>

→

→

In Did we lose track of the big picture? malt Thierry Koblentz ein aus seiner Sicht düsteres Bild der Dinge:

I’m afraid to say we’ve lost a few battles. As of today:

• “responsive design” beats “progressive enhancement”,
• “multi-device frameworks” beats “basic core support”,
• “screen-readers” beats “text-based browsers”.

Koblentz’ Ansatz ist dabei sicherlich, mit Core Support und Plain old Semantic HTML (POSH) so viele User wie möglich zu erreichen, anstatt sich auf möglichst moderne Browser zu konzentrieren. Responsive Design ist für ihn dabei eins von drei Sympthomen, dass wir sozusagen in die falsche Richtung surfen.

Zu behaupten, responsive webdesign sei reiner Technologietrend und man würde zwangsweise den User dabei aus dem Auge verlieren, ist schon starker Tobak. Das soll aber natürlich gerade nicht passieren, da hat er schon Recht. Wie wir ja auch schon unfreiwillig festgestellt haben, landet man ganz schnell beim User-Agent-Sniffing. Schon graceful degradation ist schwer umsetzbar, progressive enhancement ist da schon zur Tür raus.

Ein anderes Beispiel. Chris Mücke vertritt die Position des konservativen Gestalters, der zunächst mal komplett in Frage stellt, dass responsives Design überhaupt schon funktioniert:

Noch immer fehlt für mei­nen Geschmack ein wirk­lich detailiertes Vor­zei­ge­bei­spiel. Der Grad an Details sinkt erschreckend, wenn man seine Inhalte für einer Armee von Dis­plays funk­tio­nie­ren las­sen möchte. Gut ist, dass die Mär von Cross-Browser Pixel­perfek­tion end­lich stirbt. Gut ist, dass Responsiv der noch kleinere gemein­sa­mer Nen­ner ist. Schlecht ist: Varia­tion bei Gestal­tung sinkt noch schnel­ler, als zur Hoch­zeit des Minimalis­mus. Klar wird nie­mand mehr Details ent­wi­ckeln, die nur für einen Bruch­teil poten­ti­el­ler Nut­zer funktioniert. Sowas ist nur kurz­sich­ti­ger Fort­schritt.

Im Grunde sind wir uns da einig: responsive webdesign ist noch nicht bereit für die große Masse. Man muss sich allerdings fragen lassen, warum man nicht selbst dazu in der Lage ist, das wirklich detaillierte Vorzeigebeispiel zu bauen. An seinem Raster zu arbeiten und zu war­ten, bis auch Desk­tops Dis­plays mit DPI Wer­ten jen­seits der 300 bekom­men ist ggf. auch nicht der innovative Weg. Vielleicht liegt man als Gestalter da sogar noch richtig, als Entwickler wird man diese Dinge ausprobieren müssen, solange sie noch the next big thing sind. Das hat zunächst mal nichts mit Wer­bung für die eigene Dienst­leis­tung zu tun, sondern ist eben eine Dienstleistung selbst, sich mit dem Fortschritt auseinanderzusetzen.

Some rights reserved by x-ray delta one.

Zunächst mal begegnet man responsiven Lösungen ja eher im Bereich Agenturseiten, Blogs und Landingspages, vielleicht mal ein—zugegeben—großes Webdesign-Magazin, eher konservative Bereiche des Webs, also die großen Portale oder Newsseiten halten sich bis dato noch zurück. Einzig die Webseite des Boston Globe setzt voll auf responsives Design. Wo liegen also die Probleme?

Problem numero uno ist natürlich die mangelhafte Browserunterstützung. Wirklich große Webseiten haben sicherlich noch lange nicht alle die IE6-Unterstützung gedroppt. Javascripte die bei den alten Browsern nachhelfen gibt es, aber sie kommen in Hochlastumgebungen eher nicht in Frage. Und ebenso dort, wo Zugänglichkeit Vorraussetzung ist.

Unschön auch die Sachen mit den Bildern. Hier spielen zwei Faktoren einen Rolle: der Wunsch nach qualitativ hochwertigen Bildern und gleichzeitig soll bspw. dem iPhone-Nutzer eigentlich kein 1080p-Image zum Download zugemutet werden, wo es doch auf seinem Smartphone auf 300px herunterskaliert wird. Natürlich gibt es Lösungen, die entweder auf Javascript basieren oder auch auf CSS, aber gerade für CMS-basierte Seiten mit angeschlossener Bildverwaltung stellt es ein nicht triviales Problem dar, Bildobjekte entsprechend anders einzubetten, eine Einbettung via CSS Hintergrundbilders oder gar :before stellt eine unlösbare Aufgabe dar.

Der nächste große Blocker, ich wiederhole mich mit den Jahren, ist natürlich wieder Bannerwerbung. Bannerwerbung, mit ihrer kindischen Fixierung auf Pixelmaße, hat fluide Seiten genauso verhindert, wie sie jetzt dem responsiven Design im Wege stehen. Es ist aber auch viel verlangt, nach 10 Jahren haben sich die Bannerschrauber eben erst daran gewöhnt, dass Webseiten zentriert dargestellt werden wollen, nun wollen die doofen Seiten auch noch den ungenutzten Raum belegen, in der bisher nur Skyscraper und sticky ads herumlungerten. So kann man allenfalls auf Ads innerhalb des Contents hin- und her verschieben, bis sich die Werbung der Bildschirmgröße an (ohne den ganzen Bildschirm ausfüllen zu wollen), darauf werden wir weitere zehn Jahre warten müssen.

Wenn wir uns über die Nutzung des Webs mit mobilen Endgeräten Gedanken machen, sehen wir als Entwickler und Programmierer oft die technischen Beschränkungen die im mobile web herrschen. Kleine Bildschirme, niedrige Verbindungsgeschwindigkeiten, beschränkter Download, aussetzende Verbindungen, Touchbedienung und so fort. Für alle diese technischen Probleme lassen sich technische Lösungen finden. Diese haben, da sich der Mobilmarkt rasend entwickelt (5 Euro ins IT-Phrasenschwein) und vor allem die Technik dahinter, eine relativ kurze Halbwertzeit.

Hinter diesen Einschränkungen liegt aber etwas, was ich als die mobile Nutzungssituation bezeichnen würde und diese ist viel festgelegter als die Technik selbst. Beispielsweise können wir davon ausgehen, dass ein mobiler Nutzer viel weniger Zeit hat, als ein Desktop- oder Sofasurfer. Das klingt wie eine banale Feststellung, aber hat doch trotzdem einen großen impact. Wir versuchen ja auch schon, wieder mit technischen Mitteln, auf eine solche Situation einzugehen (Ladegeschwindigkeit einer Seite), aber was nutzt das wirklich, wenn dann kilometer lange Bleiwüsten schnell aus? Außerdem ist die mobile Nutzungssituation durch weit mehr Eigenschaften gekennzeichnet, als der fehlenden Zeit. Einhandbedienung könnte dazu gehören, örtliche Beweglichkeit während der Nutzung, Einflüsse durch die Umgebung etc.

Hierauf müssen aber IMHO nicht nur Gerät und Website reagieren, sondern eben auch der Inhalt, soweit meine These. Beispiel: ein Nachrichtenportal sollte seine Artikelseiten vielleicht nicht als Einseiter oder auf vielen Seiten verteilt anbieten, sondern in drei inhaltlichen Ausbaustufen. Titel und Teaser für Indexseiten, kurze zusammenfasende Version eines Artikels, lange epische Fassung eines Artikels. Als mobiler Nutzer sollte man dann zwischen diesen Formen wählen können (und standardmäßig die kurze Version gezeigt bekommen). Und auch die Indexseiten sollten auf die Nutzungssituation ausgerichtet sein. Wollen die Nutzer, wenn sie unterwegs sind nur kurz den Dax kontrollieren, oder lange feuilletonistische Stücke lesen? Möglicherweise gehören nicht immer andere Dinge an den Kopf der Seite, aber vielleicht manchmal? Das ist dann kein SEO-Thema, sondern eher Kundenservice. Gleiches gilt natürlich für Ads, die sich nebenbei gesagt noch ganz schön an das Thema responsiveness annähern müssten.

Anderes, vielleicht nicht ganz so offensichtliches Beispiel: eine Community für Computerspiele sollte vielleicht auf der mobilen Seite nicht seine zugekauften News über Spiele vorne anstellen, sondern die Tipps und Walkthroughs, weil nämlich ihre Nutzer das Handy als Nachschlagehilfe neben dem Rechner liegen haben, während des Spielens, da derselbe ja durchs Spiel belegt ist und zum Browser switchen ziemlich abtörnend ist. Möglicherweise ist das so. Vielleicht auch nicht, müsste man mal herausfinden.

Ähnliche inhaltlichen Unterschiede sind denkbar für die Nutzungssituation auf der Couch. Den gemeinen Couchsurfer kann man ja auch ziemlich leicht targeten, er greift abends mit seinem iPad auf Webseiten zu. Dieser Nutzer widerum gibt gewöhnlich nicht viel auf Börsenkurse…

Via.

→

→

→

Via Jason Santa Maria.

→

Hier habe ich einige Nutzer gefunden, die sich die Mühe gemacht haben, das Webdesign von zeit.de nach ihrem gutdünken zu verändern und die Styles zur Verfügung zu stellen (zugegeben, mit teilweise etwas haarsträubenden Ergebnissen, aber am Ende zählt ja der Wille, positiv wie negativ).

Übersehen wir einmal das Offensichtliche: das Ausblenden der Ads, finden sich dort so interessante Styles wie: Eilmeldungen auf zeit.de entfernen, oder auch zeit.de without user comments oder …remove useless stuff.

Auf ähnlichen Pfaden wandeln die Nutzer, die Dienste wie Instapaper u.ä. in Anspruch nehmen. Ich nutze es ja eher als Merktool für Texte, die ich später am iPad (in netzfreier Umgebung) abrufen möchte, für viele ist es aber auch die designfreie (und natürlich widerum werbefreie) Umgebung, die das Leseerlebnis fördert. Man mag schon gar nicht mehr vom next big thing sprechen, denn in Sachen UI könnte dies eben kein UI sein.

Entegegen der Kritik und den Anregungen, die per Mail oder über die social Kanäle zu uns gelangen, sind dies jedoch Methoden, die der Diskussion aus dem Weg gehen, Fakten schaffen. Trotzdem natürlich ebenso valide…

Some rights reserved by Masked Malayan

Zuletzt hatte ich mir ja vor ungefähr einem halben Jahr laut gedacht, dass man nicht dauernd an seinem Blog herumwerkeln könne, solle oder müsse. Tatsächlich bewundere ich Kollegen (hüstel), die seit Jahren mit dem immer gleichen Template daher kommen, geheiligt sei der hohe Wiedererkennunswert! Doch das ist meine Sache nicht. Und manchmal bedarf es nur einer Kleinigkeit, wie das Artikelbild von Jon Díez, das ich für den letzten Aufmacher ausgewählt hatte, mir das Gefühl zu geben, mein verdammtes Blog müsse mal dringend neu angemalt werden.

Und so sei es. So was wird in meiner Arbeitsumgebung wohl graphischer Relaunch genannt, und soviel hat sich unter der Haube auch tatsächlich nicht getan. Mehr neues HTML (formally known as HTML5) und mehr CSS 3 Effekte sind schon dabei. Im Moment nutze zum ersten Mal modernizr für’s downgrading, bisher sind aber nur die Klassen no-rgba und no-touch im Einsatz, wenn sich das nicht noch drastisch ändert, wird die Bibliothek zu den art directed Artikeln abgeschoben. Die es auch in Zukunft wieder häufiger geben wird, den Mechanismus dafür habe ich verfeinert.

Auffälig ist vielleicht noch die von mit gewählte Seitenbreite, die natürlich ganz deutlich auf die Tabletanwendung, vulgo für das iPad zugeschnitten ist. Ich hatte zwar mit responsive Designs weiter herumgespielt, letztendlich ist bei mir aber die Idee hängen geblieben, dass der einzige Browser, den ich immer fullpage nutze, der im iPad ist und dieses Blog mehr Breite einfach nicht nötig hat. Vor allem auf Artikelebene fehlt es mir an Content, für große Pixelzahlen. Damit funktioniert das Design eben auch auf Apples Tablet besonders gut, ebenso auf dem iPhone.

Der Rest ist Verschlichterung im Marcschen Sinne, die Page-Speed-Analyse der Homepage steht bei 95/100. (Update: Nach Installation der Open Source Stats Lösung Piwik ist der Page-Speed-Wert erstmal wieder marginal ;) gesunken.)

Screenshot ZEIT ONLINE, Wissen Centerpage, iPad Version, Design: Information Architects

Liest man die gängigen Webdesign-Sites findet man eine Fülle von Tipps, wie man seine Website anpassen kann, damit sie auch auf dem iPad funktioniert. Der Tenor: mit css media queries ein paar zusätzliche Stylesheets für das iPad liefern, im Scriptteil ein wenig die Touch- und Gestureevents einsetzen, Flashvideos raus, Buttons größer: fertig! Das war nicht ganz das, was uns vorschwebte…

Das mit den media queries ist so eine Sache

Kurz gesagt: CSS media queries sind im Moment eine schicke und elegante Lösung, wenn man seine bestehende Website mit ein paar Handgriffen an die Gegebenheiten verschiedener, zumeist kleinerer, Displays anpassen will. Ebenso taugen sie sicherlich dazu, eine Web-App zu bauen, die nur auf Tablets funktioniert und im Desktopbrowser leer oder ungestyled bleibt (aber wer will das schon?). Für eine große Contentwebsite, die zweigleisig unter der gleichen Adresse unterschiedliche Styles an Desktopbrowser und Tablets ausliefert, sind sie jedoch (zumindest im Moment) nicht zu gebrauchen.

Das liegt zunächst einmal daran, dass mit Mediaqueries eingeschränkte Stylesheets zunächst mal allesamt heruntergeladen werden und dann entschieden wird, was angezeigt wird. Für den mobilen Einsatz und auch für den Tableteinsatz kommen sie damit kaum in Frage. Beim ersteren schon allein wegen der Downloadmengen, beim letzteren kommen wie die Erfahrung zeigt noch weitere Datenmengen an Javascript und z.B. größeren Bildern hinzu. Ein Fass ohne Boden.

Die von mir zunächst favorisierte Lösung führte aber dazu, dass nicht nur IEs kleiner Version 9 via conditional comments eigene Stylesheets zugeteilt bekommen mussten, auch Firefox 3.0 und kleiner können mit den mediumabhängigen Styles so gar nichts anfangen.

Ohne Javascript geht’s (derzeit) nicht

Und auf tut sich die böse Tür des user agent switching. Zwar gibt es eine Javascript-Lib, die css media queries gewissermassen emuliert, das ist aber ein weiterer gut 20kB großer Download ist, ein Monster mithin, das zudem nur mit Queries innerhalb von CSS-Dateien, aber nicht innerhalb von <link /> zulässt.

Stehen zusätzlich Anforderungen im Raum, dass auch ein Schalter zur Rückkehr zur klassischen Website eingebaut werden soll, oder wenn man feststellt, dass eben Tablet nicht geleich Tablet ist, man also für verschiedene Tablets noch kleinere Anpassungen vornehmen muss, dann ist man schnell dabei auf den user agent zu schauen. <interlude>Das vereinfacht übrigens auch gewaltig die Entwicklung der Seite, da man sie während des Bauens parallel zum iPad/iPad-Simulator auch im Firefox previewen kann. Das geht natürlich nur mit User Agent Switcher. Dann aber kann man den geliebten Firebug nutzen um wenigestens die Elemente auf der Seite und ihre Styles zu indentifizieren und auch das Scriptdebugging ein wenig zu unterstützen. Dinge die es auf dem iPad nicht oder nur sehr rudimentär gibt.</interlude>

Diese Lösung ist allerdings noch nicht das Endstadium, allein weil wir nach und nach die Site für weitere Tablets fit machen wollen. Im Laufe dieser Zeit werden wir auch das UA-switching wieder entfernen und durch bessere Methoden ersetzen.

Screenshot ZEIT ONLINE, Navigation, iPad Version, Design: Information Architects

Der Spass an der Entwicklung

Eins muss man gleich sagen: Entwicklung für Tablet (speziell das iPad) macht einen Heidenspaß. Zum einen ist die Touchbedienung faszinierend. Ich bin so einer, der ein mouse-over-Menü entwickelt und sich dann stundenlang daran erfreuen kann, wie beim Hovern über den Menüpunkt das Menü animiert ausfährt. Auf dem Tablet kann man solche Lösung praktisch zum Anfassen programmieren (natürlich ohne :hover). Ich habe das Menü bestimmt mehrere tausend Mal ausprobiert. Oder die Bildergalerien (obwohl ich da noch nicht zufrieden bin). Die Möglichkeiten des Webkit sind wirklich hervorragend und das geniesst man natürlich. Obwohl es auch ein wenig zu verführerisch ist, wenn man in die Hölle der Desktopbrowser zurückkehrt und feststellt, dass es da draussen immer noch Internet Explorer gibt… ;)

Kleinere Schlaglöcher

Ein paar Dinge waren allerdings echte Kopfnüsse. Da ist zum Beispiel der Viewport-Tag. Schon bei diesem Blog hier habe ich Probleme damit gehabt. über diesen einen Tag den Viewport und vor allem die Vergrößerung so zu setzen, dass es für iPad und iPhone gleichermaßen funktioniert. Das Design der iPad-Seite erforderte ganz klar ein:

<meta name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=1.0">

Das passt allerdings nicht zu unserer Art, das iPhone zu bedienen. iPhone-Nutzer werden beim Besuch gefragt, ob sie die mobile Website besuchen möchten, oder die klassische Seite. Mit dem obigen Meta-Tag kann man diese dann aber auf dem iPhone nicht mehr skalieren. Für das iPhone empfiehlt sich eher:

<meta name="viewport" content="width=device-width">

Will man allerdings (für das iPad) zwei Ansichten für Portrait- und Landscapemodus präsentieren (vs. vergrößerte Portraitansicht im Landscapemodus), dann ist man auf das minimum-scale=1.0, maximum-scale=1.0 festgelegt.

Überraschenderweise kann man aber auch diesen Metatag per Javascript setzen! Es hat allerdings ein wenig gedauert, bis ich das einfach mal ausprobiert habe (hüstel). Außerdem musste dafür ganz schön an unserer Seitenstruktur geschraubt werden.

Wie geht’s weiter?

Zunächst mal kommen jetzt schnell weitere Tablets dazu, mit denen man die Seite betrachten kann. Es war leider schnell klar, dass man mit einem Schlag nicht alle Tablets bedienen kann. Mindestens an den Einstellungen des Viewports müssen Anpassungen gemacht werden, wahrscheinlich auch etwas CSS und Script. Wobei, wir wollen jetzt auch nicht jedes Tablet das neu auf den Markt kommt kaufen (der Gadgetjäger in mir fragt natürlich: »warum eigentlich nicht«). Man wird sehen, was sich am Tabletmarkt noch tut und was sich durchsetzt. Wir räumen zunächst mal dem Galaxy Tab von Samsung gute Chancen ein, und wenn RIM mit einem Tablet kommt, wird’s ja vielleicht auch nochmal interessant.

Abschließend sei gesagt, dass die Sache natürlich ein gutes Stück weit vom Design der Information Architects lebt, Oliver Reichenstein hat dazu einen schönen Artikel geschrieben, der auch die – ich nenne es mal so – medienpolitischen Hintergründe gut erfasst und viel von dem Geist beschreibt, der hinter dieser Webapp steckt.

Noch ein paar Artikel und Stimmen zum Thema: iPadMag, Editors Weblog, iPad Planet NL…

Was Jason Grigsby vor allem kritisiert ist, dass man um eine Anpassung bspw. für mobile Clients zu erreichen, mehr anstatt weniger Code hinzufügt:

The idea of adding more code—adding more to download—in order to optimize for mobile should be the first clue that this isn’t a good solution.

www.cloudfour.com

Das wäre natürlich kontraproduktiv und ist für große Websites, die sowieso schon immer mit ihrem Gewicht zu kämpfen haben auch tatsächlich keine Alternative. Zudem hat man ja auch keine Unterscheidung für die ausgelieferten Medien, bspw. Bilder. Große hochaufgelöste Bilder braucht man bspw. für das iPad, aber nicht für das kleine Display eines Mobiltelefons. Smartphones wie das iPhone4 fallen aus dieser Kritik aber eher heraus, lechzt es doch nach noch höher aufgelösten Bildern als der Desktopwebbrowser. Hier müsste dann je nach Nutzungssituation unterschieden werden.

Allen Lösungen gemein ist im Moment, dass die mit media queries spezialisierten Seiten, nur wenige kleine Effekte anbieten, bspw. schmalere Spalten, verkleinerte Bilder etc. Was aber, wenn die Seiten für das iPad und später auch das iPhone wirklich komplett anders aussehen sollen? Versucht man sämtlichen CSS-Code zu überschreiben, landet man schnell in der Codinghölle und das Gewicht der Seite explodiert. Ich habe mich nun gefragt, mal in Bezug auf das iPad (und andere Tablets) gesehen, deren Nutzung ich weniger als mobile Nutzung betrachte, wie man mit den media queries nun zwar genug, aber eben möglichst wenig CSS-Daten an die Browser schicken kann. Mein derzeitiger Lösungsansatz sieht so aus siehe Update am Ende des Artikels:

<!--[if IE]>
	<link rel="stylesheet" href="css/base.css" type="text/css" />
<![endif]-->
<link media="only screen and (min-device-width: 769px)" rel="stylesheet" href="css/base.css" type="text/css" />
<link rel="stylesheet" media="only screen and (min-device-width: 768px) and (max-device-width: 1024px)" href="css/ipad.css" type="text/css" />

Zur Erklärung: Zunächst mal werden die IEs bedient, die derzeitig nicht in der Lage sind media queries auszuwerten. Der bekommt ganz normal sein CSS geliefert. Die restlichen Stylesheets ignoriert ein IE dann geflissentlich. Alle anderen Browser widerum ignorieren die conditional comments und falls sie eine min-device-width größer 769px haben, laden und zeigen sie das normale base.css. Hernach folgt dann das CSS für das iPad, mit einem Query auf seine Werte abgestimmt.

Soweit zur Theorie. In der Praxis scheint das so zu funktionieren. Lädt man viele verschiedene CSSse, kann das allerdings schnell unübersichtlich werden, da alle nichtmobilen CSSse doppelt aufgeführt werden müssen.

Anregungen und andere Ideen sind mehr als willkommen.

Artikelbild: Some rights reserved by anarchosyn.

Update: Zwei Tatsachen haben inzwischen dazu geführt, dass ich selbst nicht mehr so überzeugt von dieser Lösung bin: 1. werden ob mit media queries oder ohne immer alle Dateien vom Browser gezogen. Man spart aber ggf. durch weniger CSS-Überschreiben, je nach Art und Größe der Styles; 2. wichtige Info: schon Firefox 3.0 kann keine CSS media queries.

→

Nun kommen natürlich wegen mir alleine zu wenig Teilnehmer zu einem Kongress, deswegen sind weitere hochkarätige Webexperten geladen worden, bspw. Jens Grochtdreis, Vladimir Simovic und Alvar Freude. Übergeordnetes Thema des Kongresses sind Lösungen für barrierefreie Webseiten, soll heissen es geht nicht mehr nur um die Technik und den Prozess, sondern vielmehr um Webangebote, die diese Techniken auch ein- und umsetzen.

Mehr gibt es auf der Homepage des WKE 2010 nachzulesen. Man sieht sich.

Dabei habe ich vor allem darauf Wert gelegt, viel der Techniken auszuprobieren, die ich in den letzten Wochen und Monaten gelernt und an anderen Stellen gelernt habe. Darum ist auch viel mehr unter der Motorhaube passiert, als die Dinge, die man nach aussen sehen kann. Namentlich sind das: Nutzung vieler neuer HTML5-Elemente, Verschlankung des CSS-Codes und Nutzung von CSS media queries um eine angepasste Version für das iPad und Browser mit verkleinertem Fenster anzubieten, Verschlankung des Javascriptcodes, Verbesserung der WordPress-Templates und meiner geliebten functions.php. Aber eins nach dem anderen.

Welcome figure und figcaption

Das neue HTML5-Element figure gehört wirklich zu den sinnvollen Elementen, die schon immer gefehlt haben. Bei figcaption allein bin ich mir nicht so sicher. Der Name zeigt schon, dass man Schwierigkeiten hatte, das neue Element zu integrieren. In einem früheren Stadium war es auch tatsächlich geplant, die Elemente in figure als Definitionslisten zu gestalten. Mit diese Semantik war man schlussendlich aber nicht zufrieden, weshalb man ein eigenes Element erfinden musste und das erhielt den üblen Namen: figcaption. What a word. Ihhhh. Aber sei’s drum, beide Elemente finden sich nun prominent in der Homepage wieder.

Außerdem habe ich die Seite, nicht nur visuell, sondern eben auch im Code, in sections unterteilt. Die HTML5-Elemente header, article , footer und noch ein paar mehr, waren schon vor diesem Relaunch Teil des Codes. Damit bin ich der HTML5fizierung der Seite schon ein ganzes Stück weiter gekommen, ganz abseits der Buzzwordklopperei, rein im Code. Nun müsste man die Elemente nur noch ordentlich in den Artikeln nutzen können, ohne das WordPress anfängt rumzumucken, aber da kümmere ich mich auch noch drum.

Eine neue Brotschrift gibt’s nun auch, hier geht Droid Serif ins Rennen und ersetzt die Georgia, wo sie kann.

CSS Media Queries

Man konnte ja schon vorher lesen, dass ich mich in der Vorbereitung auf das iPad schon ausgiebig mit den praktischen Media-Queries auseinanderhesetzt habe. Nun habe ich auch hier im Blog eine entsprechende Regeln implementiert. Ab sofort bekommen das iPhone im Portraitformat und Browser deren Fensterbreite unter 920px liegt, eine verschmälerte Version der Seite angezeigt. Das kann ja jeder, der mit einem modernen Browser hier vorbeischaut leicht nachvollziehen, sonst hier auch mal ein Beispiel: so sieht’s breit aus:

Und so die schmale Version, 620px-einspaltig. Eigentlich hatte ich die schmale Version im normalen Browser nur zum Testen genutzt, bis mir am Netbook auffiel, dass das natürlich auch für den Firefox durchaus Sinn machen kann.

Der eigentliche Seitencontent ist 940px breit, ich habe 20px Karenz gelassen, weil mir auffiel, dass wenn man bspw. genau 940px nimmt, der Sprung zur schmalen Version auch passiert, wenn er gar nicht nötig ist, zum Beispiel, wenn man das Fentser genau auf Contentbreite bringen will. Insgesamt stört mich der Moment des schwitchens ein wenig, das ist schade, das das so abrupt erfolgt.

@media only screen and (max-width:920px), only screen and (max-device-width: 768px) and (orientation:portrait) { … }

Für das iPad im Landscape-Modus wird übrigens kein spezielles CSS geliefert. Stattdessen habe ich versucht, die normale Seite so iPad gerecht wie möglich zu gestalten.

Zudem werden wohl nicht alle art directed Artikel in die schmale Version passen. Da kann der geneigte iPad-Nutzer ja noch den Landscape-Modus nutzen.

WordPress- und/oder Javascriptcode

Nach längerer Zeit bin ich auch mal dabei gegangen und habe meine functions.php ein wenig aufgeräumt. Da meine Templates immer ziemlich egozentrisch gestaltet sind, habe ich keine Plugins gebaut, sondern alles was ich an zusätzlichen Funktionen benötigte in diese Datei codiert. Kann man machen, ist wie gesagt nicht so freundlich, wenn man das Theme veröffentlichen will. In der genannten Datei hat sich die letzten Jahre über aber auch ziemlich viel Müll angesammelt, den ich ersatzlos entsorgt habe.

Für meine art directed Artikel habe ich mir ja selbst eine kleine Erweiterung geschrieben, mit der man zusätzliche CSS-Sourcen als Meta-Feld an den Artikel hängen kann. Ich habe mir nun das Art Direction Plugin nocheinmal genauer angesehen und es wieder verworfen, nicht nur wegen der dämlichen Zeile Pay your respects to print, get Art Direction. auf der Plugin-Seite, sondern auch weil ich es für überflüssig halte. Stattdessen habe ich meine Lösung erweitert und verbessert, sowie das Silbentrennungsscript als Option auch für andere Artikel zugänglich gemacht.

Womit wir beim Javascript sind, denn auch hier habe ich ein wenig den Hammer kreisen lassen. Früher globale Scripte, die nur auf einigen wenigen Seiten gebraucht wurden, werden nun nur noch an den entsprechenden Orten geladen. Dafür habe ich mit meiner selbstgeschriebenem Artikelgalerie mal wieder echten Betacode auf Euch losgelassen. Das ist wie immer work in progress.

→

→

Wie muss eine Webseite für das iPad aussehen? Es ist eigentlich alles wie immer. Mit dem iPad kommt ein mobile Safari, also ein potenter, moderner Webbrowser, der sich auf allerlei finessen im Bereich HTML5 und CSS3 versteht. Natürlich fungiert dieser Browser innerhalb der Constraints, die ihm das Tablet vorgeben.

768 x 1024, wtf???

Da wäre zunächst die Größe (Kleine?) von 1024 x 768px in Landscape-Ansicht, vor allem aber 768 x 1024px im möglicherweise häufiger genutzten Portraitmodus. Das ist schon mal eine gewisse Einschränkung, die es zu umschiffen gilt. Denn wie man es auch dreht und wendet, der User hat zwei unterschiedliche Perspektiven, aus denen er auf die Website schaut, [t]he iPad has no RIGHT way of viewing websites.

Hier dürfte es drei sehr unterschiedliche Lösungsansätze geben. Zunächst zwei Strategien, die von der (schon vorhandene) Standardwebsite ausgehen und diese anpassen oder erweitern:

1. Fluide Layouts: die Evangelisten des fluid designs können in die Hände klatschen und angeben, dass sie ja gleich Recht hatten. Ein ordentliches auf Prozent der Fensterbreite basierendes Konzept wird sicherlich auch im iPad tadellos funktionieren und zwar im Hoch- wie auch im Querformat.

2. Flexible Adaptive Layouts: das wäre eine Taktik, wie wir sie bei ZEIT ONLINE verfolgt haben bisher, nämlich für verschiedene Bildschirmbreiten unterschiedliche Layouts anzubieten, wobei das umschalten automatisch passiert. Dies könnte beispielsweise mit Javascript gelöst werden.

Die dritte Lösung wäre, für das iPad ganz eigene Seiten zu erstellen, so wie es heute oft auch für mobile Endgeräte gemacht wird. Das gehört aber nur insoweit hierher, diese Möglichkeit festzustellen. Geht die Welt dazu über, den iPad-Usern spezielle Mobilwebseiten zu präsentieren, dann hätte dass ja gar keinen Einfluss auf die normalen Websites.

Ich tendiere mehr zu Lösung zwei. Fluide Designs sind auf jeden Fall rock solid, aber auch stinklangweilig. Hochkant, Querformat, die Seite ist immer gleich. Apple selbst verbindet aber mit seinen Produkten (bspw. Mail) einen ganz bestimmten Effekt auf das Aussehen, der sich beim Wechsel zwischen Hochkant- und Querformat einstellt. Beim Mailprogramm beispielsweise bietet der Landscapemodus die Übersicht, links die Inbox, rechts die Mails, während im Portraitmodus die Inbox verschwindet (und nur noch als Menüpunkt bestehen bleibt) und man sich auf eine Mail konzentrieren kann. Den gleichen Effekt sehen wir auch in der Sports Illustrated Demo [via Arne], die viel Müll enthält – beispielweise das Sounddesign der 60er Jahre Batman-Serie (swoosh!), aber eben auch hervorragende Ideen, wie man Landscape- und Potraitmodus nutzen kann. Mit einer normalen Webseite kann man derartige Effekte nur per flexible Layout erreichen.

Eine Sache werden allerdings alle begreifen müssen: es gibt ein Leben unter 600px.

Und dann die Wurstfinger

Einen weiteren Einfluss, den das iPad auf das Webdesign nehmen könnte, hat mit seiner Bedienung zu tun. Finger sind irgendwie nicht so klein und filigran wie eine Maus bzw. deren Cursor. Im Gegenteil: Finger sind dick und fett und verdecken zudem noch das, was man gerade anklicken will. Logischerweise wird man also alles Anklickbare größer machen müssen. Und dann noch etwas größer. Und dann noch Platz bach aussen schaffen. Und Whitespace drumherum. Zusammengefasst: am besten nur noch dicke, große, fette Buttons.

Ach ja und natürlich keinerlei Hovereffekte und Mouseoverspielereien. Was berüht wird, das wird geklickt oder verschoben oder sonstwas, aber einen Hoverevent gibt es nicht.

Kein Flash

Wenn man sich auch uneinig ist, welche Zukunftsaussichten das Adobe beschert: es gibt kein Flash auf dem iPad. That’s a fact. Also: einfache Sache. Stoppt die Nutzung von Flash. Was man nicht will, sind die kleinen blauen Legosteine, die das fehlende Plugin anzeigen. Wenn man seinen iPad-Kunden seinen Content anbieten will, darf er nicht in Flash sein. Was man zum Ausweichen nutzen will, wird man noch sehen.