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.
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.
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.
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.
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.
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.
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.
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.
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?
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
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)"
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ß…
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.
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.
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…
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:
… los geht’s. 😉
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.
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
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
