Gestern abend habe ich mir Wunderkit angesehen, das anderenorts schon als Facebook für Produktivität gefeiert wird. Da bin ich mir gar nicht sicher, ob diese in sich unlogische Bezeichnung nun ein Lob oder Beschimpfung sein soll. Mal schauen…

6Wunderkinder kennt man ja schon von der kostenlosen ToDo-App Wunderlist, die ich durchaus auch genutzt habe, bis ich zu Asana gewechselt bin, ebenfalls ein Online-ToDoList-Tool mit Teamkollaboration. Ich bin also durchaus vorbelastet. Was man schon auf der Wunderkit-Landingpage merkt, setzt sich auch innerhalb der Web-App fort: Wunderkit sieht super aus, ist ordentlich und ansprechend designt, etwas Skeuomorphismus, feine Icons, in der Beziehung hat man glaube ich alles richtig gemacht. Denn, es gibt eigentlich wenig Gründe, warum Produktivität nicht auch mit dem Auge gefälligen Tools erreicht werden kann, der Charme von OpenOffice gehört in das vergangene Jahrzehnt.

Bleibt die Frage, was man denn nun eigentlich in Wunderkit machen kann. Zunächst mal natürlich: ToDo-Listen führen. Das war zu erwarten und, da bin ich vielleicht ein wenig konservativ, ich würde solche Listen allein noch nicht als Projektmanagement verstehen wollen. Natürlich ist da aber auch noch ein wenig mehr.

Der Nutzer kann in Wunderkit sogenannte Workspaces anlegen. Diese beinhalten eine beliebige Anzahl an ToDo-Listen, einen Abschnitt mit Notizen und ein Dashboard, auf dem der Workspace verwaltet wird und Statusupdates etc. über den aktuellen Workspace geschrieben und angezeigt werden. Diese drei sogenannten Apps stehen also per Workspace zur Verfügung, da können aber in Zukunft noch weitere dazu kommen, dazu später mehr.

Ein Workspace kann als öffentlich oder privat eingestellt werden. Beiden Arten können per Einladung Mitarbeiter hinzugefügt werden. Dies haben gleichberechtigten Zugriff auf die Apps, können Tasks eintragen und verwalten, Notizen schreiben etc., eben kollaborativ miteinander arbeiten. Alle Aktionen können untereinander auch kommentiert werden. Ist der Space aber öffentlich, können andere Wunderkit-Nutzer ihm auch followen, nach dem Twitterprinzip. Diese Follower bekommen dann die öffentlichen Statusupdates des Projektes zu sehen.

Klingt vielleicht ein wenig kompliziert… ist aber durch die intuitive Oberfläche durchaus zu meistern. Was Wunderkit auf jeden Fall von ähnlichen Produkten wie bspw. Asana abhebt, ist die soziale Komponente. Wird ein User-Break-Even erreicht, kann sicherlich ein kleiner Schmelztiegel für Projektarbeit entstehen: man kann sich über die Arbeit und Projekte anderer informieren, und sich in dieser doch recht professionellen Atmosphäre untereinander kennenlernen. Das kann gut für offene Projekte sein, aber auch ein interessanter Ort für bspw. das Recruiting werden.

Hinzu kommt (und hier mag der Facebook-Vergleich am wenigsten hinken) die offensichtlich Möglichkeit von Wunderkit, in Zukunft einen Entwickler-API anzubieten, womit dann weitere Apps zu den Workspaces hinzugefügt werden könnten. Hier—das ist der unvermeindliche kurze Blick in meine Glaskugel—hat Wunderkit ein Riesenpotential und wie ich die PR der 6Wunderkinder bisher erlebt habe, werden sie eine gute Chance haben, das auch zu nutzen. Und darauf muss dann am ehesten Xing mit Angst schauen…

Da ist ein Eisbär im Raum?

Im Moment gibt es wieder viel zu lernen, in Sachen CSS. Da sind zunächst die vielen neuen Dinge, die CSS3 bringt. Durch die derzeit rasante Browserentwicklung, Polyfills oder einfache Fallbacklösungen kann man vieles davon schon heute oder wenigstens morgen gebrauchen. Dazu kommen die Learnings aus einigen Jahren intensiven Einsatzes von CSS, seit der internationalen Ächtung des Tabellenlayout ist viel passiert.

Seit CSS dem style-Attribut entwachsen ist, unterlag es lange Zeit einer eher langsamen Entwicklung. Gehemmt durch den Internet Explorer hat es ewig gedauert, bis sich CSS 2(.1) überhaupt durchgesetzt hat. Man hat lange Zeit eher mit den gegebenen Umständen hantiert, anstatt CSS weiter zu entwickeln. Die floats lösten die Tabellen ab, die CSS Hacks beherrschten die Szene lange, machten zweigleisige Entwicklung für potente und für beschränkte Browser möglich. Das Set an Techniken hat sich aber in der Menge kaum verändert, vielmehr lernten wir immer besser damit umzugehen. Dabei sind aber auch viele Standardlösungen entstanden, die heute einer genaueren Prüfung unterzogen werden müssen.

Our best practices are killing us!

Nicole Sullivan (die, nicht die) tritt derzeit mit einem Vortrag unter diesem Titel auf, den ich sehr beeindruckend finde, weil er so sehr das trifft, was ich derzeit selbst in der Praxis feststelle. Viele der best practices, die in den letzten Jahren ersonnen, gepaukt und umgesetzt wurden, klingen gut, haben sich aber in den Jahren ihres Einsatzes vielleicht gar nicht bewährt. Andere wurden von der Entwicklung überholt, wurden zur Angewohnheit. Um mal ein klassisches Beispiel aus einem anderen Bereich zu bringen: wenn Sie <script>-Blöcke in einem HTML-Document nutzen, umgeben sie den Code dann auch noch mit HTML-Kommentarzeichen? Eine Technik, die heute lange nicht mehr nötig ist. Trotzdem sieht man sie immer wieder. So geht es auch mit vielen Angewohnheiten in CSS.

Nicole Sullivan nennt viele Beispiele. Unter anderem findet sie:

• die Angabe von Schriftgrößen nicht in Pixel sei kontraproduktiv,

• etwas mehr Klassizitis wäre gar nicht so schlecht, da so lange Selektorketten vermieden würden,

• durch semantische Klassennamen würde der Codewiederholung der Weg bereitet,

• der Mythos, kein zusätzliches Markup für das Layout einführen zu dürfen, sei mehr als schädlich, da durch Container Layoutprobleme auf festgelegte Bereiche beschränkt werden könnten.

In der Praxis nicht bewährt

Da geht es ihr genau wie mir. Wenn man betrachtet, wie wirklich große Website-Projekte entstehen, stellt man fest, dass durch die genannten best practices Nötiges nur von einer Ecke des Projekts in die andere verschoben wurde. So kann man wunderbares, absolut semantisch reines HTML schreiben, ohne jegliche Layout-Divs, so klein wie nur irgend möglich, ob die Seite dadurch wirklich schneller wird? Oder übersichtlicher? Nun, das HTML natürlich schon, aber wenn wir uns anschauen, wieviel sich gegenseitig überschreibendes CSS benötigt wird, merkt schnell, das man die Komplexität nur verlagert hat. Miss Sullivans Beispiel: bei Facebook hatte man vor einem umfassenden CSS-Relaunch 706 CSS Dateien, in denen 261 Mal die gleiche Farbe blau definiert war. Do not repeat yourself?

Und dabei geht’s nicht mal darum, sich gegenseitig den schwarzen Peter zuzuschieben: Komplexität im CSS schadet allen Beteiligten, denn sie drückt auf die Performance. Mein Beispiel ist die tägliche Praxis. Bei einem großen Projekt wurden nahezu nach Lehrbuch beim Schreiben von HTML-Code (und Javascript^[1]) auf auf eine ganze Reihe best practices geachtet. Das hat zunächst mal dazu geführt, dass wir zwar schlankes HTML, aber ziemlich viel CSS (und Javascript) über die Leitungen schicken. Dabei ist die Menge an CSS und seine Komplexität eine direkte Folge der semantischen Strukturen im HTML. Aber wo im HTML bspw. nur wenige Klassen stehen, muss im CSS mit unendlich langen Selektorketten auf Elemente zugegriffen werden, was die Menge an CSS erhöht, die Geschwindigkeit des Renderings aber herabsetzt. Nach einigen Jahren ist diese Situation immer schlimmer geworden. Sie ist dabei kaum noch überschaubar, weil man praktisch nur noch mit dem Firebug entscheiden kann, welche CSS-Regel auf ein Element greift. Und die schiere Menge an Code macht es nicht besser. Abhilfe schafft da oft, einfach mal eine Klasse ins HTML zu schreiben, die direkt angesteuert wird. Und die darf dann vielleicht auch mal “blue” heissen, naja, vielleicht besser “main-color”.

CSS Refactoring?

Will man sich aber, mindestens in Teilen nun aber von dieser Praxis abwenden, dann hat man jetzt den GAU, den man eigentlich vermeiden wollte: Änderungen an der Codebasis und am CSS. Zumindest kann man das Nutzen, um die IE6-Unterstützung endgültig zu droppen und so das ganze CSS etwas zu modernisieren. So stehen nun vieler Orten viele Änderungen in Sachen CSS an. Neues hinzufügen, alte Zöpfe abschneiden. Alte Projekte auf den aktuellen Stand heben.

^[1] Noch ein Nebensatz zur Rolle von Javascript: dies wurde erstaunlicherweise viel zu oft genutzt, um die selbst gesetzten Grenzen bei HTML und CSS zu überwinden oder umgehen. Hüstel…

Hier sehen wir zunächst unsere Musterpizza (Modell: Längsgestreift), zum ersten Milestone: Grundbelag. Mitarbeiter Nico hat den Teig ordentlich vorbereitet, ausgerollt und mit Tomatensauce bestrichen.

Das belegen mit Peperonistückchen ist der nächste Projektschritt. Hier werden kurzzeitig alle Ressourcen belegt, damit es zu einem ausgewogenen und gleichmäßigen Belag kommt.

An dieser Stelle kommt das Ergebnis des Projektschrittes »Spinatbelag vorbereiten« zum Tragen. In einer flugs einberufenen Stakeholderversammlung wird der Projektverlauf an dieser Stelle überprüft. Alle Stakeholder äußern sich zufrieden (siehe Sitzungsprotokoll).

Hernach wird in einem nächsten Schritt die Pizza mit dem vorbereiteten Belag… belegt. Hier ein Bild von der Milestonesitzung.

An dieser Stelle des Projektes treten erste Probleme auf. Einzelne Stakeholder bestehen auf einem weiteren Belag der Pizza mit gewürfeltem Schafskäse, während ein anderer Teil der Ansicht ist, Schafskäse sei zwar völlig in Ordnung, müsse aber zerkrümelt werden und dann mit einer Schicht Pizza-Käse belegt werden. In endlosen Diskussionen werden beide Modelle von allen Seiten beleuchtet. Derweil kommt es zu einem langen Projektstillstand.

Am Ende setzt sich die Schafskäse-Würfel-Fraktion durch.

An dieser Stelle wird das Projektende eingeleitet. In einer kleinen Feierstunde, wird die Pizza in den Ofen geschoben und der Tag mal wieder vor dem Abend gelobt. Projektleiter Brünjes bedankt sich bei seinen Mitarbeitern für den aufopferungsvollen Einsatz und merkt an, dass die Pizza sicherlich auch ohne Pizza-Käse »eine echte Wucht werden würde«, auf die Fertigstellung könne er jedoch nicht warten, da er zum Kickoff-Meeting des nächsten wichtigen Projektes »Schokoladenpudding zum Nachtisch« abreisen müsse.

Zurück bleibt die Projektcrew, die sich inzwischen an dem Projektbeitrag der Kollegen Erdfische (hier im Bild, nein, nicht die Erdfische, sondern ihr Beitrag zu diesem Projekt) gütlich getan hat. Im Taumel der Freudenfeier verbrennt die Pizza leider im Ofen.

Na, das war ja wieder ein echt gelungenes Projekt.

You better don’t mess with the IT(aly) Crowd…

Das Programm klingt interessant, es geht mir natürlich um die Bereiche Frontenddesign und -programmierung (im weitesten Sinne allerdings) und neben viele Leuten, die ich schon kenne, freue ich mich auf Vitaly Friedman (Smashing Magazine) und Duana Nickull (Adobe).

Ich buch’ mal ein Hotel jetzt…

Inhaltlich ist das Ganze dann aber eher mau: denn es sind wirklich die ganz einfachen, offensichtlichen Fehler, die dort besprochen werden. Die man aber natürlich bleibe lassen sollte. Insofern: »Level Beginner«.

One thing I’ve come to realize is that urgency is overrated. In fact, I’ve come to believe urgency is poisonous. Urgency may get things done a few days sooner, but what does it cost in morale? Few things burn morale like urgency. Urgency is acidic.

www.37signals.com

Schreibt Jason Fried, der zur 4-Tage-Woche übergegangen ist, testweise erstmal. [via Moe in Twitter].

Bis zur 67 Minute wahrscheinlich die interessanteste Aktion…

Ein Experiment war die Sache alleine schon, weil ich mir normalerweise natürlich zu fein bin, mich in irgendeinen Fanblock zu stellen, bei Werder nicht, schon gar nicht beim HSV und eigentlich auch nicht bei den sympathischen Jungs aus dem Ostwestfälischen. Aber bei denen ist es denn sicherlich noch am kuhlsten, denn – obwohl oder eben wegen der Platzierung, sind die Arminia-Fans voll happy drauf – es war eine reine Freude. Und da man nicht sooo erfolgsverwöhnt ist, freut man sich natürlich auch über ein 1:1 auswärts, auch wenn man bis zur 82. Minute mit 1:0 im Feindesland vorne lag. Jedenfalls haben wir lustige Sachen aufs Spielfeld bzw. in die Ohren unserer Vordermänner und -frauen gegröhlt, die meisten Sachen davon hab ich nicht mal verstanden, außer: “Dein Hund ist eine Katze” und die Internationale (die kannten aber die anderen Fans wieder nicht…).

Gute Laune: den zweiten Großen zum Unentschieden gezwungen…

Selten so gelacht.

• why are we doing this?
• what problem are we solving?
• is this actually useful?
• are we adding value?
• will this change behavior?
• is there an easier way?
• what’s the opportunity cost?
• is it really worth it?

Jason Fried von 37signal, via hier sozusagen. Auch mal als Antwort hierzu zu verstehen.

Game Development is like pregnancy, you can’t throw money on it to speed things up – it happens at it’s own pace…

John Doe in jPod.

Man tausche Game gegen Web…

Wir haben mit Drupal (deutschspr. Seite: drupalcenter.de) inzwischen sehr gute Erfahrungen gesammelt und es mit Hilfe von open-source Modulen aus der Drupalcommunity und Selbstgeschriebenem (hauptsächlich gebaut von unseren Partnern bei Erdfisch) die nächste Ausbaustufe unserer Community umgesetzt und die Basis für eine modulare Weiterentwicklung gelegt. Dabei handelt es sich diesmal weniger um die berühmt berüchtigte Betaversion einer Community, sondern eher um Phase 1.

Die Kommentarcommunity hat sich dabei vom reinen Kommentarsystem für ZEIT-Artikel zu einer PLattform für lesende, nachrichteninteressierte und schreibende Besucher entwickelt. Mitglieder der Community können – wie gehabt – ZEIT-Artikel kommentieren, aber auch selbst Beiträge verfassen. Jedes Mitglied hat ein – je nach Wunsch mehr oder weniger – ausführliches Profil, mit Avatar, sprich Nutzerbild, das an jedem Artikel und Kommentar angezeigt wird. Über das interne Nachrichtensystem können die Mitglieder Nachrichten aneinander verschicken.

Ein Aktivitätsindex und ein ausgeklügeltes Bewertungssystem sollen helfen, die Perlen im »river of text« der Community zu finden, durch den Import aus der Vorläuferversion befinden sich immerhin bereits jetzt rund 177.000 Benutzer und ca. 80.000 Kommentare im System, es kommt praktisch minütlich neuer Content dazu. Auf einer Fünfpunkteskala können Beiträge, wie auch Kommentare bewertet werden. Die Bewertung eigener Artikel prägen den Bewertungsindex eines Nutzers, der in seinem Profil als durchschnittliche Bewertung abgebildet wird. Ebenfalls können später (wenn die entsprechende Menge entsprechenden Contents zusammengekommen sind) beispielsweise die bestbewerteten Nutzer für ein bestimmtes Thema errechnet werden. Mit Hilfe dieser Techniken soll sich die Community ihre Experten für bestimmte Themen selbst bewerten/errechnen: traditionell wird das Kommentarsystem der ZEIT ja von vielerlei Experten genutzt, durch die verschiedenen Indizes wird man diese Experten nun auch finden können.

Einhergehend damit wurde ein dreistufiges Stichwortsystem eingeführt: es vereint die sehr grobe Ressorteinteilung, wie sie auf den Seiten von ZEIT online genutzt wird, mit den aktuellen ZEIT online Tags und durch die Nutzer frei wählbare Stichworte. So soll eine Navigation anhand von Themen gefördert werden.

Gleichzeitig mit diesen funktionalen Änderungen, wurde ein neues, leichteres Design umgesetzt. Die viel, heiß und agressiv diskutierten Grüntöne wurde, bis auf die neue Sidebar in »Waldmeister« weitgehend zurückgedrängt…

Zur Klarstellung: der Autor arbeitet bei ZEIT online – dies ist also durchaus wonach es klingt: Werbung.

Am Wochenende ist nicht mit streikbedingten Behinderungen zu rechnen.
Freitag gilt folgender Fahrplan:
In Hamburg/Schleswig-Holstein verkehren vom Grundsatz her alle RE-Züge

www.bahn.de

Na dann…

codecandies@stripgenerator.com