Verlinkt XXXIII

Relounge

Bewerben

Javascript

  • Sowas mag ich ja: Paul Irisch hat eine Liste zusammengestellt »What forces layout / reflow« und uns da wieder viel Arbeit abgenommen. Was mich wieder zu der Frage führt, wann unsere Webdev-Nomenklatura eigentlich mal schläft, oder Urlaub macht…

CSS

  • Kann man mir auch nicht nachsagen, ein Freund von CSS-Frameworks zu sein. Trotzdem finde ich Pure.css wirklich sehr sehr nett. So pur eben.

Nö.

Nö, Felix.

Es ist ja nachgerade höchsterstaunlich, wie man jemanden in (zumindest gespielte) Aufregung versetzen kann, in dem man ihm mit aller gebotenen Knappheit vor Augen führt, dass er Quark redet. In diesem Fall entsprang die Knappheit der Aussage zwar eher den äußeren Umständen: Zugfahrt, Edge, keine Zeit gleich per Artikel zu antworten, keinen Bock auf Disques-Kommentare (und mobil funktionieren die auch nur bei LTE glaube ich), also Twitter, aber auf 140 Zeichen kann ich das auch nicht erklären, Ende. Ich hätte auch schreiben können: „Ey Felix alter Bartträger, ich hab gerade keine Zeit zu antworten, schau doch nochmal genau nach.“ Und Felix hätte mich fragen können: „Hey Nico, ich schätze Deine Arbeit und ZEIT ONLINE, ich hab hier aber etwas entdeckt, und bevor ich das jetzt in die Welt hinausposaune und es am Ende gar nicht stimmt…“, aber hey, wir sind Blogger, oder nicht?!

So, und nun nochmal für alle zum mitschreiben: obwohl das Gerücht geht, dass wir Verlagsleute total bekloppt und degenerierte Volldeppen sind, sind wir doch nicht so blöd, so etwas wie einen nativen Adblocker in unsere Seite zu bauen. Überraschung. Stattdessen haben wir uns sehr lange und ausgiebig Gedanken machen und viele viele viele Zeilen Code schreiben müssen, um zwei komplett konträre Systeme: eine moderne responsive Website und völlig antike pixelgebundene Bannerwerbung so miteinander zu verbinden, dass es für Werbekunden und Nutzer gleichermaßen funktioniert.

Was also in Wahrheit passiert ist, dass auf ZEIT ONLINE je nach Gerät, Browser- oder Bildschirmgröße die passenden Ads geladen werden und zwar zum Zeitpunkt des Ladens. Verändert man die Fenstergröße, werden diese geladenen Ads mitunter ausgeblendet, damit sie nicht das sich an die Umgebung anpassende Design zerstören. Damit sind sie natürlich keinesfalls geblockt. Inzwischen könnten wir an diesen Stellen passende Ads on the fly nachladen, aber darauf haben wir erstmal verzichtet, weil wir es tatsächlich nicht für den häufigsten Anwendungsfall halten, das Leute ihr Fenster auf und zu machen.

Das alles sind natürlich nur Kompromisse. Leider gibt es noch so gut wie keine responsiven Ads auf dem deutschen Markt, eher nur zwei Formen, desktop und mobile. Und ebenso schlimm ist, dass es so viel aussen liegende Werbung gibt (Walppaper, Fireplace), die die Maximalbreite einer Seite plump einschränken. Und dann ist das alles natürlich auch noch fehleranfällig, es konnten nicht alle Werbeplätze eins zu eins übernommen werden und und und. Allerdings sind uns die Kollegen von der werbeschaltenden Zunft auch schon ein paar Schritte entgegen gekommen, bspw. durch endlich nicht mehr blockende Ads: es kommt also erst der Content, dann die Werbung. Das schon angesprochene Nachladen von Ads ermöglicht uns endlich wieder bedienbare Bildergalerien.

TL;DR: Wer also Werbung auf ZEIT ONLINE nicht sehen will, der kann nach jedem Seitenload schnell die Größe seines Browserfensters ändern und währenddessen solange wonaders hinschauen. Blocken tut er damit aber nichts, ausser vielleicht den eigenen Lesegenuss…

Post-Launch-Depression

Die Post-Launch-Depression (PLD) ist eine unter Webentwicklern bekannte psychotraumatische Erfahrung, die den Entwickler gerne in jenem Moment kurzer Unaufmerksamkeit von hinten anfällt, wenn er gerade eben das Produkt, an dem man viele Monate gearbeitet hat, in die Freiheit entlässt. Schwierigkeiten bei diesem Ereignis, wenn also das Baby nicht so richtig ans Licht der Welt will und sich lieber im Server zu verkriechen sucht, bereiten für die PLD das Terrain besonders gut vor. In diesen Momenten ist der Entwickler besonders angreifbar.

Symptome der PLD sind unter anderem eine geistige Abkopplung des Entwicklers von seinem Produkt. Es gehört ja nun auch nicht mehr ihm (und seiner Gilde) alleine, viel mehr muss er es nun mit der breiten und mithin undankbaren Masse von Nutzern teilen, die sich allesamt allerhöchstens für das Aussehen interessieren, oder das auch alle Knöpfchen schön pling pling machen und am allermeisten eigentlich dafür, dass zwar alles neu und modern sein soll, dem Grunde nach sich aber nichts verändern soll. In einem Jahr Entwicklungszeit hat der Entwickler derart viele Wasch-mir-den-Pelz-aber-mach-mich-nicht-nass-Situation erlebt, dass er der Bipolarität der Nutzermasse nur höchst gleichgültig gegenüber steht, was dann schon eine Ausdruck der PLD ist, denn er hat ja ein Jahr oder länger für die Nutzer gekämpft. Hunderttausend Details bleiben aber natürlich immer nur Details und die werden dort draussen selten betrachtet. Aber auch schon die Formulierung „dort draussen“ deutet auf eine schwere PLD hin. In einer recht aufwendigen Differentialdiagnose muss die PLD übrigens gegen andere in dieser Phase auftretenden Entwicklerkrankheiten wie der akuten Unlust, dem Teamstockholmsyndrom und dem *designerium homicerium“—der Lust Designer zu ermorden—abgegrenzt werden. Ein Zusammentreffen von PLD und Teamstockholmsyndrom ist übrigens keinesfalls unüblich, ganze Teams oder Abteilungen sind schon so der PLD zum Opfer geworden. Hier ist äußerste Vorsicht geboten und die Erkrankten sind in eine strenge Quarantäne—auch bekannt als Überstundenausgleich—zu nehmen.

Was hilft jedoch gegen die PLD? Wenn sie erst mal eingetreten ist leider nicht mehr so viel. Dann hilft nur warten, den Entwickler mit neuen Projekten (aber nichts Wichtiges bitte, die Gefahr des Scheiterns ist in dieser Phase hochprozentig) zu zuschütten und vor allem Alkohol. Am besten feiert man den geglückten Launch zwischen vier und sechs Mal und achte dabei darauf, die Entwickler ordentlich mit Bier und Champus abzufüllen. Danach sollte das PLD nach ca. vier bis sechs Wochen langsam abklingen. Ebenfalls als hilfreich haben sich agile Entwicklungsmethoden erwiesen. Der moderne agile Prozess an sich kennt ja keinen Launch, allenfalls den permanenten. Wenn sie es schaffen, am Tag nachdem ihre Website endlich online gegangen ist, so zu tun als wäre nichts passiert—einfach ganz normal ein daily machen—dann bemerkt Entwickler frühestens in der nächsten Review, dass sich irgendetwas verändert hat. Wenn dann die Retro geschickt um zwei, drei Wochen verschleppt wird, ist der Entwickler schon wieder viel zu sehr mit anderen Dingen beschäftigt, um der PLD anheim zu fallen.