2. Webseiten modular entwickeln

In allen Programmiersprachen gibt es Diskussionen darüber, wie man seine Applikation möglichst effizient und gut wartbar entwickelt. Die Diskussionsergebnisse fliessen in Entwicklungsparadigmen wie MVC (Model-View-Control) oder in Benamungsrichtlinien ein. Folgt man solchen Standards, ist es leichter, Code von anderen zu verstehen und zu übernehmen.

Im Bereich der Frontendentwicklung sind über die Jahre auch solche Standards entstanden, sie haben aber nicht die gleiche normative Kraft entfaltet. Das ist vor allem deshalb sehr bedauerlich, weil viele unterschiedliche Entwicklertypen für den Frontendcode verantwortlich sind. Speziell die Backendentwickler, die neben ihrer Hauptaufgabe auch Frontendcode schreiben müssen, wären sicherlich sehr dankbar für klare Richtlininen zur Formulierung guten Codes. Auch die Arbeit in Teams wird durch Regeln erleichtert. Sie gewährleisten einen vergleichbaren, für alle leichter verständlichen Output.

Es gibt nicht die eine Art, das Frontend zu entwickeln. Es gibt hingegen viele unterschiedliche Wege, HTML und CSS zu organisieren. Einige werde ich später skizzieren und meinen eigenen Weg dagegen halten. Doch bei aller Lust am Entwurf von Coderichtlinine sollte man immer die spezifischen Eigenheiten seines Projektes im Auge haben. Wenn es das Wissen der Teammitglieder erlaubt, sollten die Vorgaben flexibler sein, als bei Teams mit einem hohen Anteil an Entwicklern mit geringer Frontendkompetenz.

Eine Seite ist eine Ansammlung von Modulen

Eine Webseite setzt sich aus vielen unterschiedlichen Einzelteilen zusammen, die gängigsten sind Header, Footer und der immer anders angeordente Inhalt. Meist werden diese Einzelteile mittels eines CMS aus einzelnen Bausteinen kreiert. Wir gestalten und entwickeln im Grunde keine Seiten, sondern Systeme. Diese Systeme bestehen aus vielen einzelnen Elementen, die man Module nennen kann. Diese Module sind prinzipiell unabhängig voneinander, jedes ein eigenes kleines Universum. Gängige Module sind beispielsweise:

• Navigationen
• Linklisten in Seitenleisten oder im Footer
• Teaserboxen - mit oder ohne Bild
• Slider/Karussell
• in einem Akkordeon organisierte Inhalte
• in einem Tab-Interface organisierte Inhalte
• eine eingebettete Landkarte

Für Backendentwickler ist dies sicherlich keine neue Erkenntnis, da sie im Normalfall die Einzelteile einer Webseite in diversen Templates realisieren und getrennt ablegen. Auch Frontendentwickler schreiben Seiten nicht in einem Rutsch durch, sondern nehmen sich die einzelnen Bestandteile (Module) nacheinander vor.

Nicht immer wird aber aus dieser Vorgehensweise die richtige Schlussfolgerung gezogen. Denn wenn wir schon die Webseiten schrittweise, modular erstellen, dann sollten diese einzelnen Module auch möglichst unabhängig voneinander existieren können. Das tun sie aber meist nicht. Über diese Diskrepanz soll es im Folgenden gehen.

Dieser Screenshot repräsentiert eine nicht mehr aktuelle Version von ZEIT.de.

Mitte 2017 ist dies die aktuelle Version von ZEIT.de.

Der Aufbau der 2012 redesignten Seite von Microsoft, Quelle: Artikel von Dave Rupert

Erst der Sinn, dann die Optik

Sie sollten sich immer wieder vor Augen halten, dass HTML die Basis aller Webseiten ist. CSS und JavaScript sind als die Erweiterungen azusehen. CSS ist für die hoffentlich attraktive Optik zuständig. JavaScript soll die Seite hingegen dynamisch machen. Das kann über das Hinzuladen von Inhalten passieren (AJAX) oder über Oberflächeneffekte (bspw. ein Akkordeon). Trotz aller schönen und dynamischen Optik beginnt jede Seite aber mit hoffentlich gutem, semantischem HTML. Webentwicklung ist ein Handwerk, keine Kunst. Semantisch armes HTML spricht Bände über die Fähigkeiten des Handwerkers. Bevor Sie also anfangen, die Gestaltung mit CSS umzusetzen, sollten Sie zuerst sinnvolles HTML erzeugen.

Mittlerweile haben Sie eine Fülle semantischer Elemente zur Verfügung. Sie sollten sie nutzen. Eine Webseite besteht aus mehr als nur DIV, P und SPAN. Erst nachdem Sie sich Gedanken über das korrekte HTML gemacht haben, sollten Sie sich mit CSS und JavaScript beschäftigen. Denken Sie bitte immer daran, welches HTML-Element dem Sinn nach genutzt werden sollte, nicht der Optik nach. Schliesslich besteht ein Teil der späteren Arbeit darin, die eigentlich gewohnte Optik von Elementen stark zu verändern. Bei Navigationen machen wir dies immer. Niemand sieht ihnen an, dass sie eigentlich Listen sind. Von der Optik können wir also nicht zwangsweise auf das HTML schliessen. Sie müssen sich schon mit den Inhalten beschäftigen.

Layout und Design

Unter Layout verstehe ich die Verteilung der Inhalte im Browserfenster, ihr horizontales und vertikales Arrangement. Hierfür werden normalerweise Grids oder Spalten genutzt. Design liegt dann vor, wenn Elementen innerhalb dieses Layouts eine konkrete Optik verpasst wird. Design ist also im Idealfall schön.

Das Layout ist unabhängig vom jeweiligen Design, das sich im Wesentlichen mit Farben, Größen und Abständen beschäftigt. Design ist grob gesagt die Dekoration. Layout kann sich auf die Webseite als Ganzes oder auf ein einzelnes Modul beziehen. So können bspw. die Inhalte eines Teasers vertikal oder horizontal angeordnet sein.

Grundsätzlich sollte die Platzierung des jeweiligen Moduls innerhalb des Layouts egal sein. Es sollte sich bei kleinem und großem Platz anpassen, unter Beibehaltung der eigenen Funktionalität. Module sollten also generell unabhängig vom Layout sein.

Ich empfehle dringend, auch beim Schreiben von HTML und CSS diese beide Ebenen zu trennen. Es sollte auf der einen Seite Klassen geben, die nur das Layoutgerüst konstruieren und auf der anderen Seite Klassen, die sich um das Design der Inhalte kümmern. Das Layout sollte zudem aus eigenständigen Elementen bestehen. In diese werden dann die Module als eigenständige semantische Konstrukte platziert. Ein Beispiel für ein Layoutgerüst (ohne Inhalte):

1 <div class="ym-grid">
2 	<div class="ym-g60 ym-gl">
3 		<!-- Hier kommt das Inhaltsmodul hin!  -->
4 	</div>
5 	<div class="ym-g40 ym-gr">
6 		<!-- Hier kommt das Inhaltsmodul hin!  -->
7 	</div>
8 </div>

Wir diskutieren hierbei nicht über die korrekte Verwendung von Klassen. Mir ist nur wichtig zu zeigen, dass mit dieser einfachen Struktur und diesen paar Klassen ein Grid erzeugt wurde. In diesem Falle ist der erste Container 60% breit und der zweite 40%. Das Beispiel wurde vom CSS-Framework YAML entlehnt.

Das Gridmodul existiert unabhängig von den Inhaltsmodulen und kann an unterschiedlichen Stellen wiederverwendet werden. Die Inhaltsmodule passen sich dem ihnen von den Layoutmodulen zur Verfügung gestellten Platz an. Dadurch haben wir eine Trennung von Seitenlayout und Inhalten erreicht. Diesen benötigen wir, damit die Inhaltsmodule transportabel sind. Ein Teasermodul kann an der einen Stelle beispielsweise zwei Drittel, an der anderen nur ein Drittel des Platzes wegnehmen. Würden wir dem Teasermodul direkt Layouteigenschaften mitgeben (bspw. <code>float</code> und Breite), so wäre das Modul nicht mehr einfach zwischen Seitentypen oder gar Projekten transportabel. Und das wäre in meinen Augen eine unnötige Einschränkung.

Der neue Blick auf das CSS

Seit ein paar Jahren gibt es vermehrt Artikel und Bücher, die sich mit der Organisation und der Nomenklatur von Webseitenstrukturen und ihrer Gestaltung durch CSS widmen. Mir gefällt dieser Blick auf unsere Methodik, denn ich habe während meiner gesamten Berufslaufbahn immer wieder meine Arbeitsweise hinterfragt. Mein Bestreben war es immer, das nächste Projekt effizienter zu erledigen.

Über die Jahre habe ich meine Arbeitsweise mehrfach geändert. Dazu trugen technische Veränderungen genauso bei, wie Anregungen von aussen. Der sogenannte “objektorientierte Ansatz” - präsent und bekannt in den Projekten OOCSS, SMACSS und BEM - hat auf lange Sicht den größten Einfluss ausgeübt. Einzelne Aspekte der Ansätze hatte ich schon in meinen Projekten, bevor ich von OOCSS und Konsorten überhaupt Kenntnis hatte. Allerdings fehlte es meiner Arbeit an der letzten Konsequenz. Vor allem SMACSS empfand ich als besonders hilfreich.

Die objektorientierten Ansätze wenden den Blick von der reinen Gestaltung und der Erzeugung von Effekten ab. Ihnen geht es nicht um das “was”, sondern um das “wie”. Sie befördern den systematischen und durchdachten Umgang mit Klassen. Dadurch wird Teamarbeit erleichtert, ebenso die Übergabe an andere Entwickler. Und auch man selber sollte durch eine konsistente Systematik leichter in ältere eigene Projekte wieder reinfinden können.

In meinen Augen liefern alle drei Ansätze interessante Aspekte. Ich empfehle nicht, einem dieser Ansätze sklavisch zu folgen. Aber ich empfehle, sich anhand dieser Ansätze - und meiner hier folgenden Ausführungen - Gedanken über die eigene Arbeitsweise und den Aufbau der eigenen Projekte zu machen.

Das Ziel: Modulbaukasten

Wenn wir unsere Module so schreiben, dass sie für sich stehen und im sinnvollen Rahmen beliebig auf einer Seite platziert werden können, dann können wir sie auch auf einer Übersichtsseite sammeln. Es entstünde so etwas Ähnliches wie das berühmte “Bootstrap”: ein eigenes Bootstrap, das auf eigenem Code aufbaut. Jeder Frontendentwickler und vor allem jede Agentur kann sich einen solchen Modulbaukasten (oder auch Framework) aus vergangenen Projekten zusammenstellen.

Bootstrap ist nur deshalb so beliebt, weil es eine grosse Menge immer wieder nachgefragter Module zur Verfügung stellt, die Anwender einfach nur per “copy & paste” in eine Seite fallen lassen müssen, um eine funktionierende Seite zu erhalten, die sogar ein halbwegs ansprechendes Design als Ausgangslage mitbringt.

Jede Agentur hat allerdings das Potential, sich ein eigenes Bootstrap aufzubauen, um sich daraus zu bedienen. Dadurch kann man in einem ersten Schritt sehr viel einfacher und schneller mit Rapid Prototyping arbeiten.

Ausserdem muss man nicht für jedes Projekt die immer wieder gleichen Elemente von neuem schreiben. Man kopiert sich einfach schon erfolgreich getesteten Code und passt ihn an. Und je weniger Abhängigkeiten es zwischen den einzelnen Modulen und allgemeingültigem CSS gibt, desto besser. Es bleibt jedem selbst überlassen, wieviel eigener Code mit wieviel Fremdcode kombiniert wird.

Ein Modulbaukasten erleichtert die Dokumentation der Module, erleichtert den Austausch mit Kunden und Designern. Es entsteht eine Fundgrube für Module, die in zukünftigen Projekten genutzt werden können. Dabei sollten Sie immer im Hinterkopf behalten, dass das Design eines Moduls sich relativ leicht ändern/anpassen lässt. Eine horizontale Navigation lässt sich mit nur wenigen Zeilen CSS optisch stark modifizieren. Finden Sie deshalb eine neutrale Darstellung für Ihre Module. Arbeiten Sie mit Grautönen und neutralen Bildern und Logos.

So entstehen schnell eigene Klickdummys, deren Einzelteile immer wieder weiterverwendbar sind.

Die Idee des Modulbaukastens wird heute für die Abarbeitung einzelner Projekte als Living Styleguide oder Pattern Library beworben. Und was für ein einzelnes Projekt gilt, kann auch für viele gelten. Sammeln Sie Module/Patterns, so sparen Sie sich unnötige Arbeit.