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