Grid-Layouts – das neue Tabellenlayout?

Grids sind seit einiger Zeit ein beliebter Ansatz zur Erstellung von Layouts. Es gibt vehemente Befürworter, die allesamt auch attraktive Designs zur Demonstration vorlegen. Ein Grid ist ein Raster, das als Grundlage der Layouterstellung genommen wird. Es wird dabei nicht allein auf die Verteilung von Elementen auf der Seite geschaut. Das Raster soll dem Layout Dynamik verleihen, indem die bisherige Orientierung an Spalten durchbrochen wird und Seitenbereiche unabhängig von Spalten arrangiert werden können. Hinzu kommt ein verstärkter Blick auf die Typographie, das Spiel mit Zeilenhöhen.

Das Konzept von Grids

Das Konzept ist unabhängig von der tatsächlichen technischen Umsetzung. Diese war nie im Fokus. Man kann Grids genauso gut mit einem Tabellenlayout wie mit Floats erstellen. Der Grundgedanke hinter dem Konzept ist eher traditionell als modern, eher Tabellenlayout als Float. Der Seitenaufbau orientiert sich bei Grids nicht mehr primär an Semantik und Inhalt, sondern an der Optik, am Seitenaufbau.

Auf dem Raster werden alle Seitenelemente platziert. Über die optimale Aufteilung des Rasters gibt es unterschiedliche Sichtweisen. Die Grundidee ist schon bei grober Betrachtung den traditionellen Layouttabellen sehr ähnlich. Es besteht ein direkter Zusammenhang zwischen HTML und Layout. Einzig die dafür zuständigen Elemente wurden getauscht.

Herkömmliches CSS-Layout geht vom Inhalt aus

Die bei herkömmlichem CSS-basierten Layouts übliche Methode geht folgenden Weg:

  • Erst werden grobe Bereiche anhand ihrer Funktion identifiziert, bspw. Header, Footer, Navigation und ein Inhaltsbereich.
  • Diese Bereiche werden in der Regel als DIV-Container mit entsprechenden IDs in semantischem HTML umgesetzt (auch funktionale Auszeichnungen gehören zur Semantik) und mit Inhalten gefüllt.
  • Erst dann kümmert man sich mit CSS um die Gestaltung des Layouts – die Positionierung, Ausrichtung und Randabstände der einzelnen Funktionsbereiche sowie die Formatierung der Inhalte.

Das HTML liefert also Struktur und Inhalt, das CSS entscheidet über die Art und Weise der Präsentation.

Ein solcher Ansatz kann Flexibilität bringen. Nehmen wir an, wir haben ein zweispaltiges Layout mit Floats aufgebaut. Nur durch die Änderung der Float-Richtung können wir aus der linksseitigen eine rechtsseitige Navigation machen. Hierfür müssen wir zwei Eigenschaften im CSS ändern. Auch die Breiten der einzelnen Bereiche kann ich durch eine einfache Modifikation des CSS ändern.

Beim Grid-Layout steht die Optik im Vordergrund

Ein Grid-Layout, wie es Blueprint & Co umsetzen, würde diese einfache Möglichkeit nicht zulassen. Denn in diesen Grid-Frameworks erfolgt die Gliederung der Inhaltemittels der Klassen des Frameworks nicht nach ihrer Funktionen, sondern anhand ihrer späteren Position innerhalb des Rasters. Inhalte werden somit nach rein visuellen Kriterien in ein Zeilen- und Spaltenraster sortiert, ganz ähnlich dem früheren Tabellenlayout.DIV-Container mit unterschiedlichen Klassen ersetzen das gute alte <tr colspan=2>.

Das Verschieben eines Elementes innerhalb des Layouts führt daher zwangsläufig (und das ist das Entscheidene) zu größeren Änderungen im Markup. Denn der zeilen- und spaltenweise Aufbau des Layouts erzwingt ein Umsortieren auch benachbarter Elemente, damit das Raster auch nach der Änderung passt. Dies erinnert stark an die alten Tage des Tabellenlayouts.

Vom Inhalt her gegliedertes HTML lässt sich per CSS deutlich freier Gestalten. Zwar kann auch hier ein Redesign mit Änderungen im Markup verbunden sein, jedoch lässt sich beispielsweise eine floatende Navigation mittels einer Zeile CSS vom linken an den rechten Rand des Layouts verschieben, ohne das Markup zu modifizieren.

Ich empfinde dieses tabellennahe Konzept zur Umsetzung eines Grids als einen Fehler. Doch der Fehler liegt in meinen Augen nicht in der Grundidee des Grid-Layouts begründet. Dirk Jesse hat gezeigt, daß man auch mit seinem YAML ein Grid-Layout erstellen kann. Offenbar liegt das Problem also bei den Entwicklern der einzelnen Grid-Frameworks. Diese vermehren sich in letzter Zeit. Offenbar haben einige Entwickler erkannt, daß die bisherigen Frameworks allesamt Einschränkungen mit sich brachten, die mit ihren persönlichen Bedürfnissen nicht in Einklang zu bringen waren.

Die Entstehung der CSS-Frameworks

Gehen wir mal einen Schritt zurück: was ist der Sinn eines Frameworks? Ein Framework soll dem Anwender Arbeit abnehmen. Es schafft dies, indem es immer wiederkehrende Aufgaben löst, ihre Lösung standardisiert. Auch die Standardisierung der Anwendung ist eine Problemlösung. Der Entwickler muss sich nicht wiederholt Gedanken über die Benamung immer wieder genutzter Seitenbereiche machen.

Bei aller Standardisierung sollten Frameworks den Anwender aber nie über Gebühr einschränken. Es liegt in der Natur der Sache, daß ein CSS-Framework weniger komplex ist, als eines für PHP oder Javascript. Es ist auch schwer, auf einem ähnlich hohen Abstraktionsniveau zu agieren, da CSS jegliche Dynamik und Programmierbarkeit fehlt. Dies ist sicherlich der Hauptgrund dafür, daß es sehr lange dauerte, bis ein wirkliches CSS-Framework entwickelt wurde.

Die ersten Frameworks: YAML und YUI-Grids

Die ersten waren YAML (Oktober 2005) und YUI-Grids (Februar 2006). YAML wurde lange Zeit nur im deutschen Sprachraum beachtet und genutzt, weil eine englische Übersetzung fehlte. Es war von Anfang an auf Flexibilität im Umgang ausgerichtet. Prinzipiell konnte und kann man jegliches Layout damit erstellen. Fixe, flexible und fluide Layouts mit unterschiedlicher Gesamt- oder Maximalbreite sind damit genauso möglich, wie Grid-Layouts. Yahoo hingegen entwickelte sein Framework für die eigene Anwendung. Deshalb waren die ersten Versionen sehr limitiert, flexible Layouts waren Anfangs unmöglich. Man hatte zu Beginn die Auswahl zwischen zwei Breiten. Der Name „YUI-Grids“ ist übrigens irreführend, denn die Idee der Grid-Layouts war nie Grundlage des Frameworks.

So funktionieren Grid-Frameworks

Ergänzend zu diesen beiden CSS-Frameworks entstand im Rahmen der Diskussion über Grid-Layouts ein erstes Grid-Framework. Diesem folgten viele ähnlich gestrickte in recht kurzen Abständen nach. Sie wählten bei der Umsetzung eine andere Herangehensweise, als YAML oder YUI-Grids. Die engere Verzahnung des Layouts mit HTML, wie oben beschrieben, ist eindeutig ein Schritt zurück. Erlauben YAML und YUI-Grids ein Layout beliebiger Anordnung und Breite, schränken die selbsternannten Grid-Frameworks die Umsetzung ein. Ein Grid entsteht immer aus einer mehr oder minder großen Anzahl von Spalten und Spaltenzwischenräumen (dem Grundraster).

Für eine Positionierung eines Elementes innerhalb des Rasters, stellen Grid-Frameworks wie Blueprint eine Vielzahl von Klassen bereit, mit denen sich dessen Lage innerhalb einer „Grid-Zeile“ festlegen lässt und womit bei Bedarf mehrere Spalten des Grundrasters zu einem größeren Block zusammengefasst werden können. Einige Frameworks erlauben auch die Verschachtelung von Containern, wobei dann in der Regel Helfer-Klassen benötigt werden, um die Ausrichtung innerhalb des Elternelements (Randabstände) zu korrigieren.

Dieses Konzept erfordert eine Vielzahl vordefinierter Klassen zur Festlegung von Containerbreiten und Randabständen zu benachbarten Elementen. Alle diese Werte sind jedoch abhängige Größen des Grundrasters. Ändert sich das Grundraster (Spaltenbreite oder Spaltenzwischenraum), ändern sich auch die abhängigen Größen und alle vordefinierten CSS-Klassen müssen angepasst werden.

Wer mit dem zugrunde liegenden Raster nichts anfangen kann, muss sich zwangsläufig sein eigenes Raster erstellen. So ist in meinen Augen die steigende Anzahl an Blueprint-Klonen zu erklären, deren zugrunde liegende Logik unverändert bleibt, es ändern sich nur die Zahlen und/oder Maßeinheiten.

Ein Grid-Layout mit YAML ist flexibel

Auch YAML bietet neben dem spaltenbasierten Layoutkonzept spezielle Grid-Bausteine für Grid-Layouts. Deren Funktionsprinzip ist jedoch ein anderes. Sie sind robuster, da Spaltenbreiten und Zwischenräume einerseits flexibel aber vor allem als unabhängige Größen definiert werden. Sie lassen sich zudem einfach mit dem spaltenbasierten Layoutkonzept von YAML kombinieren, womit auch die funktionale Gliederung der Inhalte wieder leichter möglich ist.

Blueprint ist der falsche Weg

Ich finde es daher schade, daß so viel Energie darauf verwendet wird, ein suboptimales Konzept, wie es Blueprint eingeführt hat, immer wieder zu modifizieren, anstatt mit neuen Ideen an die Sache heranzugehen. Es kann doch nicht unser Ziel sein, mittels Grid-Frameworks die Unflexibilität eines Tabellendesigns nachzuahmen. Vielmehr sollte darüber nachgedacht werden, wie wir Rapid Prototyping, ungewöhnliche und typographisch interessante Layouts und Flexibilität in der Anwendung miteinander kombinieren können. All den Erstellern eines Blueprint-Klons sollte klar sein, daß sie ihren eigenen Beitrag nur auf Grund der Unflexibilität des Originals geleistet haben.

Das Internet ist flexibel

Die große Stärke des Internet ist seine Flexibilität in jeglicher Hinsicht. Doch diese Flexibilität ist nur eine theoretische Größe, solange wir uns selber in der täglichen Arbeit beschränken. Die Browser werden besser, aber unsere Ansätze für moderne Designs stagnieren. Dabei wird in Zukunft die Flexibilität des Internet noch stärker gefragt sein, als es jetzt der Fall ist. Das Medium ist mittlerweile nicht nur etabliert, seine Nutzungsfomen variieren auch stärker als zuvor. Immer mehr Menschen greifen von unterwegs über Handys und Notebooks auf das Internet zu. Der Nutzungskontext ist nicht mehr allein das Büro mit dem Festrechner. Bildschirmauflösungen variieren genauso stark, wie die Fähigkeiten der Betrachtungssoftware oder die Nutzungsmöglichkeiten von Zusatzgeräten wie Mäusen.

Da wir immer weniger wissen oder antizipieren können, in welcher Art jemand eine Webseite konsumiert – von der Diskussion um Barrierefreiheit sehe ich jetzt mal ab – ist es wenig hilfreich, die Nutzungsmöglichkeiten unserer Webseiten einzuschränken.

Es geht bei solch grundlegenden Designansätzen nicht allein um die attraktive Optik. Hübsche Seiten kann man in jeglicher Art erzeugen, auch in Form eines Tabellendesigns. Entscheidend ist der Grad der Flexibilität und der Zugänglichkeit eines solchen Ansatzes. Entscheidend ist auch, mit welchen Grundannahmen an eines solches Design herangegangen wird.

Zukunftsorientiertes Webdesign sollte flexibel sein

Das Internet ist noch ganz am Anfang seiner Entwicklung, auch wenn es sich für einige von uns so anfühlt, als wären sie schon Jahrzehnte dabei. Wir sind gerade erst dabei, die richtigen Ansätze zum Umgang mit dem Web und zur Entwicklung für das Web zu finden. Deshalb muss es Menschen geben, die nicht nur an die schnelle Abarbeitung von Aufträgen, sondern auch einen Schritt weiter denken. Die derzeitigen Grid-Frameworks sind einschränkend. Deshalb sollte mehr Energie auf die Entwicklung eines flexibleren Ansatzes gesteckt werden, als zum wiederholten Mal einen Blueprint-Klon mit den altbekannten Beschränkungen zu schaffen.

19 Kommentare

  1. Ich empfinde dieses tabellennahe Konzept zur Umsetzung eines Grids als einen Fehler…

    Korrekt, so sehe ich das auch.

    Ich halte Grids für eine nette Spielerei. Wirklich sinnvoll nur für fixe Layouts, für flexible Layouts nur mehr eine Krücke, also nicht wirklich innovativ. Ja, Grids stehen nahe am Tabellanlayout. Und Hallo: Es gibt noch viel zuviele Kunden, die ein printbasiertes Fixlayout wollen und Webentwickler, die das ohne Murren und gern umsetzen. Da ist die Baustelle.

    Es gilt auch im Internet die Feststellung des US-amerikanischen Architekten Sullivan „form follows function“. Diesem Ausspruch (identisch zur Philosophie des Bauhaus) verdanken wir eben nicht nur hässliche Nachkriegs-Bausünden, sondern vor allem Häuser, in den man gut wohnt und gern lebt. Oder Einbauküchen, die auch nur aus „little boxes“ bestehen, die ich nach Funktion und Anforderung zusammen stelle, und deren Fortschritt nur der erahnen kann, der mal in einem Heimatmuseum eine Küche der 20er Jahre betreten hat oder die seiner Großmutter kennt.

  2. Schöner Artikel, der mein Unbehagen mit Blueprint-Grids sehr gut auf den Punkt bringt.

    Andy Clarke beschreibt das in „Transcending CSS“ ab S. 55 mit dem Satz „Mit CSS gestylte Seiten werden oft immer noch ‚von oben nach unten, von links nach rechts‘ konstruiert“, nur halt mit div statt mit table.

    Er empfiehlt stattdessen „Die inhaltsbezogene Vorgehensweise“: Zuerst nur strukturelle HTML-Elemenente, dann das Design. Und er bringt wunderschöne und überzeugende Beispiele.

    Bemerkenswert daran ist, dass er von Haus aus Grafikdesigner ist und trotzdem den inhaltsbezogenen Ansatz bevorzugt, weil der der Flexibilität des Mediums „Web“ besser entspricht.

  3. Jens, ich verstehe Deinen Standpunkt als Web-Entwickler mit Standardista-Ambitionen sehr gut. Aber er ist nur eine Seite der Medaille. Fakt ist nämlich auch, das haben unzählige Usability-Tests ergeben, dass der Betrachter einen strukturierten Inhalt erheblich besser erfassen kann, als einen unstrukturierten. Und obendrein länger auf der Seite bleibt und mehr liest, als auf unstrukturierten Seiten. Es gibt Gründe für die Nutzung eines Grids, sehr gute sogar.

    Und versuche bitte zu verstehen, das Deine Meinung zu Grids nur eine von mehreren möglichen ist, die nicht allein dadurch richtig ist, weil Du die anderen konstant für falsch deklarierst. Alle Entwickler von Grids und deren Nutzer können nicht so dumm sein, wie Du es darstellst. Fast alle Nachrichten-Portale weltweit und Millionen anderer Webseiten beruhen heute auf Grids. Sind deren Designer alle blöd?

    Es kommt wie immer auf den Einzelfall an. Es gibt Texte, die liest man am Besten in ihrer natürlichen Struktur der Absätze. Un d es gibt texte, die sind einfacher zu verstehen, wenn man ihnen eine äußere Struktur mitgibt. Und vor allem gibt es immer mehr Seiten im Internet, die nicht nur einen Text präsentieren, sondern viele verschiedene anreißen, um den Leser dazu zu animieren, auf den Weiterlesenlink zu klicken. Aus solchen Seiten ist eine übergreifende Struktur in Form eines Grids absolut unverzichtbar.

    Und weil es unterschiedliche Einzelfälle gibt, gibt es auch unterschiedliche Ansätze. Und Grids sind ein guter Ansatz für etliche der Einzelfälle, aber nicht für alle. Aber sie sind nützlich, ob Dir das jetzt gefällt oder nicht.

  4. Jens Grochtdreis

    30. Mai 2008 um 19:30 Uhr

    Lieber Lothar,

    es kann sein, daß ich es nicht deutlich genug geschrieben habe – obwohl ich dies schon glaube -, aber ich habe nichts gegen den Grid-Ansatz. Ich habe überhaupt nichts dagegen, ich verstehe die Idee dahinter und glaube auch, daß sie eine Berechtigung hat. Was ich allerdings bezweifele ist, daß man Grids so umsetzen muß, wie die sogenannten Grid-Frameworks es tun. Lies Dir bitte meine Abschlußabsatz durch, dann stellst Du fest, daß ich genau das geschrieben habe.

    Daß Du Dich auf den SChlips getreten fühlst, daß ich eien andere Meinung habe, als Du, ist bedauerlich, aber ich kannd amit leben. Unterstell mir aber bitte nicht, ich würde andere Meinungen nicht gelten lassen wollen, wenn ich einfach eine dezidiert andere habe und diese auch zu begründen weiß.

    Mein Problem ist – ich wiederhole mich gerne, damit es wirkt – nicht die Idee, sondern die Umsetzung. Grids mit YAML sind auch Grids, der Code ist aber intelligenter, besser weiterzuverwerten. Blueprint und alle anderen Frameworks malen nur die alten Rezepte neu an.

    Ich bin auch sehr erstaunt, daß Du einen Unterschied zwischen strukturiert und unstrukturiert aus den Ansätzen herzuleiten vermagst. Das ist mir schleierhaft.

    Einigen wir uns darauf, daß sich Deine Gedanken nur darum drehen, wie Du möglichst schnell ein Layout für einen beschränkten Anwendungsfall – nämlich das pixellgenaue Umsetzen – abgewickelt bekommst. Ich hingegen plädiere dafür, die Flexibilität des Internet ernst zu nehmen und nicht nur in bunten Bildchen und Layouts zu denken. Wenn die Kunden dies tun, ist das noch lange keine Rechfertigung für mich, nicht für sie weiterzudenken.

  5. Ein „Grid“ ist ein Gestaltungsraster und fast jedes gute Layout ruht auf einem solchen Raster.

    Insofern ist der Name „Grid-Framework“ für Blueprint & Co. vielleicht ein bisschen irreführend, denn was Jens (und mich) stört ist nicht das Gestaltungraster, sondern der Weg dorthin, also der Quelltext, der dahinter steht.

    Andy Clarke vertritt wie weiter oben zitiert den inhaltsbezogenen Ansatz nach dem Motto „Beginnen Sie mit der Struktur“.

    Im selben Buch zeigt er weiter hinten unter der Überschrift „Denken Sie bei der Erstellung Ihrer Designs in Rastern“ wie man auf Grids basierende Layouts erstellt.

    Ich sehe überhaupt keinen Widerspruch zwischen einem strukturierten, am Inhalt orientierten HTML und einem auf einem Grid beruhenden visuellen Design per CSS.

  6. Jens, so langsam wird mir klar, was Du eigentlich sagen willst. Leider hast Du das aber in Deinem letzten Kommentar erstmals klar ausgedrückt: Du bist gar nicht gegen Grids, sondern nur gegen unflexible Webseiten. Deswegen hast Du was gegen alle Grid-Frameworks außer YAML, weil die ja alle mit festen Spaltenbreiten arbeiten.

    OK, das ist eine Meinung, die kann man haben. Aber am wahren Leben geht die Idee leider ein wenig vorbei. Und ich werde Dir auch aufzeigen, warum:

    1. Ob fest oder flexibel ist im wahren Leben eine Frage des dargestellten Inhalts, nicht der Technik, mit der das umgesetzt wird. Habe ich vorwiegend Text und die Bilder sind klein, dann kann ich problemlos ein flexibles Layout gestalten. Sind spaltenbreite Bilder vorgesehen, z. Bsp. als Spaltenköpfe, dann wird das schon erheblich schwieriger. Und spätestens bei spaltenbreiten Fotos wird es unerträglich, weil ich die für die Flexibilität mit em oder % auszeichnen müsste, was in fast allen Fällen zu entsetzlichen Ergebnissen führt.
    2. Gute und richtig eingesetzte Grid-Frameworks erfordern keinerlei zusätzliches Markup. Das heißt: Ich nehme einen semantischen Quelltext, füge lediglich ein paar Klassen hinzu, und der Inhalt wird als Grid dargestellt. Gerade hier fällt allerdings Dein geliebtes YAML böse aus der Reihe. Damit YAML funktioniert, brauche ich eine ganze Reihe unsematischer DIVs, die den Quellcode tatsächlich so aussehen lassen, als habe jemand die TRs und TDs gegen DIVs ausgetauscht. Dies ist also keine Frage von Grids als solchem, sondern eine Frage des richtigen Frameworks.
    3. Wenn denn flexibel gut ist und unflexibel schlecht, dann frage ich mich allerdings, warum dann dieses Blog hier ein unflexibles Layout hat. Und die Website Deines Arbeitgebers. Und dessen Blogs. Und alle Websites in den Referenzen Deines Arbeitgebers, alle!
    4. Wenn Du darüber verwirrt bist, wie ich den Unterschied zwischen strukturiert und unstrukturiert aus den Ansätzen herleite, dann musst Du vielleicht einmal mindestens genauso viel Zeit für das Studium der Informations-Architektur aufwenden, wie Du übrig hast, um gegen Blueprint und seine Nachfolger zu wettern.
    5. Du kennst den Markt, über den Du hier urteilst, nicht wirklich. Es gibt durchaus Grid-Frameworks, die flexibel sind, z. Bsp Typogridphy, das komplett mit EMs bemaßt ist.

    Deine Betrachtungen sind rein philosophisch. Und gehen an der alltäglichen Design-Praxis vollständig vorbei. Es geht nicht darum, ob ich den philosophisch richtigen Weg wähle, um ein Ziel zu erreichen. Es geht erst mal nur um das Ergebnis. Ist das Ergebnis so, wie es der Kunde haben wollte, dann bezahlt er die Rechnung. Ist das Ergebnis nicht so wie es der Kunde wollte, dann zahlt er trotz philosophisch richtigem Ansatz keinen Cent. So einfach ist das wahre Leben. Und in diesem wahren Leben befinde ich mich jeden Tag in meiner Berufspraxis. Deswegen fühle ich mich auch nicht auf den Schlips getreten, weil Du eine andere Meinung hast als ich. Ich erlaube mir nur, Deine Meinung als nicht zielführend zu kritisieren. Punkt.

    Wenn Du nach wie vor der Meinung bist, Du währst im Recht, dann beweise mir das mit Webseiten, die Du oder Dein Team bei Deinem Arbeitgeber geschaffen hast. Solange die öffentlich sichtbaren Ergebnisse Deiner Arbeit so aussehen, wie sie aussehen, solange machst Du Dich nicht gerade glaubwürdig. Nochmal Punkt.

  7. @Lothar
    Zu 1: Es geht eben nicht nur um die Frage fixes oder flexibles Layout. Dein Beispiel mit spaltenbreiten Bildern kann ich auch nicht nachvollziehen, kannst du mal ein Beispiel nennen, wo das bei den unzähigen flexiblen Webseiten zu entsetzlichen Ergebnissen führt?
    Zu 2: „kein zusätzliches Markup“ und „füge lediglich ein paar Klassen hinzu“ widerspricht sich doch, oder? Und ja: YAML ist kein Fertig-Baukasten. Damit YAML funktioniert, sollte man es anpassen. Wer was fertiges will, solte fertige Lösungen nehmen wie die Provider-Baukästen oder Fertig-Templates.
    Zu 3: es geht doch um den medienkonformen Workflow, das heißt , wie ich eine Website erstelle und nicht, wie ich die Vorgaben eines Grafikers oder meines fixen Photoshop-Templates pixelgenau umsetze. Das kann dann aber trotzdem ein fixes Layout sein, wenn es angemessen ist, das kann auch deine GridEasy-Lösung sein, die als schnelle Lösung für ein fixes Layout durchaus überzeugt. Dann muss man sich und dem Kunden aber auch klarmachen, dass PC-Monitore heute und zukünftig nicht mehr eine Auflösungsfenster von 800×600 bis 1024×768 haben, sondern bis 1900×1200. Auf denen wird das Browserfenster individuell vergrößert oder verkleinert, inklusive oder vielleicht auch exklusive Toolbars, Tab-Spalten oder Lesezeichen. Und dann kommen die mobilen Anwendungen im Miniformat, nicht mit separatem Stylesheet, nein, im Vollbildmodus. Das iPhone und ähnliche Geräte sind da nur der Anfang einer weiteren Evolution.

    Grids, pixelgenaue Layouts und viele andere Aspekte im Webdesign kommen aus den klassischen Medien, die meisten aus dem Printbereich, einige auch aus dem Bereich bewegter Bilder (z.B. Ken-Burns-Effekte beim Fading/Überblendungen). Aber: das Potential des Webs und damit die Möglichkeiten einer Webseite halte ich persönlich für weitaus größer als die der klassischen Medien zusammen.

    Print ist beschränkt auf einen verfügbaren Platz in der Image-Broschüre, dem Faltblatt oder gar der Visitenkarte. Da bleibt mir nichts anderes übrig, als die Inhalte an das Format anzupassen. Und da gibt es Jahrzehnte der Erfahrung, wie ich das perfekt umsetzen kann, damit es bei den Lesern und Betrachtern des gedruckten Gegenstandes zielgerichtet funktioniert. Bei der Zeitung reichten über Jahrzehnte schwarz-weiß-Bilder und ein einhetliches Gestaltungsraster.

    Kurios finde ich, dass Grids als die große neue Zauberformel des Webdesigns angesehen werden – meine warme Empfehlung dazu: Joseph Müller-Brockmann: Grid systems in graphic design, Hatje Verlag Stuttgart. Erstauflage: 1981.

    Die Möglichkeiten der ersten Designer im Web reichen, um Webseiten zu erstellen, die die Nutzer seit damals kennen. Mehr Anspruch ist dann aber auch nicht vorhanden. Das Web ist einer Evolution unterworfen und gerade mal 10 Jahre in der Gesellschaft zuhause. Es geht doch darum Wege zu suchen, die für das Medium Web auch angemessen sind. Ein Beispiel: Die ersten Waffen der Bronzezeit waren nicht gleich die gefürchteten Streitäxte der Ägypter. Die ersten Bronzebeile sahen exakt so aus wie die letzte Generation der Exemplare aus Feuerstein. Groß, schwer, klobig: nur dem spröden Material des Steins angemessen. Das unendlich größere Potential des Metalls bezüglich Funktionen, Größe und Gestaltung wude erst langsam und durch die kreativen Versuche entdeckt, die auch danach suchten.

    Schmied war als Beruf damals übrigens so neu wie heute Webdesign, auch er wurde mit Geheimwissenschaft und Voodoo in Verbindung gebracht, dass er es sogar bis zur Gottheit (Vulkan) gebracht hat. Und damit wieder alle zurück an den Amboss.

  8. Jens Grochtdreis

    31. Mai 2008 um 15:02 Uhr

    Hallo Lothar,
    ich frage mich langsam, ob es an mir oder an Dir liegt, daß Du meinen Grundansatz nicht verstehst. Mir geht es nicht um flexible oder fixe Designs. Ich selber habe immer nur fixe Designs entworfen. Der Kunde will es nicht anders, die Desigern kapieren es meist nicht anders.
    Für mich selber habe ich hier übrigens nur ein Fremddesign gewählt, weil es mir damals gefiel, ich kein Designer bin und mir lieber die Zeit für andere Projekte nehme, als das Design meines Blogs.

    Noch einmal: ich habe nichts gegen Grids, ich habe nichts gegen fixe Designs. Die Flexibilität von der ich spreche, liegt im Quellcode begründet. Ich schreibe ja deutlich, daß man bei den Grid-Frameworks das Design durch die Zuweisung bestimmter Klassen regelt. Die Klasse sagt dann „Du bist 380px breit“. Wenn ich den gleichen Seitenbereich 560px breit machen will, muss ich das HTML ändern. Beim „normalen“ Ansatz ändere ich nicht die Klasse. Da ändere ich das CSS. Ich ändere die Layoutinformation, nicht dessen Verknüpfung im HTML.

    Dies erinnert mich zu sehr ans Tabellendesign. Und diese Vorgehensweise wünsche ich geändert. Wenn Du Dich so intensiv damit beschäftigt haben willst, ist Dir nie aufgefallen, daß Du die selben Arbeiten machst, wie noch zu den Anfangszeiten des Web? Nur mit dem Unterschied, daß Du keine Tabellenzellen definierst?

    Du kannst mein Unbehagen mit diesem Vorgehen ruhig als philosophisch abtun. Das empfinde ich als Ehre, denn neben all denen, die nur daran denken, wie sie schnell ihre Jobs abgewickelt bekommen, muss es auch Leute geben, die versuchen, ein bischen weiter zu denken. Nur dann können wir unsere Art, Webseiten zu entwickeln, optimieren.

    Ich habe übrigens letztens selber an der Arbeit ein kleines Grid-Framework entwickelt. Es ist einfach in der Anwendung. Aber ich bin nicht davon überzeugt, daß es eine kluge Idee war. Natürlich habe ich auch nicht ewig Zeit, Grundsatzforschungen auf Rechnung meines Kunden anzustellen. Aber privat kann ich dies und ich werde nicht müde, dies auch von anderen einzufordern. Denn wir wollen doch hoffentlich alle, daß das Internet voran kommt.

    Grid-Frameworks erfordern immer die Modifikation des Markups. Auch die, deren Ergbenisse dank EM flexibel sind. Die Flexibilität im Aussehen ist nicht mein Punkt, das möchte ich nochmal betonen. Es ist die Flexibilität in der Anwendung. Du kannst mit Deinem Gird-Easy nicht einfach eine Navigation von links nach recht schieben, indem Du das CSS änderst. Du mußt eine andere Klasse zuweisen und evtl. die Code-Reihenfolge ändern. Wo ist da der Unterschied zu Tabellen und wo ist da die Hilfe für den Anwender?

  9. Nah, sag ich doch: philosophisch. 😉

    Natürlich hast Du theoretisch Recht mit all dem, was Du im letzten Kommentar geschrieben hast. Aber es ist nur ein Teil der Wahrheit, und es ist eben theoretisch, nicht praktisch. Die Praxis ist leider in der anderen Hälfte der Wahrheit verborgen. Und diese andere Hälfte ist die kommerzielle. Und die bestimmt leider die Spielregeln.

    Ich nenn Dir gerne ein konkretes Beispiel: Letzte Woche hatte ich eine Anfrage von jemand, der mich wie so oft über meine Website gefunden hat. Der wollte einfach von mir wissen, was es kostet, seine bisher statische Website in ein WordPress-Theme zu konvertieren. Ich habe ihm gesagt, dass ich mir die jetzige Website erst ansehen müsse, um den Zeitaufwand kalkulieren zu können.

    Diese statische Website war ein typisches Frontpage-Tabellenverhau mit ganz vielen „Font“-Tags. „Optimiert für Netscape“ – Du weist, was das heißt. Und natürlich auf jeder Unterseite ein wenig anders. Ich habe ihm dann eine Mail geschrieben, wo ich ihm eine vernünftige Summe genannt habe, bei der ich auch ein wenig verdiene. Was war die Antwort?
    „Viel zu teuer! Ich habe bei myHammer jemand gefunden, der macht mir das für 80 Euro.“

    Das ist die andere Hälfte der Wahrheit. In diesem Business habe ich überhaupt nur dann noch eine Chance, Aufträge zu bekommen, wenn ich optimiert arbeite. Und genau dafür hab ich mir GridEasy geschrieben. Weil ich damit bei jedem Webprojekt mehrere Stunden Arbeit einspare. Nicht nur, weil die Seite schneller steht, sondern vor allem, weil 90% der Internet-Explorer-Fehler-Vermeidung schon vom Framework erledigt worden ist. Und ich dadurch besser mit dem „Neffen vom Onkel meiner Cousine mit der Frontpage-Lizenz“ konkurieren kann.

    So sieht das wahre Leben des Freelancers aus. Die ganz großen Kunden, die krieg ich als One-Man-Show nicht. Die gehen zu einer der großen Agenturen, z. Bsp. zu Euch. Und die kleinen feilschen wie Hölle. Würde ich nicht mit Hilfsmitteln wie Frameworks arbeiten, dann wäre ich schon längst Harz-4-Empfänger. Und meine Jobs würden von jemand anderes mit Frontpage, Netobjects Fusion oder ähnlichem gemacht.

    Und jetzt frage ich Dich: Was ist besser für die Zukunft des Webdesigns – Frameworks oder Frontpage? Das ist hier die Shakepeare-Frage, die gestellt werden muss. Und wenn man die vermeidet, sich rein philosophisch auf die Seite des Reinen, Schönen, Guten stellt, dann wird man nicht mehr lange in dieser Branche überleben können. Und die Zukunft des Webdesigns gehört wieder Frontpage, oder heute wahrscheinlich Golive oder dem „Webseitenbaukasten“ irgend eines Providers.

    Deshalb ist Deine Meinung, so richtig sie theoretisch auch ist, im wahren Leben einfach falsch. Sie lässt den wichtigsten Faktor unbedacht – das Geld. Und das regiert bekanntermaßen die Welt, und wir beide werden das auch mit noch so guten Absichten so schnell nicht ändern können.

    Das ist wie mit dem Umweltschutz. Natürlich währen eine Menge alternativer Antriebskonzepte besser für die Umwelt als das Verbrennen von Erdöl. Und natürlich haben wir da schon einige fertige Konzepte in der Schublade. Aber werden die bei Volkswagen gebaut? Oder bei Daimler? Nein. Und weder Du noch ich haben das Geld für den Aufbau einer Fertigungsstraße für umweltverträglich Autos. Und genau deshalb wird man auch in einigen Jahren noch Autos mit Benzin-Motoren kaufen müssen, weil die anderen immer noch nicht gebaut werden. Das ist sicherlich schlecht für die Umwelt, aber das wahre Leben. Nicht mehr und nicht weniger.

  10. Jens Grochtdreis

    31. Mai 2008 um 17:58 Uhr

    Lothar,
    ich kenne einige Selbständige, dioe mit Frameworks arbeiten und sich so ihre Arbeitszeit verkürzen. Dein Postulat ist falsch. Sagst Du ja eigentlich auch selbst, denn Du hast Dir ja ein eigenes Framework entwickelt.

    Deinem myHammer-Kunden ist sowieso nicht zu helfen. Dem würde ich nicht hinterher laufen, denn er macht Dir am Ende nur mehr Ärger als Profit. Er glaubt den Computerzeitschriften, die „eine professionelle Webseite in 5 Minuten“ versprechen. Es ist unsere Aufgabe diesen Menschen zu kommunizieren, daß das alles nicht so simpel ist.

    Meine „philosophische“ Sicht hat einzig und allein den Zweck, ein gutes Endergebnis mit einer sinnvollen und guten Nutzung seitens des Entwicklers zu erreichen. Derzeit ist das Ergebnis nicht gut, nur die Nutzung. Ist es falsch, das zu wünschen?

    Wenn Du keine Lust hast, die Qualität Deiner Arbeit zu steigern, sondern nur an Effektivität denkst, dann ist das schade und nur mittelbar mein Problem.

  11. Jens, es wäre schön, wenn Du meine Kommentare auch lesen würdest. Es geht hier nicht um Effektivität, sondern ums Überleben in einer Branche, wo der größte Teil der Konkurrenz viel schlimmeres produziert als ich. Aber offensichtlich kannst Du Dich als Angestellter nicht wirklich in meine Situation als Freelancer hinein denken.

  12. Also ich renne solchen Kunden nicht hinterher. Nicht mal, wenn ich ein Script hätte, welches die Webseite generiert 😉
    Ich habe gerade ein Template auf YAML Basis fertiggestellt, wo man auf Knopfdruck auf 2,3 oder 4 Spalten wechseln kann. Ich glaube nicht, das ich für den HTML Code länger gebraucht habe als irgend ein Anderer. Und ja, es sind um jeden Artikel 2 Container. Dafür kann ich aber zB. den Abstand der Container zueinander im CSS regeln, ohne das etwas kaputt geht oder dass ich andere Klassen im HTML Quellcode definieren muss. Es passt sich dem Browserfenster und der Schriftgröße perfekt an. Hier der Beitrag dazu.

  13. Lothar, ich glaube, deine gesamte Diskussion mit Jens basiert allein darauf, dass ihr euch falsch verstanden habt.
    Auch die Diskussion um Freelancer, Qualität und Nutzung von Frameworks geht aus meiner Sicht vollkommen an dem vorbei, was Jens in seinem Beitrag heraus stellen wollte. Ihm ging es allein um technisch-konzeptionelle Grundüberlegungen zur Umsetzung eines Layouts, und nicht um das »Überleben in einer Branche«, die wie auch immer gestrickt ist.

    Und bitte nicht zum »Kleinkrieg« stilisieren (siehe dein Beitrag bei blogpimp). Es sind schlicht essentielle Überlegungen zur Layoutentwicklung, die hier und nebenan ausgebreitet werden.

    —–

    Danke für den interessanten Beitrag, Jens!

    Ich hatte nie mit Blueprint zu tun, kenne also seine Funktionsweise nicht. Aber so, wie du es beschreibst, sehe ich es wie du als den falschen Weg an, ein Layout umzusetzen.

    Uneingeschränkte Zustimmung für deine letzten drei Absätze.

  14. Ein solider Beitrag mit berechtigter Kritik an Grid-Layouts, aber mir ist er – ehrlich gesagt – noch ein wenig oberflächlich und eindimensional. Ich hab das schonmal bei Dirk Jesse geschrieben, da allerdings im Zusammenhang mit fix vs. flexibel: Es ist nur eine neue Ausprägung, die neue Möglichkeiten eröffnet – Grid-Frameworks sind eine möglicher Alternative für den, der es braucht. Dazu zähle ich persönlich vor allem Print-Designer, die bis heute noch nicht verstanden haben, dass Websites heute mehr denn je vom Ausgabegerät abhängen.

    Jens hat das schon richtig herausgearbeitet: Es ist eine Frage des Vorgehens. Fange ich beim Pixelschubsen an oder bei der Technik? Und wenn ich beim Pixelschubsen anfange, hab ich dann auch an die Technik gedacht, an die Semantik, an alles, was jenseits des absolut positionierten Pixels liegt? Jedes vernünftige Layout folgt einem Raster, aber Bildschirme sind so unterschiedlich, wie die Benutzer davor / dahinter. Das Grid-Layout ist tot, lang lebe das Grid-Layout.

  15. Manueller Trackback:

    Mai 2008 im Kontext | Darf’s ein bisserl billiger sein?
    http://hyperkontext.at/weblog/artikel/mai-2008-im-kontext/#darfs-ein-bisserl-billiger-sein
    […]Genau das was Jens Grochtdreis also an den fix positionierten Grid-Konzepten kritisiert wird bald in den bekannten Web-Editoren eingebaut sein.[…]

  16. @Lothar,
    du tust mir echt leid, wenn du zum überleben als Freelancer Websites für 80 € basteln musst, um zu überleben.

    Das, was Jens hier schreibt, ist vollkommen richtig, nicht nur theoretisch, es trifft zum Beispiel praktisch genau auf deine Seite zu:
    Wenn man sich den Quelltext im Portfolio anschaut, sind dort div-tags anstelle von Tabellen-Tags 1 zu 1 nachgebildet. Also Markup à la 1998.

    Genau das zeigt Jens mit seinem Artikel auf.
    Und das ist auch gut so!

    Die Tatsache, dass du keine Möglichkeit siehst, als Freelancer ohne solch hier aufgezeigten schlechten Frameworks am Markt zu bestehen, hat nichts damit zu tun, dass diese für die Zukunft des Mediums Web nicht der richtige Weg sind.

    Für dich pers. mag es keinen anderen Weg geben, für das Web an sich aber sicherlich schon. Nur muss es auch Leute geben, die darüber nachdenken.

  17. Nachtrag:
    Zitat Lothar:
    „Deshalb ist Deine Meinung, so richtig sie theoretisch auch ist, im wahren Leben einfach falsch. Sie lässt den wichtigsten Faktor unbedacht – das Geld. Und das regiert bekanntermaßen die Welt, und wir beide werden das auch mit noch so guten Absichten so schnell nicht ändern können.“

    Du lässt auch einen wichtigen Faktor außer Acht: Qualität. Es gibt auch Kunden, die darauf Wert legen und auch zu schätzen wissen. Das sind nicht nur die großen.

  18. Gedanken, die mir „durch den Kopf schossen“:

    1. Wer sich mit „Kollegen“ messen muß, die ein Projekt für 80 EUR anfertigen, hat möglicherweise zu wenig Selbstvertrauen und/oder keinen Stolz.
    Von eventuell fehlendem Wissen und Erfahrung mal ganz abgesehen…

    Ich versuche nicht einmal mit Leuten zu konkurieren, die sich für 250 oder 300 EUR verkaufen. Punkt.

    Wenn Kunde billig will, soll er billig haben.

    Ein einigermaßen gutes Projekt mißt sich auch nicht nur nach dem Layout, sondern auch nach Zugänglichkeit, Benutzbarkeit und Sicherheit.

    Das macht oft genug den Unterschied.

    2. Ich verstehe auch die ganze Aufregung nicht und halte es eher mit Jens: Erst die Projekt- und Inhaltsstruktur, dann „darüber“ das CSS.

    Ob man dazu nun Grids, in welcher Form auch immer braucht, weiß ich nicht.

    Wer schon mehr als 2 Projekte gefertigt hat, wird auch vielleicht auf seine immer wieder verwendeten IDs und Klassen) zurückgreifen – die Namen hat man im Kopf und die wesentlichsten Formatierungen sind auch vorhanden. Ein bischen Modularität dazugeben, umrühren, fertig.

    Es gibt doch Inhalts- oder Seitenelemente die immer wieder verwendet werden.
    Beispiel: Formulare. Einmal mit standardkonformen und semantisch korrektem Markup entworfen ist es ein leichtes, diese über CSS an verschiedene Layouts anzupassen.

    Wo also ist das eigentliche Problem…
    Aber vielleicht bin ich auch zu blöd, den großen Vorteil jeglicher Grids zu verstehen.

  19. Peter: Keine Panik, bist nicht der einzige, der den Vorteil nicht kapiert.

    Ich sehe in Grids zumindest für Hobbyenthusiasten eine Möglichkeit, halbwegs praktisch eine eigene Website auf die Beine zu stellen. Es gibt Anleitungen, es gibt Erfahrungsberichte, auf die man sich stützen kann und anhand derer man dazulernt.

    Der hier oftmals angesprochene Profi, der damit sein Geld verdient, hat es meiner Meinung nach nicht nötig, Grids zu nutzen.

    Semantische Struktur die mit CSS gestaltet wird sind dessen Handwerkskunst, die er schlicht und ergreifend im Schlaf können muss. Wer sich hier um einen „Konkurrenten“ (sowas ist für mich keine Konkurrenz) um 80 Euro kloppt, der sollte seine Geschäftsstrategie überdenken.

    Freelancer-Business ist hart, aber auf dem Türschild stand auch nicht Takka-Tukka-Land. Gewöhnt euch dran.