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.

Rahmenbedingungen

Jeder arbeitet in einem bestimmten Kontext, der wiederum Einfluss auf die Arbeitsweise hat. Ich entwickele als selbständiger Webentwickler vor allem Templates, die andere in ein CMS integrieren. Ich bin dementsprechend von speziellen Contentmanagementsystemen unabhängig. Würde ich in einem bestimmten CMS arbeiten, würde ich möglicherweise direkt in einer Testinstallation meine Templates entwickeln. Allerdings konnte ich auch in den Jahren bei SinnerSchrader, als ich hauptsächlich für das Enterprise CMS RedDot entwickelte, nicht sinnvoll innerhalb des CMS meine Templates entwickeln. Dafür ist das CMS zu langsam und zu umständlich in der Bedienung.

Der ständige Kontakt mit einem CMS hat mich in den letzten Jahren zum Denken in Modulen getrieben. Ich gehe an ein Layout mit der Frage, welche Inhalte gleich strukturiert und nur anders lackiert sind, damit ich diese möglichst in ein einziges Template überführen kann. Auch in meiner aktuellen Arbeitsweise bin ich bemüht, gleichförmige Seitenbestandteile möglichst auszulagern. Die Auslagerung hat dabei den großen Vorteil, daß störende Seitenbestandteile weitestgehend ausgeblendet werden, ich mich auf die notwendige Struktur konzentrieren kann und schon fast die späteren Templates schreibe.

Die Verwendung eines Frameworks

Ich möchte aus meiner täglichen Arbeit den Umgang mit YAML nicht mehr missen. Hierbei zählt für mich nicht in erster Linie das spezielle Framework, obwohl ich es das Beste unter den möglichen Optionen finde. Meine Bewertung ist Geschmackssache. Viel wichtiger finde ich, generell mit einem Framework zu arbeiten. Es hilft mir, mich auf meine eigentliche Arbeit zu konzentrieren, indem es immer wieder gesuchte Lösungen für immer wieder auftretende Probleme liefert. Ich entwickele somit auf einem soliden Fundament, dessen Bestandteile ich mir nicht selber zusammensuchen bzw. zusammenschreiben muss. Ich kann jedem nur raten, sich ein wenig Zeit zu nehmen und sich das auf sich passende Framework zu suchen. Alternativ kann man sich natürlich auch sein eigenes Framework erstellen. Doch angesichts der guten Auswahl sehe ich keine Notwendigkeit dafür.

Der Grundgedanke von Dirk Jesse bei der Schaffung von YAML kommt meiner eigenen Arbeitsweise entgegen: er bietet ein Komplettpaket an, aus dem man sich die notwendigen Elemente herauspickt und den Rest löscht. Auch ich gehe bei meinem Starterkit so vor, indem ich möglichst viele Lösungen separat sammele und dann alle bis auf die Notwendigen wieder lösche.

Sammlung von Lösungen

Ein Framework ist eine verallgemeinerte Sammlung von Problemlösungen, doch es kann nicht allen Anforderungen begegnen. Deshalb gehe ich dazu über, ergänzend zu YAML eigene Lösungen zu sammeln. Diese werden in separaten Dateien in meinem Starterkit abgelegt und werden vor der Weitergabe an den Kunden um die nichtgenutzten reduziert. Es ist mir wichtig, Standardlösungen für mich zu finden. Die meisten Elemente einer Webseite sind Standardelemente. Es macht wenig Sinn, sie jedesmal von Neuem zu erfinden oder aus alten Projekten zusammenzusuchen. Auch einmal als gut befundene jQuery-Plugins sammele ich. Ich überprüfe allerdings immer wieder, ob es eine neue Version eines genutzten Plugins gibt, damit ich von dessen Weiterentwicklung profitieren kann.

Versionierung

Erst in den letzten zwei Jahren hatte ich Kollegen, die von den Vorzügen eines Versionierungssystems wußten und dieses auch nutzen wollten. Zuvor habe ich jahrelang mit durchnummerierten Dateikopien und gezippten Projektkopien gearbeitet. Diese Arbeitsweise ist nicht nur Steinzeit, sie ist auch hemmend. Ein Versionierungssystem nimmt mir die Änderungsverfolgung ab. Ich kann nachvollziehen, welche Änderung ich wann gemacht habe, alte Stände wiederherstellen. Ich kann jedem nur raten, sich mit SVN oder git auseinanderzusetzen. Ich selber bevorzuge SVN aus zweierlei Gründen:

1. Ich habe bislang keinen Kunden kennengelernt, der git nutzt, geschweige denn weiß, was das ist. Wenn jemand ein Versionierungssystem nutzt, dann SVN, sodaß bei größeren Unternehmen auch eigene SVN-Server existieren. Diese nutze ich dann mit.
2. Ich mag GUIs und kann mit der Kommandozeile nicht viel anfangen. Da es derzeit noch keine vernünftige Mac-GUI für git zu geben scheint, bin ich derzeit zwar von github fasziniert, beteilige mich aber nicht.

Zuerst verwendete ich einen kostenlosen SVN-Dienst im Netz. Mittlerweile nutze ich den beim Mac mitgelieferten SVN-Server, denn normalerweise arbeite ich für mich alleine und benötige SVN nur als System, das mir Dateiänderungen nachverfolgbar macht. Das macht die Übertragung nicht zwangsweise schneller, aber ich kann soviele Projekte kostenlos einrichten, wie ich Lust habe und vertraue keiner Fremdfirma meine Daten an. Meine gesamte Festplatte wird sowieso regelmäßig alle paar Stunden via “Time Machine” gesichert.

Mein SVN-Workflow ist sicherlich stark ausbaubar. Ich habe aber bislang weder die Zeit noch die verständliche Einführung gehabt, mir tiefergehende Gedanken zu machen. Für Anregungen bin ich dankbar. Vielleicht kann ja der eine oder andere Leser in seinem Blog über seine Arbeitsweise berichten. Ich lerne gerne dazu und würde gerne meine Arbeitsweise verfeinern.

Anpassung des Versionierungs-Workflows

Durch die Nutzung von SVN mußte ich meinen Workflow anpassen. Es hat gedauert, bis ich das verstanden habe. Bislang fing ich an, meine Dateien zu schreiben, bis ich nach ein paar Stunden oder Tagen auf die Idee kam, ich könnte mal den aktuellen Stand in SVN einchecken (bzw. früher als ZIP-Datei sichern) und dann weiterarbeiten. Falsch gedacht! Ich kann meine Dateien in SVN einchecken, muss dann aber eine Arbeitskopie wieder auschecken. Dies muss logischerweise an einem neuen Ort sein. Ich müßte also meine bewußt gewählte Ordnerstruktur über den Haufen werfen und meinen lokalen Webserver wieder neu einrichten. Nachdem ich den Fehler in meinem Vorgehen erkannte war mir klar, daß ein kleines Arbeits-Framework noch mehr Nutzen als gedacht haben würde. Denn nun checke ich bevor ich einen Handschlag mache mein “Starterkit” in ein neues SVN-Projekt ein und am gewünschten Bearbeitungsort wieder als Arbeitskopie aus und kann unmittelbar mit meiner Arbeit beginnen.

Ich habe leider keine Ahnung, wie dies mit git funktionieren würde. Ich warte noch auf eine einfach nutzbare Anwendung, die mir git ohne großes Lernen ermöglicht. Denn ich möchte mich nicht über Gebühr mit einem Versionierungssystem beschäftigen. Dieses System soll meiner Arbeit dienlich sein, es soll mir nützen und nicht meine Aufmerksamkeit ablenken.

Mein kleines Framework – die Grundlagen

In den weiten des Netzes gibt es zahlreiche Vorschläge, wie man sich seine Arbeit mit einer Art “Starterkit” erleichtern kann. Es handelt sich dabei meist um ein sehr abgespecktes Template mit einer DTD und Verknüpfungen zu einem leeren Stylesheet und einer leeren Javascriptdatei. Das sind Sachen, die jeder halbwegs gute Editor auch mit sich bringt. Meine Idee ging wesentlich weiter, da ich zu Beginn meiner Selbständigkeit beschlossen hatte, auf YAML als Entwicklungsgrundlage zu bauen, soweit die Kunden einverstanden sind. Zudem schreibe ich Javascript immer mit Hilfe von jQuery und habe damit eine Festlegung, die ich gleich in mein kleines Starterkit einbringen kann.

YAML als Basis

Die Verwendung eines CSS-Frameworks ermöglicht es mir, mich auf punktuelle Herausforderungen des jeweiligen Designs zu konzentrieren und nicht jedesmal wieder über den besten Weg für die Umsetzung eines Grundlayouts zu sinnieren. YAML nimmt mir die Suche nach Best Practices und immer wieder gesuchten Problemlösungen ab, denn Dirk Jesse hat für deren Implementierung schon viel Zeit investiert.

Egal welches Framework man nutzt, ein fremdes oder ein selbstgemachtes, es hilft dabei, sich selber zu disziplinieren und spart dadurch Zeit. Indem ich festgelegte Containernamen habe, wird meine Arbeit effektiver. Ich muss mir kein System ausdenken.

Die Namenskonventionen zu übernehmen fällt mir nicht besonders schwer. Probleme habe ich híngegen immer bei der Art, wie Dirk die einzelnen Dateien auf Verzeichnisse verteilt und miteinander verknüpft. Doch YAML ist kein Fertigtemplate, daß man so nutzen muss, wie es kommt. Es ist vielmehr ein Baukasten, aus dem man sich bedient, wie man es braucht. Ich habe mir also YAML so “zurechtgeschnitzt”, wie ich es sinnvoll nutzen kann, habe dabei aber immer im Auge behalten, daß ich das Framework auch wieder schnell updaten können möchte, wenn eine neue Version veröffentlicht wird. Da ich mir diese Arbeit der Neuaufteilung nur einmal machen wollte war schnell die Idee eines “Starterkits” geboren.

jQuery als Basiserweiterung

Ich habe leider nie richtig Javascript gelernt. Als ich begann, mich intensiver mit DOMScripting zu beschäftigen, mußte ich feststellen, daß die Javascript-Implementierungen der Browser noch kaputter und bescheuerter sind, als ihre CSS-Implementierungen. Man kann hier keinen Hersteller allein an den Pranger stellen, jeder hat auf seine eigene Art Mist gebaut.

Javascript-Frameworks bieten die Chance, alle Browser fehlerfrei und mit wenig Code anzusprechen, denn sie normalisieren die Unterschiede. jQuery hat mir von Anfang an am Besten gefallen, was wohl hauptsächlich an der CSS-ähnlichen Art der Selektion liegt. Ich kann mir allerdings vorstellen, daß jemand, der Javascript richtig gut beherrscht, mit Prototype, YUI oder mootools sehr viel besser bedient ist. Es ist doch klasse, daß wir Auswahl haben und für jeden etwas dabei ist.

PHP als Templateengine

Wie erwähnt nutze ich mein kleines Framework nicht primär dafür, komplette Sites zu erstellen, obwohl auch das ginge. Es geht mir vielmehr darum, schnell kleine Testcases bauen zu können und für meine Kunden Klickdummys zu erstellen, die sie selber dann in CMS-Templates überführen können. Meine gefundene Lösung hat den Vorteil, daß sie strukturelle Ebenen voneinander trennt. Ich nutze dafür PHP als Templateengine, ganz rudimentär. Das grobe Gerüst der Seite wird als Template abgespeichert und pro Einzelseite inkludiert. In dieses globale Template kommt nicht vielmehr als das, was ein Editor auch als Template vorschlagen würde. Mit Variablen kann ich eine ID oder Klasse dem Body-Tag hinzufügen, kann seitenspezifisches CSS oder Javascript laden, den Title-Tag und eine Seitenüberschrift befüllen.

Am Ende bleiben so Dateien übrig, die den eigentlichen Inhalt einer Seite im wesentlichen als HTML aufweisen. Sie können sogleich als Basis für die eigene Umsetzung als Template dienen.

Mein Editor als bestimmendes Element

Als ich mich an den Mac als mein neues Arbeitsgerät gewöhnte mußte ich mir einen neuen Editor suchen. In den langen Jahren meiner Tätigkeit als Frontendentwickler habe ich viele unterschiedliche Editoren genutzt und an den meisten ein paar Details schätzen gelernt. Es dauerte ein wenig, aber nach meinem ersten Erschrecken über die Schlichtheit von Textmate wußte ich die Stärken des Editors schnell zu schätzen. Da ich nicht der Typ Entwickler bin, der sich gerne stunden- und tagelang mit seinem Editor beschäftigt, bis er ihn passend zurechtgebogen hat, sind mir alle Erweiterungen und Verbesserungen mehr oder minder zufällig und vor allem schnell untergekommen. Ich habe mittlerweile meine eigenen Snippets, auf die ich schnell zugreifen kann, habe aber sicherlich viele versteckte Stärken noch nicht gehoben.

Dank der Snippets und der Technik “Zen Coding” sowie der vielen in Textmate eingebauten Features kann ich so schnell wie nie zuvor Code schreiben. Ich tippe einfach “fll” und drücke die Tabtaste und schon erscheint float: left. Bei meinen eigenen Snippets tippe ich nur “y33″ und die Tabtaste und schon erscheint der Code für die drei 33% breiten Boxen von YAML.

Problemfall Mischform

Ein Problem, das sich mir schnell stellte, war die Vermischung von HTML und PHP. Für mein Starterkit wäre es ja wichtig, daß ich innerhalb von PHP-Code normales HTML schreibe. Dagegen hat Textmate zwar nichts, aber es unterstützt mich dann nicht mehr wie gewohnt bei der visuellen Codedarstellung. HTML-,und PHP-Highlighting schließen sich leider gegenseitig aus. Schlimmer als das fehlende Hightlighting ist aber, daß ich im PHP-Modus auf einmal nicht mehr schnell HTML und CSS mit Codevervollständigung schreiben kann. Das wäre das Gegenteil von Rapid Prototypíng.

Problem erkannt und umgangen

Anstatt nun lange im Netz nach einer Lösung zu suchen, habe ich das Problem umgangen. Die gefundene Lösung hat sowohl einen Vor- als auch einen Nachteil für mich und meinen Workflow: ich erzeuge eine neue Seite, in der sich hauptsächlich HTML und ein paar PHP-Includes befinden. Der Nachteil ist, daß ich eine weitere Seite erzeuge. Der Vorteil ist, daß ich so den Content komplett in eine eigene Datei auslagern und somit auch schnell in ein anderes Projekt kopieren kann. Ich konzentriere mich am Ende nur auf den Content und blende alles andere aus.

Der Aufbau meines Starterkit

Mein Starterkit hat schon ohne eine einzige Seite einen komplexen Inhalt zu bieten. Als Standard habe ich eine Startseite und eine Testseite mit allen wichtigen semantischen Elementen als Grundausstattung auf der obersten Ebene. Eine solche Testdatei kann man immer gebrauchen, weil man schließlich irgendwann die Inhaltselemente einer Seite gestalten muss und sie dann auf einen Blick in einer Seite vor sich hat. Hinzu kommen die Ordner “css”, “images”, “inc”, “js” und “yaml”. Im Ordner “yaml” befinden sich nur die Kerndateien des Frameworks, verteilt auf die Ordner “core” und “patches”. Es sind diese Dateien, die ich nie verändere, höchstens mit einer neuen Version überschreibe.

Ein paar Screenshots

Der Ordner “css”

Im Ordner “css” befindet sich auf der obersten Ebene die Datei “layout.css”. Sie bindet alle YAML- und eigenen CSS-Dateien mittels @import ein. Im Ordner befinden sich noch die Ordner “navigation”, “patches”, “print” und “screen”.

In “navigation” sammele ich CSS-Dateien, die unterschiedliche horizontale und vertikale Navigationen aus derselben Codebasis erstellen. Indem ich immer wieder neue Beispiele erstelle und sammele bin ich schnell bereit, wenn ich eine bestimmte Form der Navigation benötige. Falls für diese Navigationen Bilder notwendig sein sollten, werden sie hier im Unterorder “images” abgelegt. Im Ordner “patches” befinden sich eine oder mehrere IE-spezifische Dateien. In “print” befindet sich natürlich die Datei für die Druckausgabe. Ich habe hier alle Dateien abgelegt, die Dirk Jesse mit seinen Beispielen zur Verfügung stellt. Sie sind eine prima Ausgangsbasis für mich.

In “screen” geschieht die meiste Arbeit. Hier wird meine jeweilige “basemod.css” (die entwicklungsabhängige Modifizierung der “base”) abgelegt, also die optische Finalisierung meines jeweiligen Projektes. Hinzu kommt die “forms.css”, also die Datei für den Formularbaukasten. Dirks Vorschläge für deren Optik habe ich aus der “forms.css” herausgenommen und in eine “forms-layout.css” gepackt. Dort kann ich dann gezielt an der Optik schrauben. Die “forms.css” lasse ich unverändert. Meinem Verständnis nach könnte sie später zu den Core- Dateien von YAML wandern. Bis dies nicht im Projekt so geschieht, werde ich meine Sortierung beibehalten. Auch die bei YAML mitgelieferten CSS-Dateien für Mikroformate und die “jQuery- Tabs” stecken genauso in diesem Ordner, wie Dirks erster Gestaltungsvorschlag (“content.css”). Sollten in diesen CSS-Dateien Bilder verknüpft sein, befinden sie sich im Unterordner “images”.

Mit YAML kommen viele Anwendungsbeispiele. Dirk Jesse hat für jedes eine eigene “basemod.css” erstellt, die vor allem für das Arrangement der drei Hauptspalten sorgt. Alle diese basemod-Dateien habe ich in einen eigenen Unterordner gepackt. Wenn ich also ein 3-Spalten-Layout mit der Anordnung “3-2-1″ erstelle (mit der Containerabfolge div#content3, div#content2, div#content1), dann binde ich in der “layout.css” die Datei “basemod_3-2-1.css” im Unterordner “basemod” ein und ich habe damit schon die grundsätzliche Ausrichtung geschafft. Ich erspare mir durch diese Vorarbeit das lästige Suchen.

Der Ordner “images”

In den Ordner “images” kommen vor allem Bilder, die im Content genutzt werden. Alle über CSS-Dateien eingebundenen Bilder sollten über den jeweiligen Unterordner bei den CSS-Dateien selber eingebunden werden. Durch eine solche Trennung habe ich vor allem bei den diversen CSS-Dateien einen großen Vorteil, weil ich einzelne Elemente schnell zwischen Projekten austauschen kann. Es steigert zudem die Übersichtlichkeit. Sie ist auch der Grund für die diversen Unterordner.

Der Ordner “js”

Im Ordner “js” befinden sich neben der aktuellen jQuery-Datei eine kleine Sammlung von jQuery-Plugins, deren Nutzung mir sinnvoll erscheint. Sie müssen immer wieder aktualisert werden. Da während meiner Entwicklungszeit Performancefaktoren unwichtig sind, binde ich jQuery nicht über ein CDN ein, weshalb ich die relevanten Dateien auch lokal vorhalte.

Der Ordner “inc”

In diesem Ordner sind auf der obersten Ebene das Template und alle ausgelagerten Seitenbestandteile, also vor allem der “Footer“, der “Header” und die jeweiligen Navigationen. Wichtig ist der Unterordner “pages“. In ihm befinden sich die eigentlichen Inhalte der Seiten. Im Unterordner “pages” kann sich ein weiterer “inc”-Ordner befinden, falls ich Seitenbestandteile auslagern und häufiger nutzen möchte. Das ist besonders bei Teasercontainern oder kleinen Kalendern u.ä. der Fall.

Benennungsrichtlinie

Der hier skizzierte Aufbau meines Starterkits funktioniert nur deshalb im Editor reibungslos und ohne Fehler, weil ich die Rahmenseite und die Inhaltsseite ähnlich aber in einem Detail trotzdem unterschiedlich benenne. Eine Datei “testseite.php” ist mehr oder minder eine Steuerdatei. Riefe ich sie allein auf, bekäme ich das Rahmentemplate und vielleicht die Seitenüberschrift zu sehen. Aber wahrscheinlich nicht einmal die. Die eigentlichen Inhalte befinden sich im Unterordern “inc/pages” in der Datei “testseite.php.inc”. Ich habe die Dateiendung “inc” aus zweierlei Gründen angefügt: Erstens ist es verbreitete Konvention, eine Include-Datei mit dieser Endung zu versehen. Und zweitens habe ich so in den Reitern meines Editors eine deutliche Unterscheidung der beiden Dateien, die ich sonst nur über Umwege bekäme. Ich möchte mir ja die Arbeit erleichtern und nicht verkomplizieren.

In der Templatedatei ist das eine klitzekleine Abfrage via PHP nach dem Namen der Datei und einer kleinen Stringoperation, mit der ich die Dateiendung “inc” anfüge:

<?php
  $dateiname = basename($_SERVER['PHP_SELF']);
  include_once 'inc/pages/'.$dateiname.'.inc';
?>

Rudimentäres Template

Das Template soll möglichst global für alle Projekte und für alle Seiten eines Projektes funktionieren. Deshalb definiert es nur einen kleinen Rahmen und definiert keine Inhaltsspalten. Einzig die bei YAML immer genutzten Container “.page_margins“, “.page” und “#main” bleiben erhalten. Was sich innerhalb von “#main” abspielt ist Sache der jeweiligen Includes. Ich könnte das Template für die Zukunft auch soweit aufbohren, mit einer switch-case-Abfrage unterschiedliche Unterstrukturen zuzuweisen. Doch ich habe mich dagegen entschieden, da ich mittels Textmate-Snippets sehr fix eine Grundstruktur in eine Datei einfügen kann. Ich halte dadurch alle Strukturierungsgedanken aus dem Template heraus, das damit ganz global nutzbar bleibt. Mit unterschiedlichen Grundstrukturen in einer Abfrage im Template würde es entweder projektspezifisch werden oder so aufgebläht, daß ich – und vor allem mein Kunde – den Code nicht mehr schell überblicken kann.

Das Template

Nun habe ich schon einiges über das knappe Template geschrieben, da ist es auch recht und billig, den Code zu zeigen. Ich habe bewußt meta-Tags ausgespart, denn da ich im wesentlichen Templates erstelle, benötige ich sie nicht. Für die eventuelle produktive Nutzung habe ich Kommentare über die Nutzung von jQuery via CDN hinzugefügt.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<title><?php if (isset($seitentitel)) {echo $seitentitel;} else { echo "Platzhalter für einen Seitentitel";} ?></title>
<!-- JavaScript Detection -->
<script type="text/javascript">document.documentElement.className += " js";</script>
<!-- add your meta tags here -->
<link href="./css/layout.css" rel="stylesheet" type="text/css" />
<?php if(isset($additionalCSS)) {echo $additionalCSS;} ?>
<!--[if lte IE 7]>
	<link href="./css/patches/patch_my_layout.css" rel="stylesheet" type="text/css" />
<![endif]-->
</head>
<body<?php if (isset($bodyid)){ echo ' id="'.$bodyid.'"';} ?>>
 <!-- begin: skip link navigation -->
 <?php include_once $skiplinks ?>
 <!-- end: skip link navigation -->
 <div class="page_margins">
  <div class="page">
   <!--  begin: header -->
   <?php include 'header.inc' ?>
   <!--  end: header-->
   <!-- begin: main navigation #nav -->
   <?php //include 'mainnavigation.inc' ?>
   <!-- end: main navigation -->
   <!-- begin: content area #main -->
   <div id="main">
    <?php
     $dateiname = basename($_SERVER['PHP_SELF']);
     include_once 'inc/pages/'.$dateiname.'.inc';
    ?>
   </div>
   <!-- end: #main -->
   <!-- begin: #footer -->
   <?php include 'footer.inc' ?>
   <!--  end: #footer -->
  </div>
 </div>

<!-- Für bessere Performance werden die Skripte erst hier unten geladen. -->
<!-- Siehe: http://www.webkrauts.de/2008/12/14/sehr-sehr-schnelle-seiten-website-performance-best-practice-teil-2/ -->

<!-- Später im Produktionsprozess kann man jQuery über Google-Code nutzen. -->
<!-- <script src="http://ajax.googleapis.com/ajax/libs/jQuery/1.4.2/jQuery.min.js" type="text/javascript" charset="utf-8"></script> -->
<!-- <script src="http://ajax.googleapis.com/ajax/libs/jQueryui/1.8.0/jQuery-ui.min.js" type="text/javascript" charset="utf-8"></script> -->

<script src="./js/jQuery-1.4.2.min.js" type="text/javascript"></script>
<script src="./js/scripts.js" type="text/javascript"></script> 

<!-- full skiplink functionality in webkit Browsers -->
<script src="./yaml/core/js/yaml-focusfix.js" type="text/javascript"></script>
<?php if(isset($additionalJS)) {echo $additionalJS;} ?>
</body> <!-- end: body -->
</html>

Ich habe bewußt zwei Bereiche integriert, in die ich individuelles CSS und Javascript einfügen kann. Das kann inline oder durch die Einbindung einer externen Datei geschehen, denn im Template ist nur Platz reserviert, keine Regeln für die Verwendung des Platzes vorgegeben. Das Template kann man leicht erweitern. Doch vor zuviel Ergänzungen schrecke ich zurück, weil ich die leichte und schnelle Umarbeitung als CMS-Template im Blick habe.

Fazit

Kern meiner Arbeitsweise sind drei Aspekte:

1. Alle als Module identifizierbaren Einheiten werden soweit es geht in eine eigene Datei ausgelagert.
2. Zusätzlich werden Inhalte werden in eine eigene Datei.
3. Einzellösungen werden möglichst verallgemeinert und gesammelt, sodaß mit der Zeit eine immer größere Ressource entsteht.

Die Auslagerung von Dateien erleichtert die Erstellung von Templates und beschleunigt die Erstellung neuer Seiten.