Es ist kurz vor 20 Uhr. Ich sitze in der Lounge des Motel One „Hackescher Markt“ am Alexanderplatz (don't ask) und mir schwirrt der Kopf. Eigentlich hätte es heute abend noch ein Event mit Chip Kidd und anschließenden Umtrunk beim Get Together gegeben. Aber ich bin jetzt schon soweit an die Grenze meiner Aufnahmefähigkeit gekommen, das ich ein Get Together mit mehreren Hundert Leuten (500 Teilnehmer sind es dieses Jahr, plus 200 auf der Warteliste) eher als Last empfinde.
Wie war es?
Doll war es. Ich würde am liebsten ein Timeout-Zeichen machen. Lasst es bitte sacken und lasst mich mal nen Monat ausprobieren.
Es waren heute sechs Vorträge. Zwei waren bei konkreten technischen Themen für mich nutzwertig. Zwei waren uplifting und inspirierend. Da würde man jetzt gerne mal selber ausprobieren. Ein Vortrag war ein interessantes Sujet, über das ich gerne länger nachdenken und diskutieren wollen würde. Und ein sechster Vortrag über ein Thema das für mich aktuell keine praktische Anwendung hatte und zu dem ich auch eine etwas dezidierte Sicht habe...
1: Steve Sounders + Mark Zeman „Design & Perforance“
Guter Vortrag mit gleich zwei Präsentatoren, die das Ping Pong zwischen Design und Performance veranschaulichten.
Performance ist eines jener Themen die längst bei den Entwicklern angekommen sind – die aber die Entwickler/Designer häufig genug nicht auf die Agenda hieven können. Die Probleme fangen schon beim Start an, wenn Designer in ihrer Abteilung vor Photoshop sitzen und herumprokeln, während die Entwickler in anderen Abteilungen, räumlich getrennt sitzen. Der banale Tipp von Mark Zeman: kleine interdisziplinäre Teams aufbauen. Die eigentliche Schlüsselinformation von Zeman war aber die Verkaufe. Man setzt sich am Anfang des Projektes hin, startet ganz unschuldig "Guiding Principles" und schiebt u.a. rein, dass die Website eine sehr gute User-Experience besitzen soll. Die gute User-Experience als Guiding Principle ist das U-Boot um in Projekten das Thema Performance auf die Agenda zu hieven.
Mark Zeman ging näher auf ein Projekt ein: „New Zealand 100% Pure“, eine optische sehr aufwändige Seite für die Tourismuszentrale Neuseelands und eine sehr tricky Umsetzung angesichts der oppulenten optischen Umsetzung. Mark Zeman bringt hier eine für mich neue Interpretation des Satzes „We’re designing Timelines, not static pages“. Den Satz kannte ich nur für Animationen oder Übergänge. Zeman verwendet ihn hier aber explizit für die Frage: welche Assets, welche Teile der Seite laden zuerst und wie laden sie? Was kann ich dem User anzeigen, bis die Assets geladen sind?
Hier kam dann Steve Sounders als „Performance Guy“ ins Spiel. Er zeigte einige Anwendungsbeispiel zur Frage, was eigentlich die Benchmark ist, um userzentrische Performance zu messen. Custom Metric. Beispiel: Twitter und die Zeit die es braucht, bis die Seite soweit geladen ist, dass der User den ersten Tweet (Text und Avatar) sieht.
Sounders zeigte wie er die neue W3C Web Timer Specs verwendete, um direkt im DOM Ladezeiten zu messen. windows.onload() erweist sich als Hook als erstaunlich untauglich. Amazon hat 99% seines Above the Fold-Contents schon nach zwei Sekunden geladen, während das windows.onload()-Event erst nach 9,7 Sekunden getriggert wird.
Der Vortrag hat mit Lust gemacht mit den neuen Web Timer Specs herumzuspielen und an einigen Websites damit herumzuspielen, aber sich auch mal einen Nachmittag lang hinsetzen und sich für verschiedene größere Websites Custom Metrics zu überlegen.
2: Brad Frost „Style Guide Best Practices“
Frost ist eine Rampensau und sein Vortrag hat Spaß gemacht. Sein Vortrag war zwar mal wieder um die Essentials von Atomic Design herum gestrickt. Das war aber in diesem Fall nicht schlimm, denn der Vortrag zeigte, das Frost inzwischen 2-3 Schritte weiter denkt. Ähnlicher Ausgangspunkt wie beim Sounders-Zeman-Vortrag: wie kann das Thema zur Agenda gemacht werden.
Frosts Antwort: „$ell it“. Die meisten Websites bieten genügend „Angriffspunkte“ um in einer Präsentation auseinandergenommen zu werden. Sei es Inkonsistenzen innerhalb eines Webauftritts (Frost zeigte die 14 unterschiedlichen Buttons auf der Website seiner Bank) oder Inkonsistenzen innerhalb der Familie der Websites, z.B. bei den ganzen unterschiedlichen Töchtern der Firma Canon. Und man kann CSS Stats drüber jagen und Inkonsistenzen in Form von zuvielen Fontstyles und Farben extrahieren.
Atomic Design und Pattern Lab sind in diesem Kontext nicht mehr nur als bloße Stylinghilfe oder Styleguide zu verstehen, sondern als Interface Inventory zu vermarkten, also als Baukasten für Design-Elemente – nicht nur des Webauftritts.
Die Nachhaltigkeit eines Systems wie Pattern Lab wird aber auch davon abhängen, inwieweit es den Status eines bloßen Style Guides velassen kann und stattdessen das Markup und das CSS von Pattern Lab auch in Code einfließen kann. Das Reiseportal „Lonely Planet“ hat mit „Rizzo“ ein Styleguide-System gebastelt, bei dem das Markup aus den Komponentes des Style Guides über APIs direkt in die Applikation reinläuft. Brad Frost hat sich in kleineren Dimensionen einen entsprechenden Grunt-Workflow gebastelt.
3: Martina Flor „Telling Good from Bad“
Martina Flor ist eine argentinische Letterin, die vor einigen Jahren nach Berlin gezogen ist – Berlin, die Hauptstadt der internationalen Typographie. Sie erzählte über ihre Arbeit und wie sie als „One-Woman-Shop“ mehrere Aufträge handlet. Sie gab am Ende des Vortrages fünf Schlüsselpunkte zum Erkennen von guten Lettern an die Hand – aber die eigentliche Inspiration aus ihrem Vortrag ist für mich, welche positive Effekte sie hat, weil sie viele Arbeiten ins Netz stellt. Das sind ebenso Fingerübungen wie auch das Austesten von neuen Wegen oder einer neuen Designsprache, aber auch die typischen Sovial Media-Effekte, wie die Erhöhung des Bekanntheitsgrades. U.a. nahm sie an einer Art Battle mit einem Kalligraphen teil, bei dem nach einer Aufgabe, ein Buchstabe gezeichnet werden sollte und per Voting über den Sieger abgestimmt wurde: letteringvscalligraphy.com
4: Marcy Sutton „How to win mobile accessibility“
Es war für mich der uninteressanteste Vortrag des Tages – was nicht an Marcy Sutton lag. Ich hatte mich vor anderthalb Jahren recht intensiv für einen Kundenauftrag mit dem Thema Accessibility beschäftigt und von daher kannte ich das Thema schon. Noch schlimmer: der Auftrag hat mich seinerzeit für das Thema Accessibility verbrannt.
Ich musste damals ziemlich verwarzten HTML-Code eines großen, selbstgestrickten PHP-Kunden-Frameworks unter Accessibility-Gesichtspunkten gerade ziehen. Nach dem ich mich mehrere Wochen in das Thema Accessibility eingelesen und Code geradegezogen habe, kam einer der Kunden meines Auftraggebers mit einem blinden Mitarbeiter vorbei – und kam mit den von mir gerade gezogenen Webseiten nicht zurecht.
Das ganze ARIA-Zeug und ähnliches, liest sich auf Papier gut. Es scheint aber auf User-Seite nicht wirklich gebraucht und ausgewertet zu werden. Ich hatte eine komplexe Navigation auf eine ARIA-Tree-Navigation umgestrickt. All diese von ARIA empfohlenen Patterns, alles sinnlos. Der Blinde hat letztendlich nur die TAB-Taste und die RETURN-Taste verwendet. Keine Plus-/Minus-Zeichen. Keine Anfangsbuchstaben für Menüpunkte etc…
Wenn das Markup über einen gewissen Punkt hinaus verwarzt ist, ist die Geschichte unter Accessibility-Gesichtspunkten unrettbar gegen die Wand gefahren worden und keine ARIA-Attribute dieser Welt können das schlechte Markup kompensieren. Und mit diesem selbstgestrickten PHP-Framework des Kunden war schlichtweg nichts mehr zu retten. Da sind die eigentlichen Schmerzen von Accessibility und da ist man letztendlich wieder schnell bei dem Punkt wo es auch ein Problem der Projektleitung und der Agenda des Projektes wird.
Vor dieser von mir erlebten Realität nimmt sich der Vortrag von Marcy Sutton etwas idealistisch aus.
5: Scott Jenson „Building the Pysical Web Together“
Jensons Vortrag blieb mir vor allem unter dem Gesichtspunkt haften: was kann da die nächsten Jahre noch passieren. Das „Physical Web“ ist ein merkwürdiger Begriff für etwas, was man schon als „Internet of Things“ kennt. In dem Fall handelt es sich um kleine Hardware, kaum größer als ein 20 Cent-Stück, die ein Beacon darstellen, also über Bluetooth permanent eine URL an die Außenwelt abgeben.
Die Außenwelt, z.B. in Form eines Smartphones, kann diese ausgesendete URL empfangen und in den Notifications darstellen. Beispiel: Parkuhren. Eine Parkuhr strahlt die URL mit einer Reichweite von 2 Metern aus. Das Smartphone kann die URL anzeigen und führt zu einem Portal, wo speziell diese Parkuhr bezahlt werden kann. Die Parkuhr bekommt aus dem Internet das Feedback: „Parken ist bezahlt worden“ und stellt sich auf Grün.
Jensons Vortrag führte in diese Technik ein, demonstrierte wie billig die Technik sei und dass es problemlos möglich wäre, solche Beacons z.B. an Toastern zu kleben. Nicht um ferngesteuert toasten zu können, aber auf eine Produkt-Website zu gehen, auf der sich Doku und Pflegehinweise befinden.
Im Gegensatz zu den iBeacons von Apple, können dem Smartphone-Besitzer keine Coupons aufgedrängt werden. Das System verhält sich passiver und ist, weil ein Proxy zwischen geschalten ist, auch potentiell datenschutzfreundlicher.
6: Brendan Dawes „Plug an Play“
Wenn man Dawes Vortrag nicht gesehen hat, fällt es schwer zu beschreiben, was Dawes eigentlich macht. Vielleicht kann man ihn am ehesten „Code Künstler“ oder „Code Performance“ nennen. Sein Geld verdient er damit, das Unternehmen oder Agenturen auf ihn zu kommen und sagen: hier haben wir Daten und wir würden gerne eine attraktive Präsentation dafür bauen lassen. Das britische Mobilfunkunternehmen EE bat ihn zum Beispiel anhand der Tweets aus fünf englischen Großstädten eines Tages, eine schöne Grafik zu basteln, die dann aus Anlaß des Start der Sendeantennen in den jeweiligen Städten, dem Bürgermeister feierlich überreicht wird.
Dawes ist ein Spinner, der viel für die Schublade arbeitet. Vieles ausprobiert, viel Spieltrieb besitzt. Aber seine Erfahrung zeigt, dass dieses „Für die Schublade arbeiten“ sich lohnt. Er lässt sich davon inspirieren und hat vieles später in Projekten wieder einsetzen können.
Es gab eine klare Parallele zwischen ihm und der Letterin Martina Flor: folge deinem Spieltrieb um deine Arbeit zu bereichern. Probiere aus. Erforsche es. Und rede darüber im Netz.
Resümmee für mich nach dem ersten Tag: mal einen Tag sich intensiv das Tema der Performancemessung anschauen. Mal 2-3 Tage über das Thema einer besseren Anbindung von Pattern Lab-Code an Produktivsysteme nachdenken und eruieren, ob eine andere Templatesprache als Moustache einen dabei weiterbringt.
Sich zweimal inspirieren lassen, mehr zu spielen und damit raus zu gehen. Einmal dazu aufgefordert werden, über eine Zukunft mit Beacons nachzudenken. Und sich einmal an die Verbrennungen erinnern, die man sich bei Thema Accessibility geholt hat.