Abends fand dann zusätzlich noch das fünfte SmashingMeetup in der Frankfurter Brotfabrik statt. In dessen Rahmen hielt ich meinen ersten englischsprachigen Vortrag. Die Slides zum Vortrag gibt es wie immer bei Slideshare bzw. hier zur Ansicht.

Für die Schulung stehen 20 Plätze bereit, die kostenlos vergeben werden, dank des Sponsors MailChimp. Auf der Meetup-Seite stehen die Teilnahmevoraussetzungen: natürlich sollte man ein Fortgeschrittener Entwickler im Frontend sein. Zum Testen des eigenen Wissens stellen wir eine kleine Testfrage, die beantwortet werden muss. Die Frage befindet sich wie ein Überblick über die Inhalte des Workshops auf der Meetup-Seite. Vielleicht sehen wir uns ja.

Das Beste an der neuen Doku ist allerdings, dass sie kompakt und praktisch ist. Die alte Doku wollte noch die technischen Grundprinzipien erklären. Das machen heute Bücher wie “Little Boxes“. In meinen diversen Schulungen und meinen Uni-Kursen hatte ich den Eindruck, dass die umfangreiche Doku mehr als Belastung denn als Segen gesehen wurde. Die neue Doku lässt hingegen einen pragmatischen Umgang mit dem Framework zu. Das kommt meiner Interpretation von YAML als “Baukasten” auch sehr viel näher.

Schön sind die neuen Beispiele, die zudem auch nicht mehr allzu starke Rücksicht auf die alten IE nehmen. Die Beispiele funktionieren allerdings selbstverständlich auch im IE6 und 7, so wie das ganze Framework. Es wird nur nicht mehr in den Vordergrund gerückt. Die Zeit schreitet schließlich voran.

Letztes Jahr im Oktober gab ich schon einen Ausblick auf YAML4:

In meinem zweiten Vortrag werde ich einen Blick auf YAML4 werfen. Ich bin gespannt, ob Dirk diese Version bis dahin veröffentlicht hat. Der Weg der Weiterentwicklung ist jedenfalls klar und ich finde das Ergebnis klasse. Es bleibt bestimmt auch Zeit, Fragen zu klären.

Was sind denn Eure “best practices”? Ich lerne gerne dazu.

Vielleicht sehen wir uns ja? Dann wisst ihr auch, warum so manche das letzte Mal ob des leckeren Essens in den Pausen stöhnten und neue Hosen kaufen mussten.

Beim Webkongress Erlangen bin ich für einen ausgefallenen Vortragenden spontan mit einer YAML-Session eingesprungen. Meine Slides gibt es wie immer auf Slideshare.

Auf dem WordCamp diesen Jahres habe ich einen ersten Einblick in ein spannendes YAML-Projekt bekommen, das vor wenigen Tagen aus der Beta-Phase kam und nun also von jedermann genutzt werden kann: das XtremeOne-Wordpress-Theme von Michael Preuß. Auf der Projektseite zeigt ein kurzer Film, wie einfach, bequem und schnell man sein eigenes Template auf YAML-Basis modifizieren und pflegen kann. Ein tolles Projekt, das viele Nutzer verdient. Die Kosten von XtremeOne sind durch schnellere und bequemere Pflege der Seite schnell wieder reingeholt.

Als Abschluß möchte ich nicht versäumen, auf ein tolles Projekt hinzuweisen, das mit YAML umgesetzt wurde: wien.at. Tomas Caspers hat hier federführend das Frontend verantwortet und YAML als Basis für eine beispielgebende, barrierefreie Seite genutzt.

Das WordCamp2010 in Berlin war als eintägige Veranstaltung organisiert. Eine ungewöhnliche Sache, vor allem wenn man berücksichtigt, daß der Veranstaltungsort Berlin zwar immer zieht, für die meisten Besucher aber doch sehr abseits liegt. Eine Anreise am Vortag ist eigentlich immer geboten. Durch ein zwangloses Kennenlernen-Treffen im Brauhaus-Mitte war das für jeden auch ein Gewinn. Aber der Sonntag hinterließ ein seltsames Gefühl. Es fehlte einfach der zweite Tag.

Die Organisatoren riefen mehrfach dazu auf, Sessionvorschläge schon frühzeitig auf der Webseite anzukündigen. Aus den Vorschlägen wurde dann ein vorläufiger Sessionplan gezimmert. Das ist eine prima Sache, um sich inhaltlich einzustimmen und um eventuell den Chef zu überzeugen, daß ein Besuch eine gute Idee wäre. Denn will man sich eine Konferenz bezahlen lassen kommt es immer besser, mit konkreten Plänen zu winken als mit der Idee, daß sich alles schon von selber gut regulieren werde. Die Vorläufigkeit dieses Plans hatte aber offenbar nicht jeder verstanden, denn Michael Jendryschik wurde von einem Teilnehmer auf das Übelste beschimpft, weil er seine Session um eine Stunde verlegte, um nicht gegen Vladimir Simovic anzutreten, dessen Session ihn selber interessierte. Da hatte jemand offenbar die Dynamik eines Barcamps nicht begriffen.

Die Sessions

Der Tag begann für mich mit einer Session von Vladimir Simovic. Er sprach über Performancebremsen bei Wordpress-Blogs. Anfangs dachte ich, ich würde zum wiederholten Male die allgemein bekannten Erkenntnisse hören. Doch recht schnell schwenkte Vlad von den allgemeinen Regeln zu sehr spezifischen Erkenntnissen um. Immer mit einer Prise Humor gab er viele praxisrelevante Tips. Ich hoffe sehr, daß er die Überarbeitung seiner Folien bald fertig hat, daß er sie öffentlich zur Verfügung stellen kann. Bis dahin lohnen sich auch seine Blogartikel über Performance.

In der nächsten Session sprach Michael Jendryschik über media-queries. Ein sehr neues und sehr interessantes Thema, dem wir uns sicherlich in nicht allzu ferner Zukunft häufiger widmen werden. Auch wenn die IEs bis inklusive Version 8 mit media-queries nichts anfangen können, sind sie doch eine prima Möglichkeit, um modernen Browsern und vor allem Browsern auf Smartphones kontextabhängige Styles zu liefern. Die gewählten Beispiele waren klasse und haben Lust auf eigene Experimente gemacht.

Vor der Mittagspause ließ ich mir von Thomas Boley seine Template-Engine TempELA erläutern. Gedacht ist die Engine nicht für ganze Themes, sondern für Plugins und Widgets. Sein Bestreben nach sauberem Code kann ich natürlich nur unterstützen.

Nach dem Mittagessen gab uns Sylvia Eggerts Session eine Analyse des Stands der Barrierefreiheit im aktuellen Wordpress 3.0-Standardtheme. Man kann ihre Erkenntnisse wohl so auf den Punkt bringen: das neue Theme führt die Barrieren des alten fort. Das Theme weist wenige Barrieren auf, aber an den Farbkontrasten wie an der Visualisierung der Tastaturnutzung könnte noch gearbeitet werden. Alles in allem finde ich die Ausgangslage aber richtig gut.

Bevor das WordCamp zu Gunsten des WM-Spiels gegen Argentinien unterbrochen wurde, wohnte ich noch der Session von Michael Preuß bei. Michael zeigte sein Theme-Framework, das auf Basis von YAML entstanden ist und ab Wordpress 3.0 laufen wird. Ich bin sehr gespannt darauf, es zu testen. Mit Hilfe dieses Frameworks kann man sich sein YAML-basiertes Layout im Prinzip im Backend zusammenstellen. Selbst wichtige Plugins liefert Michael in eigener Machart mit. Das Framework hat nicht nur mich, sondern auch den neben mir sitzenden YAML-Vater Dirk Jesse so begeistert, daß wir über die Diskussion mit Michael den Anstoss des Spiels ignorierten. Das erste Tor konnten wir so nur in der Wiederholung bejubeln.

Nur ein Tag

Das WordCamp 2010 war als eintägige Veranstaltung konzipiert. Das ist sehr schade. Die meisten werden von weither gekommen sein – Berlin ist schließlich am Rande Deutschlands – und hätten einen zweiten Tag gut nutzen können. Denn eine Übernachtung war ja sowieso drin. Aber auch das Thema gibt viel Stoff her und ein zweiter Tag, vielleicht sogar mit Praxisworkshops, wär sinnvoll und schnell gefüllt gewesen.

Die Location

Ich war sehr gespannt, als ich hörte, wir würden in einer Coworking-Area tagen. Das Konzept finde ich klasse und habe auch schon einiges über die Frankfurter Coworking-Area gehört. Ich hoffe, nicht alle Coworking-Areas sind so, wie das Betahaus. Das Gebäude hatte den Charme eines vor etwa 20 Jahren verlassenen Lagerhauses, das notdürftig von ein paar Hausbesetzern wieder hergerichtet wurde. Für die Tagung selber war mir das allerdings herzlich egal.

Allerdings fehlten in den oberen Räumen und im Foyer eindeutig Mikrofone und Lautsprecher. Die Vorstellung der Sessions war bei mieser Akkustik und zu lauten Teilnehmer größtenteils gar nicht zu verstehen. Bei Vlads Session hätten die doppelte Anzahl Stühle stehen dürfen. Platz wäre genug gewesen. Der Verzicht auf Tische führte zumindest dazu, daß sich weniger Menschen nebenbei noch am Rechner betätigten.

Verpflegung

Ein Barcamp und so auch das WordCamp ist eine kostenlose Veranstaltung. Dementsprechend schraube ich meine Erwartungen niedrig. Zwar hatten meine letzten Barcamps alle eine geniale Verpflegung morgens und den ganzen Tag über, aber ich erwarte dies nie. Das WordCamp bot kein Frühstück, also nahm ich das meines Hotels in Anspruch. Allerdings hätte es etwas Leckeres im Betahaus gegeben. Es wurde leider verabsäumt, dies zu kommunizieren. Ich hätte lieber dort als in meinem Hotel das Geld gelassen.

Etwas ungünstig war die Verpflegungssituation in der Mittagszeit. Der Schnell-Vietnamese, den ich mir mit anderen aussuchte war lecker, aber nicht schnell und etwa 5 Minuten Fußweg entfernt. So kam ich mindestens 10 Minuten zu Sylvias Vortrag zu spät.

WLAN

Die Versorgung mit Internetzugängen ist auf Barcamps immer wieder ein leidiges Thema. Da ich meinen Surfstick im Hotel vergessen hatte, betraf die Unterversorgung auch mich. Es gab einige wenige Glückliche, die von Anfang an Internetzugang hatten. Im Laufe des Tages sollte sich die Lage gebessert haben. Mich interessierte das nicht mehr. Ich stellte fest, daß es viel mehr Spaß macht, den Vortragenden zuzuhören und mit ihnen zu sprechen, als dauernd zu twittern.

Diskussionsfreudigkeit

Alle von mir besuchten Sessions wurden immer wieder von Fragen und Bemerkungen der Teilnehmer bereichert. So sollte es sein, es sollte ein offener Dialog entstehen. Ich fand diese Offenheit und das Engangement aller Teilnehmer sehr angenehm und bereichernd.

Sessionplan

Anfangs wurde der immer aktuell gehaltene Sessionplan auf die Wand im Foyer per Beamer geworfen. Dank des schlechten WLANs war dies für die meisten die einzige Möglichkeit, auf den Plan zuzugreifen. Vier von fünf Räumen befanden sich im vierten Stock. Dort gab es aber leider keinen Plan. Der Aufzug wiederum war sehr langsam und es gab für alle 200 Teilnehmer auch nur diesen einen Aufzug. Nach einer Session herunterzufahren oder zu laufen um danach dann wieder den Weg zurück anzutreten ist aber keine tolle Idee.

Nach dem Mittagessen wurden im Foyer die Stühle für die Fußballübertragung aufgebaut und der Beamer wurde für das Fernsehbild eingerichtet. Dadurch gab es nach dem Mittagessen keinen Sessionplan mehr für mich. Das war sehr bedauerlich.

Fazit

Ich habe viele Kleinigkeiten gelernt, habe ein paar interessante Menschen kennengelernt oder wiedergetroffen. Deshalb wäre ich bei einem erneuten WordCamp dabei. Egal wo es stattfinden wird, abgeterennte Räume mit nicht allzu schlechter Akkustik und zusätzlich Mikrofon/Lautsprecher sollten drin sein. Das WLAN sollte genügend Nutzer vertragen und der Sessionplan auch mal in nicht-digital vorliegen, damit man nicht von Strom, Rechner, Internetzugang und Beamer abhänging ist

Seit Jahren werbe ich immer wieder für die Nutzung von YAML. Nicht, weil ich dafür Geld bekäm, sondern weil ich die Nutzung eines Frameworks für sinnvoll erachte und YAML für das Beste der derzeit existierenden halte. YAML wird dabei immer wieder vorgeworfen, es sei so “schwer” und habe einen zu komplexen Code. Abwechselnd wird von DIVitis oder DIV-Wahnsinn gesprochen. Ihre dauernde Wiederholung macht allerdings diese Behauptungen nicht wahrer. Die Kritiken zeugen in meinen Augen davon, daß das Konzept von YAML nicht verstanden wurde.

YAML bietet von Anfang an erst einmal alles. Der Trick besteht darin, das Unnötige wegzunehmen. So gehe ich auch in meinem Entwicklungsframework vor. Ich kann gut verstehen, daß das gewöhnungsbedürftig ist. Die Alternative wäre, eine ganz grobe Vorlage zu haben, in die man dann die benötigten Einzelteile einfügt. Das liefert mir prinzipiell jeder gute Editor, dafür brauche ich kein Framework. Zudem benötige ich einen Ort und eine Ordnungsmethode, um meine hinzuzufügednen Einzelteile zu finden und dann in meine neu entstehende Webseite einzufügen. Auch in diesem Falle benötige ich eine Art Framework-Grundlage. Ich bevorzuge, alle wichtigen Dateien und Skripte an einem Platz zu haben, so daß ich sie jederzeit anwenden kann, und die unnötigen am Ende schnell zu löschen.

Dirk Jesse schachelt bei YAML alle Layoutcontainer doppelt. Ich denke, es ist dieser Umstand, den viele kritisieren. Doch hinter der Verschachtelung steckt Sinn. Dirk entwickelt YAML immer mit dem Gedanken an flexible Layouts im Hinterkopf. Wenn man dementsprechend einem Container eine Breite in Prozent gibt, kann man ihm schwerlich ein Padding in Pixeln oder em geben. Schachtelt man nun einen Container in den Äußeren, dann gibt der Äußere die Breite vor und der Innere erzeugt über Padding oder Margin Abstände für die dann folgenden Inhalte. Natürlich kann ich auch den inneren Inhalten diese Abstände zuweisen. Doch das bedeutet mehr Schreibarbeit, schlechtere Wartbarkeit und weniger Flexibilität. Über die Verschachtelung ist sichergestellt, daß die Inhalte auf alle Fälle die korrekten Abstände bekommen. Zudem ist es egal, welche Inhalte in den inneren Container geschachtelt werden, sie bekommen immer den richtigen Abstand.

Die meisten Entwickler werden hingegen fixe Layouts mit Pixelbreiten erschaffen. Bei einem fixen Layout wird der innere Container nicht mehr zwangsweise für die Abstände benötigt. In diesem Falle kann man die inneren Container löschen. Das gilt für die Spaltencontainer #col1, #col2 und #col3 genauso wie für die diversen Subcolumns, also die Gridbausteine. Ohne die inneren Container kann man nicht mehr ernsthaft von DIVitits sprechen. Eine Lösung hingegen, in der ich Einheiten für Breiten und Abstände mische, kann ich schwerlich ohne zusätzliche Container lösen. Ich beglückwünsche jeden, der es dennoch geschafft hat. Ich wüßte dann aber auch gerne, ob die Lösung allgemein funktioniert, komplexe Layouts zuläßt und wie lange es gedauert hat, bis man auf sie kam.

Man kann also unter bestimmten Umständen die Struktur straffen. Andere Umstände erfordern hingegen diese verschachtelte Struktur. Denn abseits des Falles eines flexiblen Layouts gibt es genügend Gestaltungsideen, die einen zusätzlichen Container erfordern. Es dürfte schwerlich möglich sein, den Kunden zu erklären, man könne jetzt bedauerlicherweise sein Wunschlayout nicht erstellen, weil man dafür einen semantisch unnötigen Container einfügen müsse.

Ich denke, die Struktur können wir als nicht zu sehr aufgeblasen abhaken. Wie steht es nun mit dem CSS? YAML benötigt zwei Dateien, um zu funktionieren. Jede weitere Datei gehört zum individuellen Layout. Die slim_base.css hat 2,34 KB und hält damit für ziemlich viele Problemfälle Lösungen parat. Wer will, kann sich die Datei noch um die wenigen Einträge kürzen, die er definitv nicht benötigt wird. Man sollte dabei aber wissen was man tut. Angesichts der geringen Dateigröße halte ich eine solche händische Straffung allerdings für albern. Alle IE bis einschließlich Version 7 müssen 5 KB CSS-Dateien laden, da für sie ein separates Patchfile hinzukommt. (Siehe Dirks Artikel über YAML 3.2.)

Ich kann beim besten Willen an diesen Werten nichts Schlimmes entdecken. Die genannten Dateien sind eine Sammlung von Best Practices, an denen man schwerlich vorbeikommen wird. Es ist natürlich etwas Anderes, wenn man solche CSS-Dateien selber zusammensucht. Doch wird dies kaum über einen kurzen Zeitraum geschehen. Man wird seine selbst zusammengestellten Best Practices also nicht zwangsweise besser kennen, als man die YAML-Dateien kennen kann, wenn man sich einmal mit ihnen beschäftigt hat. In meinen Augen unterscheidet sich YAML von den anderen Frameworks dadurch, daß es auf Anwender setzt, die sich mit dem Code auseinandersetzen wollen und können. Es ist nicht einfach nur zum Anwenden da, wie die diversen Grid-Frameworks. YAML will erkundet, erforscht, erobert werden.

Wer sich also mit dem System beschäftigt, wird schnell die Vorteile erkennen. Ich habe mein gesamtes bisheriges Berufsleben meinen eigenen Code geschrieben. Bei meinem letzten Großprojekt für SinnerSchrader habe ich sogar ein eigenes kleines CSS-Framework geschrieben, das uns die Arbeit sehr erleichterte. Dieses war allerdings auf den Nutzungskontext zugeschnitten. Ich genieße es derzeit, daß mir YAML alle Gedanken um das Grundlayout abnimmt und ich mich um die eigentlichen Problemfälle der Entwürfe kümmern kann, von denen es noch genügend gibt.

Die Nutzung eines Frameworks hat für mich im wesentlichen folgende Vorteile:

• Ich kann mich auf Designdetails konzentrieren, weil die groben Probleme browserübergreifend schon gelöst sind.
• Für alle grundlegenden Seitenelemente gibt es eine festgelegte Notation, sodaß ich mir persönlich weder eine eigene ausdenken muss, noch die Gefahr habe, in ein paar Jahren meinen Code nicht mehr spontan zu verstehen.
• Durch die einheitliche Notation können Fremde meinen Code leichter verstehen und meine Arbeit übernehmen.
• Dadurch wird auch die Arbeit im Team stark erleichtert.
• YAML kommt mit einer ausführlichen Dokumentation. Jedes meiner Projekte hat nun also eine Basis-Dokumentation.
• Über allem steht in meinen Augen die Effizienz. Mit einem Framework erstellter Code ist effizient, denn viele Gedanken und Fehlersuchen erübrigen sich. Die Ersparnis ist nicht nur Zeit, sondern bares Geld.

Die Sorge um unnötige DIV-Container finde ich zudem übertrieben. Ich habe eher den Eindruck, es ist ein vorgeschobenes Argument. Und es wird schwer, solche unnötigen Container immer und überall zu identifizieren. Semantisch sind sicherlich sehr viele DIV-Container sinnlos. Sie machen semantisch da Sinn, wo sie eine Webseite in Bereiche unterteilen. Doch leider ist die Frontendentwicklung kein idealer Ort und wir können Layouts nicht der reinen Lehre nach nur mit CSS-Mitteln bewerkstelligen. Wir benötigen immer wieder zusätzliche DIV-Container, um Layouts zu erreichen. Das kann man kritisieren, outet sich dann aber in meinen Augen als Förderer schlichter Textwüsten.

Viele Seiten sind zudem keine simplen Bloglayouts oder einfache Seiten, die von einer Person für eine andere erstellt werden. Große Seiten werden von einem Redaktionsteam betreut, bekommen Daten von aussen angeliefert, bekommen oft Werbung von aussen eingebunden und sollen vielleicht sogar ein flexibel anpassbares Design haben. Wer all dies bewerkstelligen muss, der ist über das eine oder andere zusätzliche DIV sehr froh, das ihm die Arbeit sehr erleichtert. Die zusätzlichen 11 Byte tun weder dem Entwickler, noch dem Nutzer weh.

In Deutschland haben immer mehr Auftraggeber den zeit- und geldsparenden Effekt von Frameworks begriffen und fragen konkret nach einer Umsetzung mit YAML nach. Das hat für sie den großen Vorteil, daß sie den Frontendcode von anderen Entwicklern einfacher warten lassen können, wenn sie es aus welchen Gründen auch immer wollen. Ich sehe derzeit keine Veranlassung, wieder zu meinen alten Methoden zurückzukehren und meinen Code komplett selber zu schreiben.