Wenn man das Programmieren erlernt, dann bekommt man es sofort mit Variablen zu tun. Und das auch aus gutem Grund. Besonders zu schätzen wusste ich zu Zeiten, als ich selbst noch regelmäßig programmierte, immer die globalen Variablen. Auf die war in aller Regel verlass. Da wusste man, wenn ich deren Wert an der Stelle, wo dieser zugewiesen wurde, verändere, dann kann ich sicher sein, dass das auch an allen Stellen, wo sie verwendet werden, ihre Wirkung zeigt. Bei der für das Web so immens wichtigen Stylesheet-Sprache CSS gibt es keine Variablen. Was mich schon immer gestört hat.

Darum (na gut, sicher auch noch aus anderen Gründen) verwenden einige Web-Entwickler Sass. Sass steht für Syntactically Awesome Stylesheets und ist im Prinzip eine syntaktische Vereinfachung von CSS, wie ein Beispiel zeigt, dass ich im zugehörigen Wikipedia-Artikel gefunden habe. Zunächst der Sass-Code:


!link_color = #00F
a
 :color = !link_color


Da seht ihr auch schon den Einsatz von Variablen in Sass. Und das wird daraus, wenn Sass nach dem Coden zu CSS-Code kompiliert wurde:

a {
 color: #00F
}


Sass wird in der Regel gemeinsam mit Haml (HTML Abstraction Markup Language) eingesetzt, was ihrerseits wieder eine in der Syntax vereinfachte Variante von HTML ist. Beide haben gemeinsam, dass die Sprachen nicht nur eine Vereinfachung der Syntax mit sich bringen, sondern auch noch ein paar andere nette Sachen. Bei Sass ist das z.B. das Nesting oder die Mixins. Nestings sind im Prinzip in Selektoren geschachtelte Unter-Selektoren, die bei herkömmlichem CSS unzusammenhängend auf gleicher Ebene im Code untergebracht wurden. Was meiner Ansicht nach alles andere als gut überschaubaren Code erzeugte. Mixins wiederum sind Code-Schnipsel, die man in seinem Code wiederverwenden kann, sogar mit der Möglichkeit Parameter zu übergeben. Obendrein kann man bei Sass auch die Eigenschaften bestimmtet Selektoren an andere vererben.

Alles in allem ein feine Sache, die vor allem das Schreiben von Stylesheet-Code eleganter und schlanker macht. Ambitionierte Entwickler stehen doch auf so etwas, oder?

Der Name hat sicher historische Gründe, denn auf css-tricks.com gibt es weit mehr als nur Tricks zum Thema CSS. Besonders interessant finde ich den Download-Bereich. Dort findet man feine Tools zur Gestaltung von Websites aus den Bereichen JavaScript, Layouts/Templates, PHP und natürlich CSS.

Im Bereich JavaScript gibt es zum Beispiel das oben abgebildete InfoGrid, das mir ausgesprochen gut gefällt. Es liefert nämlich einen guten Lösungsansatz für das Problem, wenn eine Info-Tabelle eigentlich zu breit für das Layout der Content-Spalte ist. Weiter gibt es etwa bei den PHP-Sachen eine schicke Darstellung von RSS-Feeds für das iPhone und die Editable CSS3 Photo Gallery liefert eine hübsche Galerie-Ansicht, die auch Menschen mit ästhetischen Ansprüchen gefallen könnte.

Alles in allem ein sehr inspirierende Site, auch außerhalb es Download-Bereichs. Denn dort finden sich interessante Artikel und Screencasts zum Themenbereich, sowie eine ganzer Haufen an so genannten Snippets; das sind kleine, hilfreiche Code-Schnipsel für Entwickler. Außerdem gibt es noch ein Coder-Forum, in das ich aber noch nicht reingeschaut habe.

Heute ist der Tag der Webstandards … der Blue Beanie Day 2009. Die blaue Mütze soll heute ein Zeichen setzen für die Einhaltung und Anwendung allgemeiner Webstandards. Denn diese haben das Web überhaupt erst groß gemacht. Und die Einhaltung von Webstandards führt einen sehr schnell auch zu einer verbesserten Barrierefreiheit. Die ja bekanntermaßen erst in zweiter Linie was mit gehandikapten Menschen zu tun hat. Die Barrieren, die sich tagtäglich vor jedem von uns im Web aufbauen können, werden mir derzeit besonders beim Surfen via Handy bewusst.

Wissenswertes zum Thema Webstandards kam man zudem regelmäßig bei den Webkrauts lesen. Und auch das Webstandards Project setzt sich sehr für deren Einhaltung ein.

Wer mehr über die Aktionen zum Blue Beanie Day erfahren möchte, sollte mal auf t3n.de vorbei schauen.

Vor einiger Zeit gab es schon den Link zu Scrum kurz erklärt, heute folgt eine etwas längere Vorstellung des Projekt-Vorgehensmodell Scrum.  Entstanden als Trendreferat für das seitenblick-Team, nun auch im Netzlogbuch.

Der Zusammenhang zum Rugby

Eigentlich ist es etwas suspekt, dass ausgerechnet „Scrum“ (dt. Gedränge)  zum Titel für eine Methode der agilen Softwareentwicklung und Projektmanagement wurde. Es bezeichnet beim Rugby die Spielsituation, wenn sich die Stürmer der beiden Mannschaften Kopf an Kopf gegenüber stehen, aufeinander prallen und versuchen, den Ball auf martialische Art und Weise ihrer Mannschaft mit den Füßen nach hinten durch zu treten. Dabei basiert der Zusammenhang eher auf dem Versuch des Rugby-Teams, als Einheit zu agieren und den Ball immer hin und her zu spielen. Dadurch sollen Geschwindigkeit und Flexibilität erhöht werden, wie es auch bei der agilen Softwareentwicklung der Fall ist.

Agile Softwareentwicklung

Scrum ist also eine Methode für agile Softwareentwicklung und Projektmanagement. Es wird dabei versucht, den Aufwand bei der Entwicklung gering zu halten und mit wenigen Regeln auszukommen. Dadurch soll der Prozess flexibler und schlanker werden. Die Zeit, die für die Entwicklung benötigt wird, ist zweitrangig – das Ziel steht im Mittelpunkt. Außerdem werden technische und soziale Probleme, die während des Prozesses auftreten, ernst genommen und nach Lösungen gesucht. Andere agile Prozesse für Softwareentwicklung sind z.B. Extreme Programming (XP) oder Feature Driven Development (FDD).

Was ist Scrum?

Scrum selbst wurde um 1990 das erste Mal eingesetzt und hatte mit der Jahrtausendwende den Durchbruch. Inzwischen wird es weitverbreitet eingesetzt. Die Methode ist sehr kundenorientiert und setzt auf direktes Feedback zu jeder Teilaufgabe. Dadurch können Änderungen schnell umgesetzt und Bugs schnell behoben werden. Mit Scrum wird die Software oder das Produkt in Zyklen („Sprints“) entwickelt. Außerdem gibt es eine klare Rollenverteilung.

Die Rollenverteilung: Product Owner, Team und Scrum Master

Die drei Hauptakteure oder „Rollen“ sind der Product Owner, der Scrum Master und das Team. Der Product Owner stellte die fachlichen Anforderungen und legt die Prioritäten der einzelnen Teilaufgaben fest. Er definiert, welche Features und Funktionen das Endprodukt haben soll. Das Team besteht aus 5-10 Personen und entwickelt das Produkt bzw. programmiert die Software. Es organisiert sich selbst und verteilt die Aufgaben nach eigenem Ermessen. Das Team ist interdisziplinär zusammengesetzt und bildet zu jeder Aufgabe neue Unterteams. Der Scrum Master ist wie der Coach beim Rugby. Er organisiert den Ablauf und hilft dem Team eigene Lösungsmöglichkeiten für Probleme zu finden. Der Scrum Master moderiert Meetings und vermittelt zwischen Team und Product Owner. Außerdem sorgt er dafür, dass sich der Product Owner nicht in die Arbeit des Teams einmischt.

Zerlegung in kleine Häppchen: der Sprint

Scrum ist ein iterativer Prozess, d.h. es gibt einen Zyklus („Sprint“), der ständig neu durchlaufen wird. Zunächst werden alle Features, die das Produkt oder die Software später haben soll, in einer Liste, dem sog. Product-Backlog gesammelt. Die Features werden in dieser Release-Planung vom Product Owner sortiert. Das Product-Backlog kann sich während des Prozesses ständig ändern, neue Features kommen hinzu, andere fallen weg oder die Gewichtung einzelner Teile ändert sich.

Die Vorbereitung zum Sprint

In Absprache mit dem Product Owner entnimmt das Team regelmäßig einen Teil der hoch priorisierten Features oder auch Requirements (Anforderungen) und bildet daraus ein Arbeitpaket. Ziel des Teams ist es nun, dieses Arbeitspaket, das Increment genannt wird, innerhalb eines Zyklus komplett abzuarbeiten, inklusive Tests und der Dokumentation. Die Dauer eines Zyklus, ist genau festgelegt und beträgt i.d.R. zwischen 2 und 4 Wochen. Zu Beginn wird das Arbeitspaket in einem Sprint Planning Meeting in kleine Einzelaufgaben, die Tasks heruntergebrochen.

Tägliche Meetings während eines Zyklus

In einer weiteren Liste, dem Sprint Backlog werden die Tasks festgehalten und vom Scrum Master täglich der Fortschritt eingetragen. Dazu treffen sich die Teammitglieder einmal täglich zum Daily Scrum Meeting. Dieses Treffen dauert maximal 15 Minuten und wird meist im Stehen nach der Mittagspause abgehalten. Jedes Teammitglied beantwortet kurz aber aussagekräftig die folgenden drei Fragen: Was habe ich seit dem letzten Daily Scrum getan und bin ich damit fertig geworden, was werde ich bis zum nächsten Daily Scrum erledigen und welche Probleme haben mich bei der Arbeit blockiert? Dieses Treffen dient auch dem Austausch der Teammitglieder untereinander. Jeder soll wissen, wie der aktuelle Stand ist, woran seine Kollegen genau arbeiten und welche Probleme wodurch aufgetreten sind. Der Scrum Master notiert die Probleme im Impediment Backlog und unterstützt das Team nach dem Meeting bei der Lösungsfindung. Der Product Owner sollte bei den Treffen anwesend sein, um die aktuelle Entwicklung zu sehen, darf sich aber nicht einmischen.

Präsentation nach dem Sprint

Ist ein Zyklus oder Sprint durchlaufen folgt das Sprint Review. Dabei präsentieren die Team-Mitglieder dem Product Owner, Stakeholdern und weiteren Zuschauern das Ergebnis des Sprints. Die Präsentation erfolgt am Live-System (keine Dummies!) und dauert maximal 4 Stunden. Die Zuschauer können Feedback geben und der Product Owner hat eine Entscheidungshilfe für das weitere Vorgehen.

Rückblickende Analyse zur Verbesserung

Direkt im Anschluss setzt sich das Team mit dem Scrum Master zum Sprint Retrospective Meeting zusammen und analysiert den vergangenen Sprint. Dabei überlegt man sich, wie sich aufgetretene Probleme in Zukunft vermeiden lassen und wie man den Sprint noch weiter optimieren kann. Der Scrum Master übernimmt dabei wieder die Moderatoren-Rolle und notiert die Ergebnisse. Das Treffen dauert maximal 3 Stunden.

Regeln bei Scrum

Bei Scrum gibt es nur wenige Regeln, aber es ist wichtig, die wenigen Regeln einzuhalten, damit Scrum wirklich funktioniert und sich der Entwicklungsprozess beschleunigt. Eine dieser Regeln ist die klare Rollentrennung zwischen Product Owner, Scrum Master und Team. Product Owner und Scrum Master dürfen keinesfalls die gleiche Person sein, da Interessenskonflikte vorprogrammiert sind. Außerdem darf sich keiner in die Arbeit der anderen einmischen, es gibt keinen Chef oder Teamleiter im klassischen Sinne, alle sind gleichgestellt. Jeder hat die Freiheit selbst zu entscheiden, wie und mit welchen Mitteln er seine Aufgabe am Besten löst.

Nachteile von Scrum

Scrum kann nicht funktionieren, wenn dominante Teammitglieder die Selbstorganisation stören und z.B. Aufgaben eigenmächtig verteilen. Zudem sollten alle Teammitglieder bereits hoch qualifiziert sein, um in so schnellem Rhythmus funktionsfähige Ergebnisse liefern zu können. Ein weiterer Nachteil von Scrum ist der enge Zeitrahmen, in dem meist zu wenig Zeit für ausgiebige Tests bleibt. So kann es z.B. bei Webprojekten auch vorkommen, dass ‚Baustellen’ online gehen, was nicht immer im Sinne des Product Owners ist.

Mehr zum Thema

Im WEAVE-Magazin für Interactive Design, Konzeption und Development gab es in der Ausgabe 05/09 einen interessanten Artikel zum Thema “Scrum bei XING”. XING hat am Agile Day der JAX 2009 einen Vortrag zu deren Erfahrungen mit Scrum gehalten, den man auch bei Jax TV online ansehen kann (Dauer: 45 Minuten).

Vor 20 Jahren erfand Tim Berners-Lee das World Wide Web. In seinem nächsten Projekt möchte er ein Netz für offen zugängliche und verknüpfte Daten schaffen, das für Zahlen das erreichen könnte, was das Web für Wörter, Bilder und Videos geleistet hat: unsere Daten frei zur Verfügung zu stellen und die Art und Weise, wie wir sie verwenden und kombinieren, neu zu gestalten.

Wenn wir Websites auf ihre Tauglichkeit im Bezug auf ihre Nutzung mit mobilen Endgeräten testen, dann nutzen wir dazu in aller Regel entweder direkt den mobileOK Checker vom W3C oder das mobiReady Testing Tool.

Bei beiden Tools sollte man aber ausreichend Englisch können und die meisten, der zahlreichen Infos zur Optimierung der Mobil-Darstellung sind nur für versierte Entwickler wirklich verständlich.

Ich persönlich finde mobiReady etwas schicker, auch wenn sie bei den beispielhaft ausgewählten Handys für die emulierten Vorschauen das iPhone nicht dabei haben. Kommt aber bestimmt noch…

Zum dritten Mal nach 2003 und 2005 hat in diesem Sommer die eResult GmbH ihre Studie zur Nutzergerechte Startseiten-Gestaltung von Internetauftritten und Online-Shops namens Imagery III durchgeführt und jetzt deren Ergebnisse veröffentlicht. Die Studie als PDF-Dokument kann für für 99.- Euro zzgl. MwSt. online bestellt werden. Ein kostenlose Kurzversion ohne die Interpretationen und Schlussfolgerungen von eResult kann man in deren Download-Bereich herunterladen.

Wie in der Grafik oben am Beispiel der Werbe-Elemente zu sehen ist, gibt es immer wieder Verschiebungen in den Erwartungen der Nutzer, welche zentralen Elemente auf einer Website wo zu platzieren sind. Das und ob die Nutzer ein Element überhaupt auf einer Website erwarten, lässt sich aus dieser Studie recht gut ablesen.

Besonders interessant ist die aktuellste Ausgabe dieser Studie, da diesmal zwischen Online-Shops und anderen Internet-Auftritten unterschieden wurde. So erwarten zum Beispiel immerhin 86,4% bei einem Online-Shop einen Link zu einer Hilfe-Seite, aber nur 63,1% bei einer anderen Website.

Ich empfinde diese Art von Erhebungen als sehr hilfreich. So lassen sich schon früh im Entstehungsprozess einer Website, grundlegende Missverständnisse vermeiden, indem zentralen Elemente im Zweifelsfall eher erwartungsgemäß positioniert werden. Vielleicht kann man sich auch die Umsetzung teurer Funktionalitäten ganz ersparen, da die Nutzer sie sowieso nicht erwarten.

Einige mir gut bekannte Menschen, sind immer ganz begeistert, wenn es um die Einstellungsmöglichkeiten für den Nutzer auf der BBC-Website geht. Netterweise hat die BBC nun ihre interne JavaScript-Bibliothek unter dem Namen Glow als Open-Source veröffentlicht.

heise online zitiert den Glow-Produktmanager Stephen Elphson dahingehend, dass die Bibliothek sogar gut dokumentiert sein. Wollen wir mal hoffen, dass das auch so stimmt …

Zur Glow-Website…

Robert Basic hat am vergangenen Wochenende zum Buzzcamp eingeladen und gut 30 Leute fanden sich dann auch in Bad Homburg ein, um gemeinsam nach dem Open Space Konzept an seiner Projekt-Idee Buzzriders zu arbeiten.

Buzzriders?

Die Grundidee von Buzzriders ist, Lokales ins Web bringen. Und da es unendlich viel Lokales gibt … jede und jeder erlebt doch immer irgendwo etwas, was für das eigene Umfeld interessant ist … müssen im Prinzip alle ran.

Auf Buzzriders soll jeder und jede Meldungen, Berichte und Infos veröffentlichen können und jeder und jede soll aus diesem Pool an Beiträgen wiederum einen eigenen News-Stream erzeugen und weiterführen können. Bis hin zur eigenen kleinen Web-TV-Nachrichten-Sendung.

Und damit zeigt sich, dass die Buzzriders natürlich die ganze Bandbreite an Medienformaten nutzen können, die das Web unterstützt: Text, Bilder, Video, Audio, usw. Und ganz wichtig sind dabei zum einen der lokale Bezug und zum anderen die Möglichkeit themenbezogen zu wirken. Ein Buzzrider kann seinen News-Stream für eine Stadt, einen Stadtteil, ein Dorf oder einen Straßenzug generieren und/oder auf ein Thema bezogen. Da Buzzriders kein Non-Profit-Projekt sein wird, soll es ein Modell geben, nachdem die einzelnen Buzzriders auch ein bisschen was an den von ihnen dort eingebrachten Leistungen mitverdienen können.

Das Camp

Da alle, die zum Buzzcamp kamen, mit einem sehr von einander differenzierenden Kenntnisstand nach Bad Homburg angereist sind, auch was die Vorstellung, wie eine solche Open Space Veranstaltung ablaufen könnte, wurde am Samstag sehr viel diskutiert … und das auch nicht immer zielführend. Für mich war das völlig in Ordnung, denn ich fand, dass so ein gute Klima für Ideen entstanden ist. Der Sonntag verlief dann … mit ein paar weniger Leuten … etwas strukturierter.

Alles in Allem bin ich jetzt mal gespannt, was Robert an Erkenntnisse aus dem Wochenende ziehen wird. Er wird es uns sicher bald mitteilen. Ich für meinen Teil finde seine Vorgehensweise, die komplette Entwicklung von Buzzriders zu öffnen und alle die wollen daran partizipieren zu lassen, sehr interessant. Es wird bis zum Launch bestimmt ein bisschen länger dauern als auf dem konventionellen Weg, aber ich hab so das Gefühl, dass dieser Weg aber auch das passendere Ergebnis liefern wird.

Was erwartet den neuen Website Betreiber eigentlich?

Diese Frage stellt Anne-Kathrin Merz auf ihrem Blog mediamind in ihrem Beitrag Pflichtveranstaltung für alle diejenigen an den Anfang aller Überlegungen im Bezug auf die Nutzung des Webs, indem sie sagt:

Diese Frage, so denke ich mir, muss lückenlos geklärt sein, bevor irgendein erster Schritt getan und ein Gedanke an einen Internetauftritt verschwendet wird.

Ein lesenswerter Artikel, und zwar nicht nur für die Menschen, die im Endeffekt eine Website gestalten bzw. umsetzen. Sondern auch für alle, die mit dem Gedanken spielen, einen Dienstleister eben mit einer solchen Aufgabe betreuen wollen. Anne-Kathrin hat für die potentiellen Website-Betreiber auch ein Liste mit aufklärenden Punkten zusammengestellt:

• Wer eine Website möchte, braucht eine Strategie
• Die Konkurrenz im Web ist noch größer als auf der Straße
• Der Besucher klickt weg, wenn es ihm nicht gefällt und es wird ihn niemand aufhalten können
• Pro Suchanfrage gibt es nur einen Platz 1 bei Google
• Suchmaschinenoptimierung und Marketing geht etwas an
• Ein CMS macht es einfacher, – mehr aber auch nicht
• Inhalte schreiben sich nicht von alleine
• ein erfolgreicher Internetauftritt bedarf einer gewissen Pflege
• ein lebendiger Internetauftritt bedeutet Verantwortung
• Usability ist eine Notwendigkeit, positive User Experience ist ein Mehrwert, fehlt beides, ist es ein Killer

Interessant finde ich auch den zugehörigen Kommentar von Wolfgang:

Hört sich doch auch überall so an, als ob es (fast) nichts kostet. Der Web-Editor,die Bildbearbeitung, das CMS …OK, das Hosting kostet ein paar Euro im Monat. Klingt doch toll,oder? Jeder fast umsonst im Internet.

Du hast schon recht, kaufmännisch sauber gerechnet kostet auch eine kleine Web-Site sauber aufgebaut (egal ob nur mit kundigen Angestelten oder mit externer Hilfe) eine hohe 4-stellige Summe. Punkt.

Anne-Katrin und Wolfgang – wie recht ihr doch habt.

Via patrics@twitter