Der Adobe-Store bietet zwar per Default die Möglichkeit die drei Images (Upgrade plus zwei Bonus-Image-Dateien mit Fonts) mit einem eigenen Download-Manager runterzuladen. Als Option gibt es aber den direkten Download-Link, so dass man sich die Installation der drei(!) Download-Manager schenken kann.

Das In-Die-Pfanne-Hauen von Adobe-Software ist bei mir neben meiner alljährlichen Bundesliga-Sonderheft-Verisse an anderer Stelle schon eine Art Lieblingssport.

Grundsätzlich finde ich es erstaunlich, wenn Produkt-Upgrades nach nur 18-24 Monaten hyperventilierend damit beworben werden, dass man nun eine neue Super-Duper-Workflow-optimierte GUI hat … nur damit 18 Monate später die nächste komplette, nach neuesten UX-Erkenntnissen überarbeite GUI ins Haus steht.

Im Falle von Adobe kommt erschwerend hinzu, dass die einzelnen Software-Produkte nicht näher zusammenkommen, sondern in der Bedienung immer weiter auseinander bewegen. Ich warte immer noch auf das Zusammenführen der GUIs der 2005 gekauften Macromedia-Produkte mit den Adobe-Produkten. Mit CS6, sieben Jahre nach Aufkauf von Macromedia, sind Photoshop und Fireworks weiter auseinander denn je – sowohl in den groben Bedienungskonzepten, als auch in den Details wie zum Beispiel die Formen der Klappmenüs.

Und das will mir bei einer Firma wie Adobe, die Tools für Gestaltung, UI und UX zur Verfügung stellt, schlichtweg nicht in die Birne (eating your own dog food).

Beim ersten Durchmarsch durch die Applikationen am gestrigen Abend ging mir schon eine erste Flut an Anmerkungen durch den Kopf. Mal sehen ob ich irgendwie sortiert bekomme.

Es sind interessante Änderungen, es sind Umstellungen, es sind Verschlechterungen und es ist teilweise auch gar nichts passiert. Photoshop CS6 dürfte den größten Sprung gemacht haben und man sollte es als Chance begreifen, seinen Workflow zu überprüfen und zu überdenken. Wie bei einem neuen Gadget gibt es viele neue Knöpfe und Schalter die zum Ausprobieren einladen.

Das was Adobe da aber unter einem Hut “Creative Suite” zu verkaufen versucht, wirkt in CS6 weniger den je wie eine gemeinsame Familie. Während Photoshop CS6 weiter mit teilweise branchenfremden Features (Video???) gepimpt worden ist, scheint bei Fireworks CS6 nix passiert zu sein. Seit CS4 wirkt Fireworks als würde es um den Gnadenschuss betteln und CS6 scheint dies nicht zu ändern. Ich kenne Telefonbücher die sich interessanter anhören als die “What’s new?”-Liste von FW CS6.

New fw.png filename extension […] Use buttons to specify fill type options such as no fill, solid, gradient, and patterns in the Property inspector and Tools bar. Previously, these options were handled through drop-down menus […] You can now specify Stroke position (inside, center, outside) using the Stroke dialog box […] Set the angle for gradient or pattern fills […]

Vierzehn Jahre nach der ersten Version von Fireworks wird hier ein ganzes Feuerwerk (sic!) von Neuerungen abgefackelt. Neue Dateiendung “fw.png” weil zuviele die Fireworks-Quelldatei mit “echten” Websafe-PNGs verwechselt haben? Nach 14 Jahren: Burner!

Massiv beworben wird derzeit die Adobe Creative Cloud. Statt sich ein Upgrade zu kaufen, kann man die Adobe-Software für 37-61 Euro pro Monat (nein, ich habe keine Ahnung wie Adobe die Preise umrechnet) mieten – solange man die Miete zahlt, hat man Zugriff auf alle Softwareprodukte von Adobe.

Ich kann nicht nachvollziehen worin für einen Selbständigen wie mich der Reiz der Cloud liegen soll, da man i.d.R. als Selbständiger nicht die komplette Palette von Video über Audio, Grafik, DTP, DVD-Authoring, Web Design und Flash abdecken wird – und bei kleineren Aufgabengebiete kommen die CS-Pakete billiger als die Suite.

So… weiter mit der Arbeit.

Gleich der erste Vortrag “CSS for Grown Ups: Maturing Best Practices” von Andy Hume erwies sich als Volltreffer. Audio (MP3, ca 58min), Slides (Speakerdeck)

Hume stellt natürlich gewachsene Paradigmen der Web Standards-Bewegung in Frage, insbesondere die bisher propagierte Trennung zwischen ausschließlich semantischen HTML-Markup und ihre Verdrahtung mit CSS.

Von dem Gedanken “das HTML-Markup hat keinerlei Informationen über das Design zu besitzen” geht Hume schnell weg und spricht vom Markup als eine Art “API” für die Gestaltung per CSS. Das Andocken von Gestaltung z.B. an einem H2-Element sei aber weder semantisch, noch flexibel. H2 kann z.B. innerhalb einer Website im Kontext “Homepage” eine Artikel-Headline darstellen, aber im Kontext “Artikel-Seite” die Subheadline des Artikels sein, während dann dort die Headline als H1 ausgezeichnet ist.

Für denjenigen der im CSS-Code rumwühlt, erschließt sich durch das reine Markup nicht, welche Bedeutung Elemente wie H1 oder H2 haben. Noch schlimmer: das CSS eskaliert und wird komplexer, weil es für unterschiedliche Kontexte unterschiedliche Elemente berücksichtigen muss:

#page-home H2,
#page-single H1 {
	font-size: 36px;
}

Wäre es aus CSS-zentrischer Sicht nicht semantischer, das CSS nicht an Elementen, sondern an Klassen anzuhängen?

<h1 class="headline">Suppenwürfel machen Krebs!</h1>

.headline {
	font-size: 36px;
}

Diese Parallel-Existenz von Semantik mit HTML-Element und Sematik mit CSS-Klassen war bislang verpönt und ein Bruch der klaren Trennung von Markup und Gestaltung.

Die Zeiten haben sich aber geändert. Wir reden nicht mehr von Firmen-Websites die sich in zehn HTML-Seiten abfrühstücken lassen, wie einst 2004, sondern von komplexen, datenbank-gesteuerten Sites und Applikationen, deren CSS-Code locker eine vierstellige Zahl von Zeilen umfasst.

Wird das CSS nicht dadurch flexibler und sogar semantischer wenn beschreibende Klassen verwendet werden wie

<a href="#" class="button button--large is-disabled">Remove</a>?

(Man beachte dass die “Beschreibung” hier ebenfalls semantischen Wert hat und nicht wie “button--100px” oder “button--green” aufgebaut ist!)

Es hebe derjenige die Hand, der noch nie eine beschreibende CSS-Klasse wie “button” verwendet hat…

Trotzdem: ich fand dies in dieser Konsequenz gewöhnungsbedürftig und bin schlichtweg an der Grenze der Überforderung, wenn Hume dann auch noch vorschlägt, HTML-Elemente über Javascript als Trigger für CSS-Klassen zu nehmen:

<div data-squery="min-width:400px=wide max-width:10em=small">

Hume hat dazu selector-queries geschrieben, die das obige Attribut “data-squery” auswerten: wenn der DIV-Container schmaler als 10em ist, bekommt er die Klasse small. Ist er breiter als 400px, bekommt er die Klasse wide. Ansonsten bleibt die Klasse leer (was nicht immer das Oberoberoptimalste als Fallback für Javascript-lose Clients ist).

Gefiel mir auf Anhieb nicht wirklich, aber je länger ich darüber nachdenke, ist dies für viele Websites vielleicht sogar der richtige Schritt um CSS-Module voneinander unabhängiger zu machen, denn Media-Queries in CSS arten quick in verschachtelten Spaghetti-Code aus und kommen in Sachen “Responsive Images” schnell am Ende ihres Lateins.

Ein zweiter zentraler Punkt des Vortrages von Hume ist die Strukturierung von CSS in möglichst unabhängigen Modulen: “Don’t style pages, style modules.”

Ein Qualitätsmaßstab für Module ist ihre Unabhängigkeit von CSS-Code außerhalb des eigentlichen Module-CSS und ließe sich testen, indem man die Module in anderen Kontexten (Seitenleiste vs Content-Bereich) oder in der als Website angelegten Dokumentation ablegt.

Für den Workflow ist dies an zwei Punkten ein weitreichender Move. Es ist ab einem bestimmten Punkt das Verlassen der gewohnten “Top-Down”-Produktion einer Website und die komplette Abstraktion eines Moduls von ihrem zukünftigen Bestimmungsort.

Es ergibt sich daraus die interessante Frage der Dateiorganisation innerhalb eines Projektes. Auch hier ist CSS noch auf der Suche nach Best Practice. Hume schlägt drei Kategorien von Stylesheets vor, durch die eine Aufgabenteilung bewirkt wird, die die Übersichtlichkeit erhöhen soll und damit den Code pflegbarer machen soll – auch hinsichtlich des Recyclings von Modulen.

• Base – Styles für Elemente, das Fundament der Website für site-weite Eigenschaften wie Link-Farben, Schriften, Schriftgrößen
• Module – eigenständige Module wie “Einklinke”, “Link-Box”
• Layout – Layout der Seite wie z.B. Spalten

Es gibt andere Versuche der Strukturierungen für CSS wie OOCSS, BEM oder SMACSS.

SMACSS definiert fünf Kategorien von Stylesheets:

• Base – Stellt die Default-Gestalltung für HTML-Elemente, Attribute und Pseude-Classes dar.
• Layout – Grober Seitenaufbau über die Ansprache von single-class- oder id-Selektoren.
• Moduls – Wie bei Hume handelt es sich um wiederverwendbare Module wie Poduktlisten, die über classes angesprochen werden.
• State – Beschreibt die Zustände von Layouts oder Modulen wie “enabled”, “hidden”, auch in Kontexten wie für Mobile-Clients etc…
• Theme – Selbsterklärend.

Aktuell sitze ich an einer ähnlichen Struktur (SASS-basierend: Values – Mixins – Generic – Elements – Modules) – allerdings für eine hoffnungslos kleine Website und es fühlt sich nicht korrekt an für so eine kleine Website zwischen fünf unterschiedlichen SASS-Dateien zu springen.

Die Suche nach Best Practice wird auf Jahre nicht vorbei sein und bis dahin noch in viele Sackgassen gegangen werden, noch viel Overhead produziert und noch viele Kundenprojekte als Testlabor dienen.

Im letzten Sommer arbeitete ich zusätzlich für vier Monate bei einem Hamburger IT-Unternehmen fünfmal die Woche in einem nine-to-five-Job (besser: ten-to-five). Sehr interessante Monate, weil ich zum ersten Mal seit meiner Angestelltenzeit 1996, über einen längeren Zeitraum Tag für Tag in einem größeren Team arbeitete und dort neue Workflows kennenlernte, u.a. sehr streng durchgeführtes Scrum zum Projektmanagement.

Das kam on-the-top zu meiner normalen Tätigkeit als Selbständiger und mit allesaussersport dazu. 60 bis 80 Stunden-Wochen, inkl. Aufstehen um kurz vor Sechs und Arbeiten an Wochenenden waren die Regel.

Der Oktober war etwas zum Verschnaufen da, aber vom November bis Februar ging es weiter. Ein Projekt das ursprünglich bis Mitte Dezember gehen sollte, aber in der ersten Hälfte plötzlich mit soviel mehr Funktionalität aufgeladen wurde, dass die Deadline auf Anfang Februar gelegt wurde. Man versetze sich in meiner Lage: ich wankte durchaus erschöpft gen Jahresende doch statt endlich einige laue Monate in Aussicht zu bekommen, hatte ich plötzlich ein Projekt an den Hacken, dass ich nicht los wurde – und dessen Workflow aus technischen Gründen (Remote Server, proprietärer Tunnel-Client) enervierend waren. Aus Anfang Februar wurde wegen weiterer Features der letzte Februar-Tag. Auf der letzten Rille wurde das Projekt fertiggestellt.

Der Dezember, Januar und Februar waren für mich schlimme Monate. Der Akku war komplett leer. An den Wochenenden war ich antriebslos. Und an den Wochentagen stellte ich mir immer wieder die Sinnfrage. Einer der Projektleiter fragte mich später für ein anderes Projekt an: “Wir haben da nochwas in der Pipeline. Möchtest du HTML runterschrubben?”

Ich weiß wie er es gemeint hatte, aber die Formulierung “HTML runterschrubben” war ein guter Ausdrucks des Dilemmas das ich seit Dezember fühlte.

Im Akkord arbeiten. Keine nachhaltigen Lösungen. Kein Nachdenken, kein Herumexperimentieren, kein Ausprobieren.

Und dies zu einem Zeitpunkt, an dem der HTML/CSS/Javascript-Bereich (vulgo: Frontend) einschneidende Änderungen erlebt und komplett im Fluss ist. An dem alle in der Frontend-Branche verzweifelt nach optimalen Workflows und Best Practice suchen.

Irgendwas passte nicht zwischen dem was ich wollte und brauchte, dem was mir für die Zukunft wichtig war und dem was ich als Aufträge bekam. Der Herunterschrubber-Dienstleister-Weg schien mir in die Sackgasse zu führen.

Im Dezember traf ich die Entscheidung 2012 aus der aktuellen Bürogemeinschaft auszuziehen und stattdessen in eigene Räumlichkeiten zu gehen. Außerdem versuche ich den Kunden nur noch drei Tage die Woche anzubieten.

Ich war jetzt 13 Jahre in Bürogemeinschaften. Zumindest in den letzten ca. sieben Jahre hat sich das so hoch gehaltene Wort “Synergieeffekte” sehr in Grenzen gehalten. Ich will nun in die andere Richtung gehen und mich in meinen Büro abschotten können, mehr in Richtung Labor, Ruhe und Konzentration gehen. Ich will ganz bewusst in meinen eigenen Saft schmoren.

In den nächsten sechs Wochen werde ich ausziehen. In den nächsten 10 Tagen werde ich mich für ein Büro entscheiden. Und danach hoffen ich auf mehr Ruhe. Im Leben und in der Arbeit.

Nick Denton ist der Macher hinter Gawker Media, das Unternehmen das Blogs wie Lifehacker, Gizmodo, Gawker oder Deadspin unterhält. Denton propagierten Journalismus mit Wirkung genauso wie Gossip mit Veröffentlichung von Fotos mit Sportler-Genitalien.

Vor einem Monat stellte er sich bei der SWSX in Austin einem einstündigen Interview mit Anil Dash zum Thema “The Failure of Comments“ das ich zum Nachhören ans Herz lege, da Denton sehr, sehr viele interessante Gedanken entwickelt, wie Web-Publikationen mit Kommentaren und Konversation im Internet umgehen sollten.

Wo Denton herkommt, zeigt seine Aussage aus den ersten Minuten des Interviews über die Motivation Gawker zu starten:

I was struck how the conversations you’d have with journalists after deadline were far more interesting than what would appear in the newspaper the next morning. It was the story behind the story, and we turned that into a business.

Wie kann man diese Art von Konversation in den Blogbeiträgen pflegen? Wie kann man die derzeit vorherrschende Kultur der negativen Kommentare, der beißenden, zynischen Beschimpfungen stoppen ohne gleichzeitig Diskurs und kontroverse Meinungen abzuwürgen?

Denton sieht Facebook-Kommentare sieht zwar als eine Möglichkeit für einige Websites an, aber er hält Anonymität der Kommentare für ein wichtiges Gut um an gute Inhalte zu kommen.

Als gescheitert sieht er Versuche der Gamification von Kommentare – auch bei Gawker – in dem zum Beispiel Sterne für Kommentatoren verteilt werden. Denton: “Wer will denn wirklich ‘Sternchen’ bekommen? Sind die guten Kommentar-Schreiber wirklich auf Sterne aus? Nein.”

Die Hürden für “Kommentatoren-Erstlinge” sieht er noch als zu hoch: die Anmeldung und die Hemmschwelle vor der Partizipation.

Einen Weg den Gawker in den nächsten Wochen beschreiten will, ist die Übernahme der Verantwortung für die Kommentare durch die Kommentatoren selber. Nicht in Form eines generischen Bewertungsprozesses, der eine Eigendynamik lostritt, die sehr schnell nichts mehr mit den Inhalten zu tun hat. Sondern in Form von: jeder Kommentator wird Kurator für den Thread den er startet. Die Vision von Denton ist es, dass die Subjekte der Artikel selber die Hemmungen verlieren, in den Kommentaren einzusteigen.

Eine zweite interessante Vision von Nick Denton ist fractional commenting, dass die Kommentierung an spezielle Segmente des Blogeintrages koppelt – so wie bei Soundcloud auch bestimmte Passagen eines Musikstückes kommentiert werden können.

Nick Denton gehört zum Typus Arschloch, dem ich gerne zuhöre. “The Failure of Commenting”, SWSX 2012.

Die Gebäude sind dabei recht generisch umgesetzt, aber schick halbtransparent. Nettes Detail in Sachen Perfektion: die Schattenwürfe entsprechen dem Sonnenstand zur jeweiligen Tageszeit (auch der Jahreszeit?).

An der Menge der in Hamburg umgesetzten 3D-Gebäude hat sich nicht viel getan. In Hamburg beschränkt man sich grosso modo auf den Bereich innerhalb des Wallrings und selbst die HafenCity ist genauso lückenhaft, wie das Fotomaterial in der Satellitenansicht veraltet ist.

Ungewollter Nebeneffekt dieser gut gemeinten Maßnahme: das Generieren von neuen Passwörtern in so kurzen Abständen überfordert viele Mitarbeiter, die nun daher die Passwörter irgendwo aufschreiben, per Post-It-Zettel am Bildschirm oder auf einem Aufkleber am Laptop-Boden notieren…

Mit Firefox 10 hat man sich einen weiteren Schritt gen Firebug-Substitut hin bewegt: nun ist auch ein HTML-/CSS-Inspektor inkludiert.

Mit der Tastenkombination Apfel + Alt + i (Windows-/Linux-User schauen bitte selber nach) kann man auf der Seite ein beliebiges Element auswählen. Es klappt dann zuerst eine Leiste mit der DOM-Verschachtelung aus und per “HTML”- oder “Style”-Button auch ein Panel mit dem HTML-Code und den für das Element relevanten Selektoren.

Der “Properties”-Button schaltet das CSS-Panel zu einer Ansicht um, wie man sie von dem IE Web Developer Tools, aber noch nicht von Firebug kennt: einer Auflistung aller CSS-Attribute und von welchen Definitionen sie … ähm … definiert werden. Wenn man weiß, dass die Schriftgröße der Headline falsch ist, muss man sich nicht mehr durch diverse Selektoren kämpfen, die auf das A-, H1-, .entry-, H1.entry- oder sonstige Elemente wirken können, sondern kann sich gezielt das Attribut font-size stürzen und bekommt eine Liste der Selektoren die dieses Attribut ansprechen.

Ich weiß noch nicht, was ich von dem Ausbau der Web Developer Tools durch Firefox halten soll. “Konkurrenz belebt das Geschäft” für Firebug oder das Verschwenden von Energie die man woanders besser einsetzen könnte, als sich zu bemühen Firebug hinterherzuhecheln?

In den Menüs hat das Werkzeug schon für Chaos gesorgt, denn der Name “Web Developer” ist identisch mit der sehr populären Erweiterung “Web Developer” von Chris Pederick und so besitzt das Tools-Menü nun zwei gleichnamige Einträge.

Pedericks “Web Developer” lässt sich weiterhin ebenso problemlos nutzen wie sich auch Firebug mit Firefox “Web Developer Tools” co-existiert – auch wenn das Aufklappen von Firebug zusätzlich zu den Firefox-Tools nicht ästhetischen Höchstansprüchen genügen mag…

Firebug bleibt unverzichtbar. Die Firefox-Tools decken noch nicht alle Bereich in der entsprechenden Tiefe ab – und solange Farbwerte nur im RGB()-Format statt im Format wie sie Stylesheet angegeben wurden (i.d.R. Hex) sind die Tools nahezu unbrauchbar. Die Konsole kommt nicht an das “Net”-Tab von Firebug heran und im Javascript-Bereich ist anscheinend der alte, klobige DOM-Inspector inzwischen rausgeflogen und noch nicht ersetzt worden.

Ich bin auf die zukünftige Entwicklung von Firebug gespannt. Opera hat mit Opera Dragonfly ein ästhetisch sehr ansprechendes Konkurrenzprodukt herausgebracht und neue Webkit-Nightlies (genauso wie Preview-Versionen von Opera) bauen CSS-Style-Profiler ein: wie lange braucht es also um bestimmte CSS-Styles zu rendern.

Es macht deutlich dass im Web Design-Bereich auch die nächsten Jahre in nicht minder hohen Tempo fortschreiten werden, wie die letzten 2-3 Jahre.

Nach einer sehr positiven Rezension in Felix Salmons Reuters-Blog, habe ich mit “The Fear Index” von Robert Harris gekauft. Robert Harris of “Fatherland”-Fame. Damit mein zweiter Versuch im Krimi-Genre. Ich hatte durch die Rezension hohe Erwartungen an die Schilderungen aus dem Börsenbusiness.

Doch ich wurde enttäuscht. Ein banaler Krimi. Vier oder Fünf auf einer Skala von Eins bis Zehn.

Dr. Alexander Hoffman ist ein US-Wissenschaftler, der mit einem Kompagnon in Genf einen Hedge Fund führt. Der Hedge Fund setzt dabei einen von Hoffman entwickelten, auf Künstliche Intelligenz basierenden Algorithmus ein, der sich permanent selber weiterentwickelt.

Eines Tages bekommt Hoffman anonym eine wertvolle alte Ausgabe von Charles Darwins “The Expression of the Emotions in Man and Animals“ zugeschickt. Einige Tage später wird in Hoffmans Villa eingebrochen. Hoffman wird durch die Geräusche wach, stellt den Täter, bekommt aber mit einem Feuerlöscher einen über den Schädel gezogen und ist knapp eine Viertelstunde bewusstlos.

Der Einbruch stellt die Polizei vor einem Rätsel: die Villa ist derart perfekt gegen Einbrecher gesichert, dass es nicht möglich ist, ohne den Code der Alarmanlage einzubrechen. Es muss also ein “Insider-Job” gewesen sein.

Hoffman stellt zudem am nächsten Tag fest, dass das Darwin-Buch per eMail in Amsterdam bestellt wurde. Von seinem eigenen eMail-Account und von einem geheimen Bankkonto von ihm bezahlt.

Sehr viel mehr kann man ohne Spoiler nicht erzählen. Das Buch geht aber straight zu einem Ende hin, von dem sich die meisten Eckpunkte vorher leicht erraten lassen.

Der Krimi ist sehr kühl herunter geschrieben und liest sich teilweise so, als hätte Harris vorher fünf Gegenstände ausgelost und versucht sie nun in einen Krimi unterzubringen. Die englische Kritik lobt am Buch zahlreiche Anspielungen, aber diese Charade gibt dem Krimi selber keinerlei zusätzliche Dimension.

Von Schilderungen des Börsenbusiness’ ist leider nicht viel zu merken, abseits einer Erklärung der Tätigkeiten eines Hedge Funds und der Anknüpfung der Ereignisse an den reelen “Flash Crash” von 2010.

Die Charaktere bleiben platt. Es bleibt vom Buch – anders als bei “The Girl with the Dragon Tattoo” – nichts hängen. Jeder Economist liest sich spannender.

Das erste Buch in diesem Reigen ist das frisch erschienene Buch von Khoi Vinh (subtraction.com) “Ordering Disorder” über Grid Layouts im Webdesign.

Khoi Vinh ist Designer. Bis 2006 war er vier Jahre lang bei Behavior, einem der bekannteren Design-Studios, und danach, bis zu diesem Sommer, Design Director bei nytimes.com. In dieser Zeit ist er einer der am meisten beachteten Bloger zum Thema (Web) Design geworden. Seine Königsdisziplin sind seit einigen Jahren “Grid Layouts” – ein Thema dass er bei Web Designern popularisiert hat (Grid Computing… and Design, Dezember 2004; Oh Yeeaahh!, März 2007; Grids are good, PDF 8MB März 2007; Really Basic Maths, November 2009 )

Grid Layouts sind kein neues Designthema – im Laufe der letzten Jahrzehnte haben ausgehend von Bauhaus und der sog. “Schweizer Typografie” immer mehr Disziplinen die Prinzipien einer strengen geometrischen Gestaltung übernommen. Zum Beispiel Zeitungen, deren Layouts entlang von Gittern und Raster aufgebaut sind.

Dass das Webdesign sich erst seit 3-4 Jahren dieses Themas annimmt, lag an den stumpfen Waffen. Die Gestaltungsmöglichkeiten des Webdesigns, unter Berücksichtigung auch älterer Browser, gab nicht viel her. Erst durch den Wegfall von Altlasten wie IE5, IE5.5 und IE6, lassen sich die Basics von Layoutraster ohne größere Klimmzüge berücksichtigen. Und damit wuchs auch das Interesse an dem Thema.

Die logische Konsequenz ist nun die Veröffentlichung eines Buches zum Thema. “Ordering Disorder” (siehe auch grids.subtraction.com)

Das Buch hinterlässt bei mir gemischte Gefühle. Zuerst das Positive. Mit dem Buch hat Khoi Vinh seine diversen Blogeinträge und Vorträge in konzentrierter Form zu Papier gebracht und damit einen Pflock in den Boden gesetzt – jetzt ham wa erst mal ein Standardwerk zum Thema und nun können andere kommen und versuchen über die Latte zu springen.

Khoi Vinh schreibt sich konzentriert am Thema ab und ich habe mich 180 Seiten lang, respektive ca. 8 Stunden, mit diesem Thema auseinandergesetzt. Eine derart intensive Beschäftigung mit einem Thema ist wohltuend und es gab auch immer wieder kleinere “Aha”-Momente.

Trotzdem bleibt am Ende ein unbefriedigendes Gefühl, das eine Amazon-Kundenrezension am besten auf den Punkt gebracht hat, als er/sie schrieb, das das Buch sich wie ein überlanger Blogeintrag liest. In der Tat hatte ich das Gefühl, dass da jemand mächtig sein bereits vorhandenes Material gemolken hat und dem nichts essentiell Neues hinzuzufügen hatte – was knapp drei Jahre nach dem er seine offensichtliche Vorlage “Grids are good” veröffentlicht hat, dünn ist.

Das erste Drittel des großzügig (vulgo: “luftig”) gestalteten Buches macht die generische Einführung in das Thema aus. Das zweite Drittel beschäftigt sich mit der konkreten Anwendung der Prinzipien des Grid Layouts anhand eines imaginären Design-Portals.

Dieses zweite Drittel blieb zwar für mich nicht ohne Erkenntnisgewinn, aber gleichzeitig kam immer wieder Ärger hoch, dass Khoi nicht von seinem konkreten Beispiel abwich, um andere Problemstellungen und Lösungen aufzuzeigen. Das Thema “Liquid Layouts” und “Responsive Web Design” auf nur vier Seiten abzuhandeln, grenzt an Unverschämtheit.

Ein anderes Beispiel. Seine Überlegungen zum konkreten Aussehen des Layoutrasters gehen von zwei Punkten aus: eine Art kleinster gemeinsamer Nenner bei der Browser-Breite (Layoutbreite) und der Umstand das ein Werbebanner einer bestimmten Größe zu integrieren ist. Alle Überlegungen zur Bemaßung des Layouts sowie der Anordnung der Layoutmodule gehen von dem Werbebanner als zentralen Punkt aus.

Bei zirka neunzig Prozent meiner Webdesign-Jobs spielen dummerweise Werbebanner überhaupt keine Rolle. Vinh diskutiert aber keine weiteren Faktoren die als “Anker” für ein Layoutraster dienen können.

Vinh geht auch nicht auf die Alternativen zu seiner Ableitung bzgl. der Layoutbreite im Browser ein – es würde zum Beispiel interessieren, ob und welche gründe es gäbe, von seinem Vorschlag von 960 Pixel abzuweichen. Seit Veröffentlichung von “Grids are good” 2007 ist die Diskussion um pro oder contra 1024er-Breite als “kleinster gemeinsamer Nenner” längst eingesetzt und auch da spielen Überlegungen hinsichtlich “Responsive Web Designs” eine Rolle. Doch ein Diskurs findet im Buch nicht statt. Vinh bleibt eng an seiner 2007er-Vorlage.

Mein Grummeln über das Buch ist also nicht zu überlesen. Er arbeitet zu linear sein Tutorial ab und vergisst dabei alles, was sich links und rechts vom sehr schmalen Pfad befindet. Das macht das Buch thematisch sehr viel kleiner als es der Materie gut tut.

Knapp 20 US$ sind deswegen ein recht happiger Preis. Wenn man aber im Hirn den Schalter umlegt, und den Preis als Entlohnung für die gesamten Arbeiten von Vinh in Blogs u.ä. ansieht, dann passt es schon.

Urteil: wer einen Startpunkt oder eine Zusammenfassung zum Thema Grid Layouts sucht und 20 US$ verschmerzen kann, darf zugreifen. Wer beim Lesen darauf wartet, das Vinh irgendwann noch die zweite Stufe zündet, wird enttäuscht.

Zusammenfassung: das Buch ist eine Zusammenfassung und ein Startpunkt zum Thema Grid Layouts. Wer aber auf darauf wartet dass die zweite Stufe zündet, wird vom Buch enttäuscht.