CSS4: Des Kaisers neue Kleider

Peter Paul Koch denkt seit ein paar Wochen, immer mal wieder ĂŒber die EinfĂŒhrung eines CSS4 nach, lustigerweise aus rein marketingstrategischen Überlegungen heraus.

Regardless of what we say or do, CSS 4 will not hit the market and will not transform anything. It also does not describe any technical reality.
Then why do it? For the marketing effect.

CSS ist heute
 CSS, es ist aufgeteilt in einzelne Module, die eine eigene Versioniering haben, sich voneinander getrennt weiterentwickeln. Ein Konzept, das aus technischer Sicht hervorragend funktioniert. Allerdings, soweit muss man PPK recht geben, es gibt der Sache keinen Markenkern, keinen werblichen Anstrich, keine Zugkraft, die bspw. CSS3 oder gar HTML5 durchaus hatten.

Instead of attempting to define it, we should airily refer to CSS4 but be rather vague about what it means exactly. That allows people to project their own feelings and ideas onto it. CSS4 is here, and it means whatever you want it to mean. Now come and learn. It’s cool!

Der Vorschlag geht tatsĂ€chlich in die Richtung, zunĂ€chst zwei Module auszuwĂ€hlen und diese fĂŒrdahin „CSS4“ zu nennen. Eins der Module soll custom properties sein, das andere wird noch diskutiert. Chris Coyer unterstĂŒtzt die Idee.

Was ist nun das eigentliche Problem dahinter? Hat die schwer definierbare Masse CSS tatsĂ€chlich keinerlei Werbewirkung? Muss man dafĂŒr ĂŒberhaupt werben? Stehen wir in Gefahr, auf Tabellen und inline-Attribute zurĂŒck zu fallen? Ich schĂ€tze nicht.

Allerdings hat PPK einen Punkt in der BefĂŒrchtung, dass CSS an Bedeutung verliert, zumindest fĂŒr einen Teil von Entwicklern, mindestens jenen, die ĂŒber Javascript und seine Frameworks zur Webentwicklung geraten sind. CSS ist kein Hexenwerk, aber anscheinend ein abschreckendes Konzept fĂŒr Javascriptprogrammierer. PPK teilt zur ErklĂ€rung die Entwicklerwelt in drei Teile: Kopf, Torso und „long tail“ (höhö), wobei vor allem bei letzterer Gruppe sich wenig um CSS kĂŒmmert. Was sich etwas sehr abgrenzend anhört beschreibt aber eigentlich recht gut, die aktuelle Wissensverteilung und aktive „wenn ich einen Hammer habe, sieht jedes Problem aus wie ein Nagel“-Ideologie, die dort herrscht, wo man der Ansicht ist, CSS durch JS ersetzen zu können.

In practice, all current outreach efforts such as conference presentations and blog posts or articles are aimed at the head. Not that the torso or long tail wouldn’t understand them, but they generally don’t seek them out. I would like to give them an incentive to do so.

Und dieses incentive soll nun CSS4 geben. Hmmm
 etwas ratloses am Kopf kratzen
 wenn ich mal kurz darĂŒber nachdenke, was ich in jungen Jahren mit viel Stolz an Badges und Buttons auf meine Seite gepappt hab, „build with CSS2“ oder was fĂŒr einen PR-Stunt es war, die erste Nachrichtenwebsite in HTML5 zu bauen
 vielleicht ist am Ende etwas dran an der Idee? Man könnte das eine oder andere Buch raushauen: „CSS4 – the good parts“, „Highend CSS4“ und „Professional CSS4“. Und Aufkleber drucken!

OK, ich weiß echt nicht, ob es helfen wird. Aber ich hĂ€tte Bock! Go CSS4!

Wir hatten ja nichts!

Möglicherweise werden wir alle Ă€lter. Ein PhĂ€nomen, das bisher an mir gĂ€nzlich vorbeigegangen ist. Allerdings poppen um mich herum immer wieder Artikel ĂŒber die guten alten Zeiten hoch, an die ich wundersamer Weise gar nicht so gute Erinnerungen hege, sondern mir graue Haare in nicht geringer Menge eingebracht haben. Evelyn Woods herzerreißende Komplettgeschichte der Webentwicklung seit 1999 bis heute, welche ich dringends zur LektĂŒre empfehle, fasst nun quasi alles zusammen, was man als Webentwickler:in in den genannten Jahren erleben durfte und musste. Und das war nicht immer schön, wie die mitgelieferten Codebeispiele eindrucksvoll beweisen. Nehmt euch einfach ein halbe Stunde Zeit, eine feine Tasse Early Grey und lest den Text einmal in Ruhe durch.

Was bei allem Meckern ĂŒber die sogenannten guten alten Zeiten oft vergessen wird ist allerdings, wie hemdsĂ€rmelig das alles war einerseits, dabei aber von einer beeindruckenden Direktheit, die einen unglaublichen Spaß brachte. Man hat halt an einem Codeschnipsel immer und immer wieder herumgeschraubt, ĂŒber Nacht, per FTP direkt auf dem Server. Ich will gar nicht behaupten, man hĂ€tte damals Nerven aus Stahl gehabt, es war halt nur einfach egal. Bis weit in mein aus dem Blog erwachsenen Arbeitsleben hinein habe ich es noch mit Downtimes zu tun gehabt, die jemand beim Hantieren auf dem Server verursacht hatte. Kein Netz, kein doppelter Boden. Vielleicht mal ein Backup (you know index.html.bak?). DafĂŒr war immer alles sofort verfĂŒgbar, wir operierten an offenen Herzen und in 98% der FĂ€lle ĂŒberlebten die Patient:inn:en und sahen danach besser aus als vorher. Noch heute sitzt mir diese direkte Arbeitsweise im muscle memory, was sich durch hunderte Reloads oder Wechsel von der IDE zum Browser, reloaden passiert ja inzwischen von selbst, zeigt. Coden, schauen, coden, schauen, rinse, repeat. Es hat sich auch gezeigt in einem starken Unwillen, diese Macht aus der Hand zu geben. Was liebte ich CSS-PrĂ€prozessoren, aber lehnte sie zunĂ€chst doch ab, weil ich ihnen mißtraute, die sollen mein CSS schreiben? Never! Und erst webpack đŸ˜±

Naja, glĂŒcklicherweise habe ich immer junge Kolleg:inn:en gefunden, die mich auch noch heute in meinem Rollstuhl durch die Codebasis fahren und mit mir die Wunder der modernen Webentwicklung ergrĂŒnden.

Keine Cookies

Aus gegebenem Anlass möchte ich mal eins erwÀhnen: ich habe kein Cookie-Banner auf dieser Seite. Weil es hier auf diesem Blog keine Cookies gibt. Gern geschehen.

An dieser Stelle einfach das passende Stockfoto mit Keksen hindenken. Kekse, die gerade von einem sonnenbebrillten Hacker im schwarzen Hoodie geklaut werden. Danke.

Probleme mit dem Daily Scrum

Die Murmeltiere der Webentwicklung grĂŒĂŸen sich bekanntermaßen tĂ€glich, jedenfalls dort, wo ProjektverschleierungsreligiositĂ€ten wie Scrum betrieben werden, also quasi all over the world. FĂŒr den Scrum-AnfĂ€nger, den Stakeholder und den Vorgesetzten IRL ist das die Scrum-Komponente, die am einfachsten zu verstehen ist. Leider ist das meist ein MissverstĂ€ndnis auf breiter Front und gerade durch die tĂ€gliche Wiederholung, verfestigen sich Fehler, die sich einschleichen praktisch immer wieder neu.

By the book

Im engere Sinne ist das sogenannte Daily ein kurzes (auf hart 15 Minuten beschrĂ€nktes) tĂ€gliches Meeting, wĂ€hrenddessen sich die Entwickler erzĂ€hlen, wie ihr Stand gerade ist. Außer den Entwicklern nimmt ein Scrum-Master an dem Meeting teil, ebenfalls der Product Owner (PO) nach Möglichkeit. Protagonisten sind aber die Entwickler, die sich gegenseitig die Fragen beantworten, was sie gestern getan haben, was sie gedenken heute zu tun und was ihnen im Weg steht. An diese drei Fragen soll sich akribisch gehalten werden. Der PO besucht dieses Meeting, um selbst auf neuestem Stand zu bleiben, ggf. um Fragen zu beantworten, das aber allenfalls, wenn sie mit „ja“ oder „nein“ zu beantworten sind, lĂ€ngere Diskussion finden zwangsweise nach dem Meeting statt.

What can possibly go wrong

Bei einem so einfachen und hart reglementierten Termin fragt man sich, was kann denn da noch schief gehen? Leider alles. Wie vieles in der Welt des Scrum funktioniert es möglicherweise nur, wenn man sich wirklich daran hĂ€lt, in der richtigen, reinen, wahren Scrum-Umgebung. Also niemals. Abweichungen, die landlĂ€ufig dauernd vorkommen („wir machen unser eigenes Scrum“), wie fehlender Scrum-Master, mehrere PO, nicht durchbrochene Command-and-Control-Muster fĂŒhren sofort zu einer Schieflage und das Meeting erfĂŒllt einerseits nicht seinen Zweck und wird andererseits schnell zur tĂ€glichen Qual.

Organisationsprobleme

Oft wird ja schon der Sinn des Meetings von vorneherein falsch verstanden. Die Entwickler informieren sich gegenseitig, was sie gerade machen und zu machen planen, nicht wie weit sie mit einer Story oder Aufgabe gerade sind. Die Fragen wie lange etwas noch dauert oder wann etwas fertig ist gehören nicht ins Daily! Dass solche Fragen natĂŒrlich doch aufkommen, liegt mal an Command-and-Control-Strukturen, die die EinfĂŒhrung von Scrum ĂŒberdauert haben, mal an fehlenden Rahmenbedingungen, die durch das Scrum eigentlich gesetzt sein sollten. Eine nicht besetzte Scrum-Master-Stelle bspw. deutet schon an, dass die Sache in die falsche Richtung zu laufen droht. Er wĂ€re es, der ein Daily moderiert und aufkeimende Konflikte schlichtet. Fehlt er, muss entweder ein Teammitglied oder gar der PO die Moderation des Treffens ĂŒbernehmen, ersteres mag noch irgendwie gehen, ein moderierender PO allerdings ist ein deutliches Zeichen fĂŒr scrumfuck. Der PO hat in einem Daily qua Definition nur eine sehr passive Rolle, er soll sich lediglich selbst informieren. Und er tritt keinesfalls im Namen der Stakeholder auf und fragt, wie lange es noch dauert. Never.

Inhaltliche SchwÀchen

Aber auch das Team kann ein Daily in die falsche Richtung fĂŒhren. Nochmal, es geht ausschließlich um die drei Fragen:

–  Was habe ich seit dem letzten Daily Scrum getan?
–  Was plane ich, bis zum nĂ€chsten Daily Scrum zu tun?
–  Was hat mich bei der Arbeit behindert?

Also darum, dass sich die Teammitglieder gegenseitig informieren, was gerade gemacht wird. Eben um es zu wissen, schon mal gehört zu haben, mitzubekommen, wenn Dinge möglicherweise drohen doppelt gemacht zu werden. Falsch wĂ€re es, diese Gefahr dann aber zu diskutieren. DafĂŒr muss man sich danach Zeit nehmen, mit den Leuten, die es betrifft, um nicht alle weiter abzulenken. Es geht eben nicht darum festzustellen, an welchem Punkt der Story sich die Entwicklung gerade befindet. Nicht weil die Frage grundsĂ€tzlich nicht erlaubt wĂ€re im Scrum, nur eben nicht in diesem Meeting. Abweichungen vom Ritual, bspw. statt die genannten Fragen zu klĂ€ren, zu besprechen, wie der Stand einzelner Stories ist, ist schlicht ein Fehler. All diese Dinge lenken zu sehr vom Fokus, der thematischen Arbeit der Entwickler ab.

Technische Probleme

Immer wieder hört man, dass Scrum ĂŒber mehrere Standorte hinweg ein Problem ist, wird immer wieder betont. Genauso oft gibt es allerdings auch Teams, die behaupten, bei ihnen wĂŒrde genau das funktionieren. Die Wahrheit mag hier in der Mitte liegen, sicher aber ist, dass örtliche HĂŒrden zu technischen HĂŒrden werden, die fĂŒr Rituale wie das Daily ein Problem darstellen können. Wie schon betont, schauen sich die Entwickler wĂ€hrend des Dailies an und berichten einander. Steht dem mangelhafte Video- und Tontechnik im Wege, nervt das nicht nur wie irre, sondern es geht auch sĂ€mtlicher Verve, den so ein Meeting möglicherweise haben könnte verloren und die Empathie der teammates untereinander bleibt auf der Strecke. Kurz: die gewĂŒnschte Kommunikation lĂ€sst sich per Videoschalte sowieso schon schlecht transportieren, technische Probleme bringen das Fass regelmĂ€ĂŸig zum Überlaufen.

Ebenso problematisch ist auch, wenn vom Ritual zeitlich abgewichen wird. Das Daily sollte immer zur selben Zeit sein und es sollten pĂŒnktlich alle da sein. Es soll Teams geben, die Strafen aussprechen (oder einkassieren) fĂŒr Zu-SpĂ€t-Kommer. Nun gut
 aber auch schon ein mehrminĂŒtiges „Könnt ihr uns verstehen“ am Meeting-Beginn setzt das falsche Setting und kann auf die Dauer ein Daily zerstören. Man darf halt nie vergessen: man macht das jeden verdammten Tag.

Und nun?

Ich persönlich wĂŒrde sagen: entweder man macht es richtig oder lĂ€sst es gleich ganz bleiben. Ohne das ich eine Alternative zur Hand hĂ€tte.

Der reinen Informationspflicht kann ein geĂŒbtes Team wahrscheinlich auch per Slack-Channel nachkommen, es gibt auch Slack-Bots, die die drei Fragen tĂ€glich bei den Entwicklern abfragen und dann das Gesamtergebnis allen prĂ€sentieren. Aber auch in diesem Setting kann man noch nicht den Scrum-Master durch den Bot ersetzen, da jemand darauf achten muss, dass nicht alle immer dasselbe schreiben. Ob eine Art „Slack-Daily“ einen zeitlichen Vorteil bietet, wage ich anzuzweifeln, die Konzentration auf die drei Fragen wĂ€re allerdings gegeben. In Teams an verteilten Standorten könnte hier wirklich ein Gewinn lauern, vor allem, wenn es technische Probleme gibt, wie oben beschrieben. Empathie bringt das Ganze natĂŒrlich nicht.

Ganz darauf zu verzichten wÀre sicherlich auch ein Weg, nur dann macht man eben kein Scrum. Davon mutiert man auch nicht gleich zum microgemangeten Wasserfall, schon klar, aber hiervon ausgehend kann man mal kontrollieren gehen, wie es im restlichen Scrum-Prozess so aussieht.

Clean install fĂŒr den Mac automatisieren

Beim Thema clean install, angeregt durch macOS development environment from scratch, habe ich nochmal ein paar lose Enden eines Git zusammengerafft, die hier auf meinem Schreibtisch noch rumlagen. Denn vor dem Konfigurieren eines neuen Mac steht das ewige Programme suchen und installieren, buh! Das geht natĂŒrlich auch einfacher


Bei der Neuinstallation eines Rechners, in meinem Fall natĂŒrlich eines Apple Rechners, vor allem aber auch bei Neuanschaffung steht man immer vor dem zeitraubenden Problem, die Softwareumgebung, die man gewohnt ist, wieder-/herzustellen. Was hier das Einspielen aus Backups oder Migrationsassistenten an convienience bringt, geht oft dadurch verloren, dass man Leichen miterbt, die man auf dem neuen Rechner eigentlich nicht im Keller haben will. Was muss man also fĂŒr ein wirkliches clean install tun?

  • ZunĂ€chst mal muss man wissen, welche Software man eigentlich nutzt. Das ist bei den großen tĂ€glich verwendeten Programmen natĂŒrlich kein Problem, aber wie hieß gleich noch dieses Colorpicker-Tool, dass man nur zweimal im Halbjahr aufruft? Vielleicht will man außerdem auch einen standardisierten Rechner fĂŒr neue Kollegen bereitstellen, dann gibt es in diesem Sinne gar keine History

  • Dann muss man die ausgewĂ€hlten Programme installieren. Das kann man peu Ă  peu machen, immer wenn man ein Tool braucht: installieren, einrichten und dann erst nutzen. Oder man macht es in einem Arbeitsgang, beide Versionen benötigen viel Zeit.
  • Schließlich mĂŒssen alle Programme konfiguriert werden, Seriennummer herausgesucht und eingegeben werden, die Arbeitsumgebung eingerichtet werden usw.

Zumindest die ersten beiden ArbeitsgĂ€nge kann man am Mac heutzutage glĂŒcklicherweise automatisieren. Die Recherche, was man denn ĂŒberhaupt installieren will ist dabei natĂŒrlich ein wichtiger Punkt. Hier verlasse ich mich auf den Paketmanager Hoembrew, dessen Erweiterung Brew Bundler und die Möglichkeit den Mac Appstore via API von der Kommandozeile aus zu bedienen. Alle drei Programme gehören heutzutage auf jeden Mac. Eine Liste von mit brew installierten Systemprogrammen und Desktop-Apps, sowie der aus dem Appstore heruntergeladenen Programmen, lĂ€sst sich mit dem Bundler per brew bundler dump erstellen. Das entstandene Brewfile ist schonmal ein guter Ausgangspunkt. Sowas sieht dann so aus:

cask_args appdir: '/Applications'

tap 'caskroom/cask'
tap 'homebrew/binary'
tap 'homebrew/boneyard'
tap 'homebrew/bundle'
tap 'homebrew/core'
tap 'homebrew/versions'

brew 'mas'
brew 'wget'
brew 'youtube-dl'
brew 'zsh'
brew 'zsh-completions'
brew 'zsh-syntax-highlighting'

cask 'tower'
cask 'transmit'
cask 'vagrant'
cask 'virtualbox'

mas 'iA Writer', id: 775737590
mas 'Airmail 3', id: 918858936
Lisitng 1: Beispiel fĂŒr ein Brewfile

Mithilfe von brew search und brew cask search findet man weitere Programme, die man auch hĂ€ndisch dieser Liste hinzufĂŒgen kann. Irgendwann hat man die Liste der ultimativen Standardprogramme und derer AbhĂ€ngigkeiten zusammen. Mit einem beherzten brew bundle kann man diese dann entweder installieren oder auch allesamt installieren (oder bereits installierte updaten).

Die Installation auf einem leeren Rechner selbst kann man getrost einem Shellscript ĂŒberlassen, das auch gleich die Xcode-Tools holt und am Ende oh-my-zsh installiert etc.


#!/bin/sh
echo Install xcodeutils

xcode-select --install
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew tap Homebrew/bundle
brew bundle
sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
Listing 2: VerkĂŒrzte Version eines Installationsscripts

All das oben genannte und ein klein wenig mehr, habe ich mal in diesem Git-Repository zusammengesteckt, mit dessen Hilfe ich meinen Rechner installiert habe. Danach muss man seine Programme natĂŒrlich noch konfigurieren. Viel Spaß


Foto: alejandroescamilla auf Unsplash.

2017: UX verbessern!

Das Jahr ist noch jung, Zeit fĂŒr die guten VorsĂ€tze. Ich persönlich habe mich da zurĂŒck gehalten, ich habe mit mir genug Erfahrung, ich brauche andere AnlĂ€sse als einen Jahreswechsel, um an mir zu arbeiten. Aber fĂŒr uns alle habe ich uns etwas vorgenommen, ist das nicht nett?

Hiermit rufe ich 2017 als das Jahr der UX-Verbesserung aus und der Abschaffung jener dark patterns, die uns nun schon seit Jahren auf den Zeiger gehen.

Keiner mag sie, aber alle haben sie.

Ich rede hier von den dark ux patterns, needy design patterns und einfachen Tricks, die auf Webseiten angewendet werden, um den Nutzer zu bestimmten Aktionen zu bewegen oder ihn davon abzuhalten. Und ab und an lenken wir den Nutzer auch einfach nur vom eigentlichen Inhalt der Seite ab. Was wir damit machen? Die Verweildauer erhöhen, bestimmte Seiten im Angebot promoten, das Wiederanzeigen von Werbung triggern, Statistiken schönen, uns in die eigene Tasche lĂŒgen. In AusnahmefĂ€llen erfĂŒllen wir damit auch EU-Normen. Der Wahnsinn kennt keine Grenzen.

Was sind die Folgen?

Keine Frage, schlechte User Experience funktioniert immer wieder. Das zeigen wahrscheinlich auch die Zahlen. Aber das ist leider nur scheinbar so: denn miese Tricks fĂŒhren letztlich dazu, dass die GlaubwĂŒrdigkeit insgesamt leidet, bis der Nutzer eben nicht mehr wieder kommt. Und irgendwann dreht sich der Wind auch, so gesehen bei Adobe Flash. Das war auch mal sehr hip und hat super funktioniert


Was ist zu tun

Ich weiß, ihr könnt das jetzt nicht alles von hier auf jetzt abschalten. Aber das Jahr ist ja lang. Da kann man schon einiges tun:

  1. AufklÀren: dark UX patterns identifizieren und bekannt machen. Sprecht Eure Produktentwickler, Projektmanager oder Chefs an und zeigt ihnen wo die Probleme liegen.
  2. Alternativen aufzeigen: es gibt immer eine bessere Lösung als einen Modaldialog, also zeigt diese Wege auf und bietet sie an. Zeigt auf, dass gutes UX die GlaubwĂŒrdigkeit erhöht, vor allem in einer Zeit, in der die Mitbewerber noch miese Tricks benutzen.
  3. Strategien entwickeln: Lasst uns absprechen und uns gegenseitig Hilfen an die Hand geben. Schreibt Artikel mit guten Lösungen. Verlinkt gute Artikel. Fragen klÀren: wo können verlorene Ad-Impressions wieder hereingeholt werden? Wie beweist man, dass wir Recht haben?

Jetzt wisst ihr Bescheid



 los geht’s. 😉

Couchblog und AMP

Dieser Artikel ĂŒber AMP1, Google May Be Stealing Your Mobile Traffic, erstaunt mich ein wenig, weil er trotz seiner naiven Herangehensweise an das Thema, ziemliche Diskussionen ausgelöst hat. Andererseits, naiv ist ja irgendwie genau mein Weg, wie ich mich dem Thema bisher genĂ€hert habe, also irgendwo auch genau richtig fĂŒr mich.

ZunĂ€chst mal glaube ich nicht, dass Google mit AMP traffic stiehlt. NatĂŒrlich lĂ€uft der Datenverkehr ĂŒber Googles Cache und schlĂ€gt so nicht auf dem hauseigenen Server auf, aber gezĂ€hlt wird er, wenn man ihn zĂ€hlt, als eigene views, pageipressions, visits, whatsoever. Falls einen das groß artiginteressiert. Das ist aber der große Vorwurf des Artikels, man rufe AMP-Artikel auf und sei dann dort in einem dead end gefangen und könne als einzige Möglichkeit zurĂŒck zur Google-Suche. Das mag so sein, wenn man einfach das WordPress-Plugin installiert und einschaltet und sich nicht weiter darum kĂŒmmert, was an AMP-HTML dabei heraus kommt. Wir haben AMP fĂŒr ZEIT ONLINE implementiert und das war mehr Arbeit, als ein Plugin einzuschalten. Wir liefern eine spezielle Version unsere (responsiven) Seite aus, die, so gut es geht, die AMP-Erweiterungen nutzt, also spezielle Adtags, Imagetags und so weiter nutzt. Das WordPress-Plugin versucht die Standard-Wordpress-Elemente automatisch in AMP umzusetzen und macht das erstaunlich gut. Trotzdem kann es natĂŒrlich sein, bspw. bei selbstgestrickten Templates, dass der Ergebnis nicht so ist, wie man möchte. Das mag ein dead end produzieren, das ist dann aber eher nicht AMPs Schuld.

Ich habe mich bisher um meine AMP-Seiten auch ĂŒberhaupt nicht gekĂŒmmert, wie sie aussehen sieht man hier. Warum ich mich noch nicht darum gekĂŒmmert habe: im Moment lĂ€uft da fĂŒr mich noch nicht wirklich etwas. Derzeit gibt’s AMP-Ergebnisse im Grunde nur in Google-News und in einer speziellen Box, da lĂ€uft in der Regel nur Medienverkehr, bei ZEIT ONLINE hat das durchaus Bedeutung, fĂŒr das Couchblog heisst das bisher no amp in the moment. Eine geplante flĂ€chendeckende EinfĂŒhrung in Suchergebnissen ist zumindest international noch nicht fertig umgesetzt, aber fĂŒr das Jahresende angekĂŒndigt. Insofern hat es fĂŒr mich noch keine Relevanz.

Was mich wirklich in Sachen AMP ein wenig nervt, ist was auch in diesem Kommentar eines AMP-Entwicklers nochmal durchscheint, nĂ€mlich dass AMPs ja auch an anderen Stellen als nur der Google Suche erscheinen könnten, bspw. in Twitter oder Pinterest. Twitter ist seit den ersten AMP-Tagen immer mal wieder genannt worden, ausser in twitter moments ist davon aber weit und breit nichts zu sehen. Das ist gelinde gesagt sehr schade, weil mit höherer Verbreitung der AMP natĂŒrlich auch das Ansehen steigen wĂŒrde und sich zeigen wĂŒrde, dass es um mehr geht, als Content fĂŒr die Google Suche zur VerfĂŒgung zu stellen. Dabei sind AMP, wenn sie sich verbreiten, einerseits eine wundervolle und vor allem offene Alternative zu Facebook Instant Articles, andererseits ein guter Satz Daumenschrauben, die Google mit dem Suchtraffic als Pfand den krankhaft langsamen Newswebseiten anlegen kann. Zusammengenommen ein guter Schritt in Richtung schnelleres Web.

Bild: William Bout

Update: Nach lĂ€ngerem Test habe ich die AMP-UnterstĂŒtzung wieder dran gegeben.


  1. AMP, Accelerated Mobile Pages, ist ein Projekt, das Google angestossen hat (es ist open source), um das mobile Wen schneller zu machen. In der Hauptsache besteht es aus einem eingeschrĂ€nkten HTML-Satz, vordefinierten Javascripten und einem fetten Caching 

Javascriptökologie

Schön, selten habe ich ĂŒber einen satiren Beitrag ĂŒber das javascript ecosystem, die Javascriptökologie mithin, so gelacht, wie ĂŒber How it feels to learn javascript in 2016. Und ebenso selten habe ich mich zumindest so gut teilverstanden gefĂŒhlt, wie bei Bastian Allgeiers Gedanken dazu. Mit diesen beiden Links könnte dieser Artikel nun enden, aber hey


Selbst habe ich natĂŒrlich auch ein paar Gedanken dazu. ZunĂ€chst mal gefĂ€llt mir Allgeiers Musikinstrumenteanalogie total gut. Ich bin selbst Quereinsteiger, habe mir das meiste selbst beigebracht und lerne jeden Tag neue Dinge dazu, auch noch nach 20 Jahren. Ich spiele allerdings kein Instrument, wenn man mal Technics 1210 nicht als Instrument rechnet. Aber das mit den Instrumenten ist ja auch persönliche PrĂ€ferenz. Die Wahl eines Programmieransatzes, einer Library, oder auch schon einer Architektur ist aber nur in einem Teilaspekt Sache der persönlichen Entscheidung.

NatĂŒrlich soll jeder das Programmieren, was ihm am besten passt, womit er am besten leben kann, womit es ihm am meisten Spaß macht. Mir scheint diese einfache Aussage aber meist nur auf den EinzelkĂ€mpfer zu zutreffen, der keine RĂŒcksicht auf sein Team nehmen muss. WĂ€re ja lustig, wenn in unserem Team Moritz alles in React, Anika alles in Angular, Thomas alles in jQuery und Tobias alles in plain vanilla javascript schreiben wĂŒrde. Und ich mach dann die code reviews, oder was?! Aber natĂŒrlich kann man auch in einem Team, mit viel Diskussion, immer wieder und nochmal, herausfinden, was die Technologie ist, die fĂŒr das Team am besten passt. Mit kleinen ScharmĂŒtzeln zwischendurch.

Dann ist das aber leider immer noch nicht die Entscheidungsgrundlage, welche Frameworks, Libraries oder Toolsets einzusetzen sind. Der wichtigste Punkt nĂ€mlich ist und das fehlt mir in all den Diskussionen immer wieder, was fĂŒr die zu erledigende Aufgabe eben das richtige oder passende Tool ist. Ob ein Framework hip, cool oder square ist, spielt da nur eine sehr untergeordnete Rolle und oft leider ebenso, ob alle Lust haben es zu benutzen. Und kommt mir nicht mit einer Komfortzone.

Jetzt gleich zu Argument Nummer eins: die machen doch alle das gleiche, da kann man nach PrĂ€ferenz gehen. Nein stimmt nicht. Denn auch wenn alle Frameworks möglicherweise Ă€hnliche Ziele verfolgen, sind sie ja eben nicht gleich. Und das zeigt der satirische Artikel von Jose Aguinaga ganz hervorragend: alle bringen eine Hölle von AbhĂ€ngigkeiten mit sich. Ein Ast im Entscheidungsbaum mag ja bspw. aber sein, wie diese AbhĂ€ngigkeiten eines Frameworks aussehen und wie stabil diese sind. Und vielleicht schaut auch mal wer, ob es da Sublibraries ohne Sinn und Verstand gibt. Hier failen viele, wenn man zum Beispiel langlebige, stabile Produkte bauen will, mit einer Mindestlebensdauer von vier bis fĂŒnf Jahren.

Bei ZEIT ONLINE haben wir im Relaunch 2015 unsere Architektur versucht so zu bauen, dass man einzelne Teile leicht austauschen kann, damit wir eben nicht auf AbhĂ€ngigkeiten festgenagelt sind. Trotzdem haben wir dann danach erstaunlich wenig buzzwordgetriebene Entwicklung gemacht, sondern sind im Grunde beim alten Handwerkszeug (including the j-word) geblieben. Das liegt natĂŒrlich hauptsĂ€chlich daran, dass wir eine content getriebene Website sind, keine One-Page-App. Und das wir auf so veraltete Dinge wie progressive enhancement oder auch einfach acessibility achten wollen. Aber eben auch daran, dass wir einiges an Erfahrung bei den Architekturentscheidungen zusammengetragen haben und uns bei maximaler Entscheidungsmöglichkeiten nicht maximal abhĂ€ngig von irgendetwas machen wollten, dass morgen vielleicht schon wieder unmaintainded ist.

Update: Addi Osmani dazu.[Via.]

Bild: Markus Spiske

Schneller sein und lÀnger bleiben

Die Washington Post ist dabei ihre so called mobile experience auf eine progressive webapp umzustellen und wird dadurch lightning fast, wie sie selbst schreiben. Und ja, die Website wird dadurch tatsÀchlich sehr schnell.

Einer der ersten Nutzerkommentare dazu lautet jedoch:

I never recognized a problem with loading speed. What I do recognize is my vision going blurry after looking at it for about 10 minutes or more. That absolutely deters me from reading articles on it.

Vielleicht eine sehr subjektive Aussage, eine Mindermeinung, ist mir gar nicht so aufgefallen. Trotzdem sehr ĂŒberraschend in dem Zusammenhang.

Und das deckt sich irgendwie mit meiner Erfahrung. Na klar, schnellere Webseiten klicken besser, wissen wir alle, die Absprungsraten nach zwei Sekunden sind astronomisch und so weiter und so fort. Die Websitenutzer entscheiden solche Dinge aber ausschließlich mit den FĂŒĂŸen, will sagen: durch wegbleiben. Das ist die eine Kohorte der Nutzer. Die schnell da, schnell wieder weg Nutzer. Man will ja nicht wie ein Werbefritze klingen, aber: die schnellen User haben (noch) keine Beziehung zur Website. Sie mĂŒssen erst konvergiert werden. Und hier ist Schnelligkeit nur ein Punkt, im Grunde erstmal nur jener, der die Auswahl möglichst groß macht.

Was dann aber folgt, dĂŒrfen wir nicht aus den Augen verlieren. Irgendwo zwischen Geschwindigkeitsrausch und Werbeverschreckung muss Platz bleiben, den Nutzer vom schnellen Vorbeisurfer zu einem regelmĂ€ĂŸigen Nutzer zu machen. DafĂŒr ist natĂŒrlich vor allem der Inhalt einer Website verantwortlich, dass der Nutzer also das findet, was er sucht. Aber auch hier haben wir als Webentwickler es in der Hand, an den Reglern zu drehen: Lesbarkeit, Struktur, Informationsarchitektur, FunktionalitĂ€t bei hoher ZugĂ€nglichkeit, es gibt so viele Dinge, die man ausser Geschwindigkeit und minimalistischem Design richtig machen kann und muss. Bitte nicht vergessen: there is more to web than speed.

Foto: Steven Wei