In der frühen Phase eines Projekts werden diese Geschichten von Interaction-Designern als Kontext-Szenarios bezeichnet. Diese Szenarios sind optimistische Erzählungen, welche das Verhalten unserer Benutzer und unserer Lösung beschreiben und uns etwas über die Motivationen und Ziele dieser Menschen verraten. Kontext-Szenarios sind für Designer dasselbe, wie Drehbücher für Filmemacher.

Beim Schreiben der Kontext-Szenarios beginnen wir uns vorzustellen, wie unser Produkt oder Service aussehen kann. Die Geschichtenform beflügelt dabei nicht nur unsere Fantasie, sondern ist eine ideale Gesprächsgrundlage, um die Qualität und den Umfang unserer Lösung im Team und mit unseren Auftraggebern zu besprechen.

Für ein sinnvolles Kontext-Szenario führen wir 30- bis 60-minütige Interviews mit unseren zukünftigen Benutzern und entwickeln evtl. Peronas, um die Menschen, für die wir designen, während des gesamten Prozesses im Kopf zu behalten. Im folgenden Beispiel haben wir ein Termin-Tool für ein Radgeschäft entwickelt. Das vorgestellte Szenario ist (stark) gekürzt und dient lediglich dazu, zu zeigen, wie Szenarios dabei helfen können, eine nützliche Lösung zu entwickeln.

Auszug Kontext-Szenario: Mechaniker

Für Flo beginnt der Arbeitstag kurz vor 10:00 Uhr. Er kommt in die Werkstatt und macht sich zuerst ein Bild davon, welche Räder heute repariert werden müssen. Er wirft einen Blick auf den Bildschirm, und sieht, dass von fünf Rädern, die heute für einen Service-Termin eingetragen sind, drei Mountainbikes und zwei Rennräder sind.

Er sieht auf seinem Bildschirm, dass das Fahrrad die Nummer 23 hat, und findet es dank der Nummer, ohne lange in der Werkstatt danach suchen zu müssen. Nachdem Flo mit der Reparatur des Rads fertig ist, bestätigt er das im System, und widmet sich dem nächsten Service.

So funktioniert’s

In diesem Auszug steht bechrieben, wie Flo mit unserer Software arbeitet, welche Entscheidungen er trifft und wie der Arbeitsablauf aussieht. Die Geschichte selbst basiert auf unseren Beobachtungen und Gesprächen mit den Mitarbeitern und ist unsere Traumvorstellung davon, wie ein Mechaniker mit Hilfe unserer Software seine Ziele erreichen kann.

Um von der Geschichte zu ersten Scribbles zu gelangen, schauen wir uns einfach jeden einzelnen Satz an und überlegen, welche Anforderungen wir für das Interface ableiten können. Zwei Beispiele sollen zeigen, wie das in der Praxis gemacht werden kann:

Beispiel 1

Er wirft einen Blick auf den Bildschirm, und sieht, dass von fünf Rädern, die heute für einen Service-Termin eingetragen sind, drei Mountainbikes und zwei Rennräder sind.

Anforderungen:

• Möglichkeit alle Räder zu sehen, die heute repariert werden müssen
• Möglichkeit den Typ eines Fahrrads zu erkennen (Mountainbike oder Rennrad)

Beispiel 2

Er sieht, dass eines der beiden Rennräder noch nicht vom Kunden gebracht wurde.

Anforderungen:

• Möglichkeit zu sehen, ob ein Fahrrad bereits in der Werkstatt ist

Und darauf kommt es an

Wie ihr vielleicht bemerkt habt, spielt der richtige Detailgrad eine entscheidende Rolle. Wir schreiben in den Szenarios z.B. dass Flo sieht, dass von fünf Rädern, drei Montainbikes und zwei Rennräder sind. Diese Beschreibung ist offen genug, um beim Scribblen verschiedene Darstellungen ausprobieren zu können und das Design iterativ zu verbessern.

Schlecht wäre hingegen, bereits im Szenario eine fixe Form der Darstellung zu beschreiben. Zum Beispiel: Flo sieht eine Liste von Rädern und sieht, dass drei dieser Räder ein Icon für Montainbikes haben und zwei ein Icon für Rennräder. Bei dieser detaillierten Beschreibung stellt sich eigentlich nur noch die Frage, wie die Icons aussehen. In Wahrheit sollen die Szenarios aber den Flow oder den Ablauf der einzelnen Aktionen zeigen, nicht jedoch das Interface selbst beschreiben.

Genauso unbrauchbar wie eine zu genaue, wäre eine zu oberflächliche Beschreibung. Wenn wir z.B. nur schreiben würden, Flo sieht die Räder, die heute repariert werden müssen, dann erhalten wir aus diesem Statement keinen Hinweis auf das Interface. Die Kunst liegt darin, den perfekten Mittelweg zwischen oberflächlich und detailliert zu finden.

Zum Schluss

Der größte Vorteil von Kontext-Szenarios ist meiner Meinung nach, dass sie Geschichten sind, die jeder versteht und unter denen sich jeder etwas vorstellen kann – egal ob Designer, Programmierer oder Auftraggeber. Sie sind eine nützliche Grundlage, um zu entscheiden, was das fertige Produkt wirklich können soll.

Das beste daran ist, dass wir keine Liste von Wunsch-Features erstellen und über verschiedenen Meinungen und Geschmäcker streiten müssen, sondern basierend auf echten Gesprächen mit echten Menschen, eine Lösung entwicklen, die unseren Benutzern dabei hilft, ihre Ziele auf einfache und angenehme Weise zu erreichen.

Miteinander reden von Friedemann Schulz von Thun

Das Standardwerk zum Thema Kommunikationspsychologie. Manche haben davon bereits während ihrer Schulzeit gehört und können sich an die 4 Ebenen einer Nachricht genauso erinnern, wie an die unterschiedlichen Persönlichkeits- bzw. Kommunikationsstile und das innere Team. Der deutsche Kommunikationspsychologe Friedemann Schulz von Thun zeigt in seinem dreibändigen Werk, was Psychologen über menschliche Kommunikation wissen und macht es sich zur Aufgabe, dieses Wissen einfach und anschaulich zu erklären.

Mir haben die Bücher sehr dabei geholfen, mich selbst besser zu verstehen. Vor allem Band 2, in dem die verschiedenen Persönlichkeitsstile vorgestellt werden, hat mich immer wieder zurück in meine Kindheit geführt und viele Dinge verständlich gemacht und mir gezeigt, wie sehr die eigene Wahrnehmung von der Kommunikation mit anderen Menschen abhängig ist und beeinflusst wird, dass ich mir gar nicht mehr vorstellen kann, ohne das Wissen aus Miteinander Reden durch das Leben zu gehen.

The Seven Habits of Highly Effective People von Stephen R. Covey

Seven Habits ist eines der meistverkauften Bücher aller Zeiten und gehört zu den wichtigsten Management- bzw. Business-Büchern überhaupt. Stephen Covey beschreibt darin ein Konzept, um Beruf- und Privatleben in Einklang miteinander zu bringen und die eigene Effektivität zu steigern und ein glückliches Leben zu führen. Zentraler Bestandteil des Buches ist der Vollzug eines Paradigmenwechsels, wie Covey es nennt, was so viel bedeutet, wie die Art und Weise zu ändern, wie wir die Welt sehen und interpretieren.

Für mich ist Seven Habits eine der größten Quellen der Inspiration und mit der Zeit so etwas wie ein Leitfaden für mein Leben geworden. Wenn mich jemand fragen würde, welches Buch ich empfehle, wenn man in seinem ganzen Leben nur ein einziges Buch lesen könnte, würde ich ohne lange nachzudenken Seven Habits von Stephen Covey nennen – viel mehr kann ich dazu gar nicht sagen, ohne dass es allzu sehr nach Werbung klingt.

Rework von Jason Fried und David Heinemeier Hansson

Jason und David sind die Geschäftsführer von 37signals, einem Softwareunternehmen aus Chicago. In ihrem zweiten Buch Rework beschreiben sie die Philosophie hinter ihrem Unternehmen und zeigen, dass weniger wirklich besser ist. Das Besondere an diesem Business-Buch ist die einfache und klare Sprache, welche komplett ohne Fachjargon auskommt und natürlich die, auf den ersten Blick völlig widersinnigen und unlogischen Empfehlungen um ein eigenes Unternehmen aufzubauen.

Bevor ich Rework gelesen habe, kannte ich bereits das erste Buch von Jason und David, Getting Real und hatte bereits eine zeitlang den Blog von 37signals verfolgt. Deshalb war der Inhalt des Buches nicht wirklich neu für mich – die Art und Weise, wie die beiden ihr Wissen zusammengefasst und in Buchform präsentiert haben, ist aber so kompakt und auf den Punkt, dass sich der Kauf auf jeden Fall gelohnt hat. Das Besondere an Rework ist, dass es einem den Mut gibt, selbst etwas zu machen und nicht ängstlich rumzusitzen und zu hoffen, dass alles gut wird.

Linchpin: Are you indispensable? von Seth Godin

Seth Godin beschreibt in Linchpin die Zukunft der Arbeit – und eigentlich der Welt, wie Tony Hsieh von Zappos dazu anmerkt. Die Prämisse des Buches lautet, dass es in unserer heutigen (Arbeits-)Welt nicht mehr genügt, nur noch auf Anweisungen zu warten und brav sein Arbeit zu erledigen. Um ein wirklich erfolgreiches und glückliches Leben führen zu können, muss man „unersetzlich“ werden und sein Leben selbst in die Hand nehmen.

Wer bereits einige Artikel unseres Blogs gelesen hat, wird feststellen, dass ich stark von den Ideen aus Linchpin inspiriert wurde und eine sehr ähnliche Meinung wie Seth vertrete. Ich habe das Buch gerade zum richtigen Zeitpunkt gelesen und es hat mir dabei geholfen, meinen inneren Widerstand zu besiegen und etwas zu tun. Für mich ist Linchpin eine perfekte Fortsetzung für Seven Habits und Rework. Ein Buch, das Mut macht, in einer Zeit, in der Nichts wichtiger sein könnte.

1. Das Wichtigste zuerst

Wie produktiv ein Tag ist, hängt davon ab, wie man ihn beginnt. Als erstes überlege ich mir deshalb, welche Arbeiten ich heute unbedingt erledigen will. Das können Arbeiten sein, die ich unbedingt erledigen muss oder auch Dinge, die ich einfach gerne ausprobieren würde. Man kann diese Aufgaben entweder auf einen Zettel notieren oder einfach im Kopf behalten – wichtig ist nur, dass man mit der Aufgabe beginnt, die heute am wichtigsten ist und so lange daran bleibt, bis diese Aufgabe entweder erledigt ist oder man für heute genug davon hat.

2. Keine E-Mails, keine Telefonate, kein Facebook …

Dieser Punkt ist eine Ergänzung zum ersten: Bevor man nicht mit der wichtigsten Aufgabe des Tages begonnen hat, gibt es keine E-Mails, keine Telefonate, kein Facebook. Kurz gesagt, es gibt keine Ablenkungen, bevor man nicht damit begonnen hat, was man heute machen will. Wenn ich heute z.B. unbedingt diesen Blog-Artikel schreiben will, lese ich keine E-Mails, bevor ich mit dem Schreiben beginne. Ich kommuniziere im Idealfall überhaupt nicht mit anderen, bis ich meine Aufgabe erledigt habe oder es für heute gut sein lasse.

3. … und vor allem keine Notifications!

Damit Punkt 1 und 2 überhaupt funktionieren können, müssen sämtliche Notifications deaktiviert sein. Notifications sind nichts anderes als Ablenkungen bzw. Unterbrechungen. Und wer produktiv arbeiten möchte, darf nicht abgelenkt bzw. unterbrochen werden. Ich bin in der glücklichen Lage, kein Smartphone zu besitzen, was mir eine Menge Ablenkungen erspart. Damit ich auch am Laptop nicht von eingehenden E-Mails unterbrochen werde, habe ich einfach das automatische Empfangen von Nachrichten deaktiviert. Das sollte meines Wissens in jedem Mail-Programm funktionieren und hilft dabei, den eigenen Tag selbst zu gestalten und nicht nur von externen Faktoren abhängig zu machen.

4. Fixe Zeiten für E-Mail & Co

Wer den Artikel bis jetzt gelesen hat, könnte meinen, dass Kommunikation mit Anderen eine böse Sache wäre – das stimmt natürlich nicht. Es geht nur darum, selbst zu bestimmen, wann diese Kommunikation stattfindet und kein Sklave der Wünsche und Pläne von anderen Menschen zu werden. Am besten funktioniert das, wenn man fixe Zeiten festlegt, in denen man seine E-Mails liest, Antwort-Mails schreibt, Telefonate führt (eventuell zurückruft), Facebook und Twitter durchschaut und andere „soziale Aktivitäten“ durchführt. Im Moment versuche ich gerade meine E-Mails einmal nach dem Essen und einmal am späten Nachmittag zu checken. Wann und wie oft man „sozial“ wird, hängt dabei natürlich von jedem selbst ab. Man sollte aber versuchen, nicht die ganze Zeit „verbunden“ zu sein.

5. Weniger arbeiten

Bis jetzt ging es nur darum, sich nicht ablenken zu lassen bzw. sich nicht selbst abzulenken. Das ist wichtig für die eigene Produktivität, um aber wirklich effektiv sein zu können, muss man fokussiert arbeiten. Eine sichere Methode um jeglichen Fokus zu verlieren, ist jeden Tag für 8 bis 12 Stunden oder noch länger zu arbeiten. Besser man arbeitet täglich 4 Stunden (oder weniger) und nutzt diese kurze Zeit so gut wie möglich, in dem man sich nicht ablenken lässt und seine Arbeit konzentriert erledigt. Das hört sich im ersten Moment kontraproduktiv an, weil weniger Arbeit auch weniger Leistung bedeutet, sobald man aber bemerkt, dass man den halben Tag im Büro nur mit Kollegen spricht, E-Mails checkt, Facebook-Nachrichten schickt und andere Ablenkungen sucht, wird man den Unterschied zwischen Anwesenheit und Produktivität schnell erkennen.

6. Nicht ständig über die Arbeit nachdenken

Ständig über die Arbeit nachzudenken, dürfte vor allem ein Problem von Menschein sein, die ihr Hobby zum Beruf gemacht haben. Ich bin z.B. manchmal so eingenommen von meiner eigenen Arbeit, dass ich nur noch darüber nachdenke. Ich denke nach, was ich schon gemacht habe und was ich noch machen werde. Ich schmiede Pläne und überlege, was als Nächstes kommt – manchmal so sehr, dass mein restliches Leben nur so an mir vorbei zu ziehen scheint. Dieses Gefühl, dass das Leben an einem vorbei zieht, ist ein sicheres Zeichen dafür, dass man 1.) zu viel arbeitet und 2.) die eigenen Gedanken zu selten zur Ruhe kommen. Wenn ich abends auf der Couch sitze und merke, dass ich schon wieder über die Arbeit nachdenke, dann schreibe ich entweder meine Gedanken auf, um morgen weiter darüber nachzudenken oder mache mir selbst klar, dass diese Gedanken nur eine Fantasie sind, die mich davon abhalten, das Leben im Hier und Jetzt zu genießen.

Bevor man beginnen kann, schlechte Gewohnheiten loszuwerden, muss man diese erkennen. Das hört sich banal an, ist aber der schwierigste und langwierigste Schritt im gesamten Prozess. Ich habe z.B. fast 13 Jahre gebraucht, um mir einzugestehen, dass es ein Problem ist, wenn ich täglich eine Schachtel Zigaretten rauche. Als ich dann aber soweit war, ging der Rest fast von alleine.

Der Grund dafür ist, dass wir uns ständig selbst belügen, um unser Bild von uns selbst wahren zu können. Stellt euch vor, wie schwierig es für mich war, mir einzugestehen, dass ich mein halbes Leben lang im Selbstzerstörungsmodus unterwegs war. Sich bewusst zu machen, dass man ein Problem hat, ist nur schwer möglich, weil man sich damit gleichzeitig eingestehen muss, dass man nicht immer richtig liegt. Das ist für die meisten Menschen schwierig, weil sie glauben, dass ihre Sicht der Dinge die richtige ist.

Deswegen tun wir uns auch leicht dabei, anderen Menschen gute Ratschläge zu geben, haben aber Probleme damit, selbst Ratschläge von anderen anzunehmen. Wir kennen uns selbst so gut, dass wir gewissermaßen vorbelastet sind, wenn es darum geht, unser eigenes Verhalten objektiv zu beurteilen.

“We tend to judge ourselves by our intent, but judge others by their behavior.” Stephen M. R. Covey in The Speed of Trust

Um eine schlechte Angewohnheit loswerden zu können, müssen wir uns ehrlich eingestehen, dass wir ein Problem haben. Nachdem ich z.B. erkannt hatte, dass ich ein Problem habe, wenn ich täglich eine Schachtel Zigaretten rauche, habe ich angefangen, mir selbst klar zu machen, dass ich unbedingt mit dem Rauchen aufhören will. Ich spreche nicht von einem halbernstgemeinten Neujahrsvorsatz, der bereits Mitte Jänner vergessen ist, sondern von dem Willen, etwas unbedingt ändern zu wollen.

Im zweiten Schritt ist es wichtig, dass man sich immer wieder klar macht, dass man etwas unter allen Umständen ändern möchte. Auf dem Weg, eine schlechte Gewohnheit loszuwerden, kann es zu vielen Rückschlägen kommen und wir wollen sicherstellen, dass wir nicht beim kleinsten Hindernis aufgeben müssen. Das wäre furchtbar für unser Selbstvertrauen. Denkt nur an Menschen, die bereits unzählige Diäten versucht haben und immer wieder gescheitert sind – das Selbstvertrauen dieser Menschen sinkt mit jedem weiteren Fehlschlag und ein Erfolg wird von Mal zu Mal unwahrscheinlicher.

Es ist deshalb wichtig, dass wir eine schlechte Angewohnheit unbedingt loswerden wollen. Nachdem ich angefangen habe, meinen Zigarettenkonsum zu senken, hat mir eine einfache Methode dabei geholfen: Immer wenn ich eine Zigarette rauchen wollte, habe ich darüber nachgedacht, was ich mir davon erwarte und wie ich mich danach fühlen werde. Wenn ich also Lust auf eine Zigarette hatte, habe ich darüber nachgedacht, wie ich mich danach fühlen werde und festgestellt, dass ich mich über mich selbst ärgern werde, weil ich ja unbedingt aufhören möchte.

Diese Methode hat mir dabei geholen, jedes aufkommende Lustgefühl mit einem Lächeln im Gesicht zur Kenntnis zu nehmen und mich gut dabei zu fühlen, erst einmal keine Zigarette rauchen zu gehen. Über die Konsequenzen nachzudenken und zu erkennen, dass ich mich ärgern würde, wenn ich eine Zigarette rauchen gehe, wurde sozusagen zu meiner Ersatzhandlung. Und an diesem Punkt passierte etwas Interessantes: Jedes Mal wenn ich Lust auf eine Zigarette hatte und dann doch keine geraucht habe, wurde mein Selbstbewusstsein ein Stück weit gestärkt. Es wurde von Mal zu Mal einfacher, meinem Verlangen zu widerstehen und meine Motivation daraus zu beziehen, jetzt erst recht keine Zigarette rauchen zu gehen.

Und damit kommen wir zum dritten und letzten Schritt. Nachdem wir 1.) unser Problem erkannt haben und 2.) eine Ersatzhandlung dafür gefunden haben, können wir 3.) unsere Wahrnehmung von uns selbst ändern. Da ich seit ich 14 war geraucht habe, war ich immer schon ein Raucher. Wenn ich über mich selbst nachgedacht habe, habe ich mich als Raucher gesehen – wie alle anderen auch. In dem Moment, in dem ich meinen Verstand unter Kontrolle bekommen habe und dadurch mein eigenes Verhalten beeinflussen konnte, habe ich auch die Möglichkeit bekommen, mein Selbstbild neu zu zeichnen.

Und hier kommt das beste an meiner Methode: Am Ende muss ich mich nicht dafür entscheiden, entweder ein Raucher oder ein Nichtraucher zu sein. Ich bin einfach ich und wenn ich heute eine Zigarette angeboten bekomme, kann ich das Angebot gerne annehmen, weil ich nicht befürchten muss, rückfällig zu werden. Da ich von Anfang an selbst die Verantwortung für mein Verhalten übernommen habe, mein Problem selbst erkannt habe und mein Verhalten selbst verändert habe, bin ich von nichts anderem abhängig, als von mir selbst.

Dasselbe habe ich übrigens auch mit meinem übermässigen Kaffeekonsum gemacht. Ich habe erkannt, dass es ein Problem ist, täglich 3 bis 5 Tassen Kaffee zu trinken und trinke stattdessen einfach Tee. Die Ersatzhandlung ist eine andere als beim Rauchen, das Prinzip bleibt aber dasselbe.

Wenn man das Aussehen von Google Chrome ändern will, kann man zwischen „Designs“ von Google und von Künstlern wählen. Das ist aus zwei Gründen interessant:

1. Der Menüpunkt heißt „Design“, weil die meisten Leute glauben, Design wäre dasselbe wie Aussehen und deshalb nach dem Wort „Design“ suchen werden, wenn sie das Aussehen ihres Browsers ändern möchten.
2. Die zweite Auswahl heißt „Von Künstlern“, weil die Designer bei Google wissen, dass das anmalen eines User Interfaces nichts mit Design zu tun hat und eher als Kunst bezeichnet werden sollte.

Das erinnert mich an diese Taschentuchboxen:

Viele Leute glauben, dass die Blümchen auf dieser Box etwas mit Design zu tun hätten. Manche würden die Arbeit des Designers sogar darauf reduzieren, diese Blümchen zu zeichnen. Schade, vor allem wenn man bedenkt, dass das eigentliche Design die Box selbst ist und die Blümchen nur aufgedruckt werden, damit wir im Geschäft ein paar Cent mehr dafür bezahlen.

Schön zu sehen, dass Google Wert auf die Details legt und einen Unterschied zwischen Designer und Künstler macht. Vielleicht wird dieser Unterschied irgendwann auch der breiten Öffentlichkeit klar und die Leute hören auf zu glauben, dass Designer nichts anderes tun, als Dinge schöner zu machen.

Wozu eigentlich ein Grundlinienraster?

Space in typography is like time in music. The Elements of Typographic Style

Robert Bringthurst schreibt in The Elements of Typographic Style, dass sich der horizontale Raum in der Typografie unbewusst ergibt. Man wählt eine Schrift und bestimmt die Breite einer Spalte. Wenn man eine Schrift setzt, füllt sich die Spalte und die abwechselnden Buchstabenformen ergeben von ganz alleine einen Rhythmus, der wie Musik für unsere Augen ist.

Der vertikale Raum einer Seite ergibt sich nicht ganz so einfach. Hierfür müssen wir selbst einen Grundrhythmus festlegen. Dieser Grundrhythmus ist der Abstand zwischen einer Grundlinie und der nächsten. Um diesen Rhythmus für Text im Web anzupassen, verwenden wir die CSS-Eigenschaft line-height.

Wie komme ich zu meinem Grundrhythmus?

Am Anfang wählt ihr eine Schrift und eine Schriftgröße. Für dieses Beispiel gehen wir einfach von der Standardgröße von 16px aus. Bei einer Schriftgröße von 16px bietet sich eine Zeilenhöhe von 24px an. Um diesen Grundrhythmus von 24px auf eure Seite anzuwenden, schreibt ihr einfach diesen Wert als line-height in euren body:

body {
    font-size: 100%;
    line-height: 24px;
    }

Hierbei ist anzumerken, dass die pixelgenaue Angabe zu Problemen führt, wenn einer eurer Besucher die Schriftgröße in seinem Browser ändert. Dann würde sich nämlich die Zeilenhöhe nicht mitvergrößern oder -verkleinern und somit würden eure vertikalen Abstände nicht mehr stimmen. Um das zu vermeiden, könnt ihr euch das Verhältnis zwischen Zeilenhöhe und Schriftgröße berrechnen …

24 ÷ 16 = 1.5

… und diesen Wert an Stelle der Pixelangabe einsetzen:

body {
    font-size: 100%;
    line-height: 1.5;
    }

Auf diese Weise bleiben eure vertikalen Abstände immer richtig. Wenn ein Besucher die Schriftgröße von 16 auf 18px vergrößert, ändert sich die Zeilenhöhe automatisch von 24 auf 27px (= 18px × 1,5).

Was mache ich mit kleineren und größeren Textelementen?

Den Grundrhythmus für euren Haupttext festzulegen war einfach. Die eigentliche Herausforderung liegt darin, Texte mit kleinerer und größerer Schriftgröße im selben vertikalen Rhythmus zu setzen. Und wie am Beginn des Artikel erwähnt, gibt es hierfür 2 Methoden:

1. Klassische Methode

Ich nenne diese Methode klassisch, weil sie vor allem Buchtypografen verwenden, damit ihre Texte Register halten. Dadurch vermeiden sie das optische Durchschlagen der Schriftzeilen der Rück- bzw. Vorderseite im nichtbedruckten Durchschuss.

Ein Beispiel aus Detailtypografie von Forssman und de Jong. Man erkennt deutlich die durchscheinenden Zeilen der Rückseite. Mit einem Grundlinienraster wäre das nicht passiert, weil die Zeilen auf beiden Seiten deckungsgleich wären.

Die Idee dieser Methode lautet, die Zeilenhöhe jedes Textelements entweder gleich der Zeilenhöhe des Standardtexts zu machen oder ein vielfaches dessen zu verwenden. Wenn wir also eine Überschrift mit einer Schriftgröße von 18px haben, wäre die Zeilenhöhe genauso 24px, wie beim Standardtext mit 16px Schriftgröße. Würde die Schriftgröße der Überschrift 28px betragen, müssten wir die Zeilenhöhe dementsprechend auf 48px, also 24px × 2, erhöhen.

Die CSS-Datei würde dafür so aussehen:

body {
    font-size: 100%;
    line-height: 1.5;
    }
h1 {
    font-size: 28px;
    line-height: 1.71428571 /* 48px ÷ 28px = 1.71… */
    }
h2 {
    font-size: 18px;
    line-height: 1.33333333 /* 24px ÷ 18px = 1.33… */
    }

Ein Screenshot soll zeigen, dass der Haupttext immer genau auf der Grundlinie landet, selbst wenn sich darüber ein Textelement mit anderer Schriftgröße befindet. Die Überschriften selbst landen nicht auf den Zeilen, weil CSS die Zeilenhöhe eines Elements so darstellt, dass diese über und unter den Buchstaben gleichmässig aufgeteilt wird.

Egal ob Haupttext oder Überschrift – jedes Textelement hat eine Zeilenhöhe von 24, 48 oder 72px. Auf diese Weise landet der Haupttext immer wieder auf der Grundlinie

Auf den ersten Blick bietet die klassische Methode einen einfachen und praktischen Weg, um die vertikalen Abstände einzustellen. Bevor ich auf den großen Nachteil der klassischen Methode eingehe, erst ein Blick auf die web-spezifische Vorgehensweise.

2. Web-spezifische Methode

Wie bei der klassischen Methode, müssen wir auch hier darauf achten, dass die Zeilenhöhe jedes Textelements 24px oder ein vielfaches dieses Wertes beträgt. Im Unterschied zur ersten Vorgehensweise, passen wir hierzu nicht die line-height der einzelnen Elemente an, sondern belassen die relative Zeilenhöhe für die gesamte Seite beim selben Wert.

Das heißt auch Elemente mit einer Schriftgröße von 28px haben eine relative line-height von 1.5. Wenn wir jetzt 28 × 1,5 rechnen, kommen wir auf eine Zeilenhöhe von 42. Um trotz dieser zu kleinen Zeilenhöhe auf ein vielfaches von 24px zu kommen, berechen wir den Unterschied zwischen 42 und 48 und kompensieren die fehlenden 6 Pixel Höhe mit der CSS-Eigenschaft padding:

body {
    font-size: 100%;
    line-height: 1.5;
    }
h1 {
    font-size: 28px;
    line-height: 1.5; /* 28 x 1.5 = 42 */
    padding: 3px 0; /* 3 x 2 + 42 = 48 */
    }
h2 {
    font-size: 18px;
    line-height: 1.5; /* 18 x 1.5 = 27 */
    padding: 10.5px 0; /* 10.5 x 2 + 27 = 48 */
    }

Die Eigenschaft line-height kann man sich für h1 und h2 auch sparen, weil ein relativer Wert für die line-height von body automatisch auf jedes Textelement der Webseite angewandt wird. Ich habe die Angabe nur drinnen gelassen, um euch zeigen zu können, wie ich auf die Werte für padding komme.

Das Ergebnis der web-spezifischen Methode sieht auf den ersten Blick genauso aus, wie das Ergebnis der klassischen Methode:

Links: klassische Methode
Rechts: web-spezifische Methode

Was ist jetzt der Unterschied zwischen den beiden Methoden?

Bevor ich den Unterschied erkläre, zeige ich ihn:

Links: klassische Methode – der Standardtext trifft jede Zeile. Leider ist die Zeilenhöhe der Überschriften viel zu groß.
Rechts: web-spezifische Methode – sobald ein Textelement mit anderer Schriftgröße vorkommt, verlässt der Standardtext das Grundlinienraster. Dafür stimmt der Grauwert.

Um diesen Unterschied zu erklären, werfen wir einen Blick auf den Aufbau eines Textelements: Egal ob p, h1, h2 oder ul – jedes Textelement besteht aus einer Schriftgröße, einer Zeilenhöhe, evtl. einem Padding und einem Border. Alles zusammen ergibt die tatsächliche Höhe des Textelements:

Links: klassische Methode – eine Zeile ist 48px hoch, weil die Zeilenhöhe genau 48px beträgt
Rechts: eine Zeile ist 48px hoch, weil die fehlenden 6 Pixel bei einer Zeilenhöhe von 42px durch 3px padding oben und unten kompensiert wird.

Bleiben wir bei unserem Beispiel: In Methode 1 geben wir der h1 bei einer Schriftgröße von 28px eine Zeilenhöhe von 48px (= 28 × 1.71428571). In Methode 2 belassen wir die Zeilenhöhe bei 1,5, was uns eine Zeilenhöhe von 42 ergibt. Die fehlenden 6 Pixel kompensieren wir mit Hilfe von padding. Und das ist der springende Punkt: padding wird nicht für jede Zeile des Textelements verwendet, sondern kommt nur einmal außen herum. Das heißt, wenn eine h1 über 4 Zeilen läuft, ist sie mit Methode 1 genau 192px (= 48px × 4) hoch. In Methode 2 jedoch nur 174px (= 42px × 4 + 6px) hoch:

Links: klassische Methode – 4 Zeilen mit je 48px Höhe ergeben 192px.
Rechts: web-spezifische Methode – 4 Zeilen mit je 42px Höhe und einem Padding oben und unten von je 3 Pixel ergeben nur 174px.

Was ist besser an der web-spezifischen Lösung?

Abgesehen davon, dass man auf den ersten Blick sehen kann, dass die Zeilenhöhen der Überschriften bei der klassischen Methode zu groß sind? Zugegeben man könnte ein bisschen tricksen und den Grundlinienraster halbieren, dritteln oder sogar vierteln. Dann wäre es möglich die Zeilenhöhe von 48px (24px × 2) z.B. auf 36px (24px × 1,5) anzupassen. In der Buchtypografie wird auch genauso vorgegangen. Bei Webtypografie können wir aber auf die Komplexität eines unterteilten Grundlinienrasters verzichten. Warum? Weil am Bildschirm ohnehin kein Text von der Rückseite durchscheint und es keinen praktischen Nutzen hat, Register zu halten.

Alles was zählt ist der Grauwert unseres Textblocks. Und der ist bei der web-spezifischen Lösung ausgewogen und bei der klassischen nicht. Wenn Raum in der Typografie dasselbe ist, wie Zeit in der Musik, dann kommt es bei den vertikalen Abständen vor allem auf Timing an. Es spielt keine Rolle, dass das klassische Vorgehen theoretisch richtig ist, wenn die neue Methode praktisch besser aussieht. Den das war das Ziel der Übung: Text in unterschiedlichen Schriftgrößen so zu setzen, dass der vertikale Rhythmus, Musik für unsere Augen ist.

Und für jeden, der bis zum Schluss durchgehalten hat, hier noch 2 Links zu den HTML-Seiten, die ich im Artikel als Screenshots eingefügt habe:

• Klassische Methode
• Web-spezifische Methode

(Links waren bis 26.01.2011 vertauscht. Danke an Lukas für den Hinweis)

Wenn ihr den Unterschied selbst sehen wollt, verkleinert die Fensterbreite eures Browsers, bis die Überschriften mehrzeilig werden. Wer das Raster inkl. Grundlinienraster im Hintergrund einblenden möchte, kann es mit der Tastenkombination [Alt]+[Shift]+G aktivieren (funktioniert im Moment leider nur auf Mac-Rechnern). Und bitte nicht wundern, aber die Dateien sind work-in-progress und vor allem die LESS-Datei enthält unzählige Styles, die aus früheren Experimenten stammen und nichts mit diesem Beispiel zu tun haben.

Was ist das?

Wenn du das Rastersystem im Hintergrund einblenden möchtest, verwende einfach die Tastenkombination [Alt]+[Shift]+G.

Wir arbeiten seit einigen Wochen an einem flexiblen Rastersystem, mit dem man einfach Webseiten im Browser gestalten kann. Die Idee hinter diesem Rastersystem ist, dass man ohne viel Aufwand, Layouts in HTML und CSS entwickelt, um somit z.B. schnelle Prototypen für Usability-Tests anzufertigen.

Die aktuelle Demo-Version unseres Rastersystems zeigt eine Artikelansicht unseres Blogs, wie diese aussehen könnte. Wir haben mit LESS gearbeitet (Danke an Lukas) und in der Demo-Version nicht nur auf das Rastersystem geachtet, sondern besonderes Augenmerk auf den vertikalen Rhythmus der Seite gelegt. Wir haben also zusätzlich zu den Spalten auch ein Grundlinienraster verwendet, nur um zu demonstrieren, was sich mit Web-Typografie mittlerweile alles machen lässt.

Wie könnt ihr uns helfen?

Wir sind im Moment an einem Punkt angelangt, an dem wir unser Rastersystem ausgiebig testen möchten. Deshalb unsere Bitte an euch: Öffnet die Demo-Version, verwendet die Tastenkombination [Alt]+[Shift]+G und ändert die Fensterbreite eures Browsers und vergrößert bzw. verkleinert die Schriftgröße. Spielt so lange mit der Demo-Version herum, bis ihr das Gefühl habt, dass ihr alles Mögliche damit gemacht habt.

Wenn ihr fertig seid, schaut euch die Demo bitte auch auf euren Mobil-Telefonen, euren Kindles und euren Tablets an. Für diese Geräte gibt es zwar keinen Raster im Hintergrund – weil dieser nur für die Entwicklung gedacht ist – ihr könnt aber trotzdem überprüfen, ob das Layout auf eurem Gerät gut aussieht. Solltet ihr irgendein Gerät finden, auf dem die Demo-Version scheiße aussieht, dann schreibt uns bitte ein Kommentar und wir können uns ansehen, was wir falsch gemacht haben.

Was wir schon wissen

Wir verwenden für unser Rastersystem box-sizing, welches in IE 6 bis 8 nicht funktioniert. Für die alten Internet Explorer bieten wir deshalb keinen Raster im Hintergrund an. Ab Version 9 könnt ihr mit [Alt]+[Shift]+[G] wie gehabt das Raster einblenden.

Für die Spaltenbreite des Rasters verwenden wir Prozentangaben. Da Opera Prozente an der Kommazahl abschneidet und aus 8.33% einfach 8% macht, haben wir das Rastersystem auch für Opera ausgeschaltet. Also nicht wundern, wenn die Tastenkombination keine Wirkung zeigt.

Was kommt als Nächstes?

Wie gesagt, wir wollen ein Rastersystem entwickeln, mit dem jede und jeder einfache Layouts in HTML und CSS selbst bauen kann. Sobald wir/ihr unser Rastersystem getestet haben/habt, werden wir gemeinsam mit Lukas an einem Framework arbeiten, welches wir vermutlich auf GitHub veröffentlichen werden und für euch zum Download bereitstellen.

Bis dahin schon einmal Danke für’s fleißige Fenstergröße ändern und rein- und rauszoomen.

Wer einen Blick auf das Endergebnis dieses Artikels wirft, wird sehen, dass es nur um das grundlegende Layout des Blogs geht. Mit Dingen, wie Schrift, Schriftgrößen und vertikalen Abständen befassen wir uns im kommenden Artikel. Für diese Übung sieht unser gewünschtes Ergebnis ca. so aus:

Wir beginnen mit der einspaltigen Version unseres Blogs für mobile Geräte.

Ab einer Fensterbreite von 768px werden aus einer Spalte zwei.

Bei einer Breite von 1.024px erstrecket sich unser Blog schliesslich über drei Spalten.

Das Rastersystem im Hintergrund

Im Unterschied zum Raster des ersten Artikels, habe ich diesmal einige kleinere Änderungen vorgenommen. Die Anzahl der Spalten beträgt bei geringer Breite 4 und ändert sich aber einer Fensterbreite von 48em (768px bei einer Schriftgröße von 16px) auf 12 Spalten. Die Media-Querie dafür sieht wie folgt aus:

@media screen and (min-width:48em) {
        
    #grid .span {
        width:8.33%; /* 12 columns */
        }   
    .col-12 {
        display:block;
        }
    
    }

Um das Arbeiten mit dem Raster zu vereinfachen, binde ich zwei unterschiedliche Stylesheets ein. Eines enthält nur die Styles für das Rastersystem im Hintergrund, das andere ist für das Layout unseres Blogs verantwortlich:

<link rel="stylesheet" href="blog.css">
<link rel="stylesheet" href="grid.css">

Ein Wort zur Semantik

Lukas hat mich beim vorigen Artikel darauf hingewiesen, dass Klassen mit dem Namen .col-XY oder .grid eigentlich nichts im Markup zu suchen haben. Da ich ihm dabei vollkommen zustimme, habe ich eine korrekte Version unseres Blogs gemacht, die ganz ohne solche Klassen auskommt. Diese Version funktioniert genau gleich, außer dass sie kein sichtbares Raster im Hintergrund zeigt und somit nur die Styles aus blog.css benötigt.

Responsive Layouts beginnen bei der mobilen Variante

Beim Design einer Webseite mit der mobilen Variante zu beginnen hat einen großen Vorteil: Wir kümmern uns von Anfang an um die Struktur unseres HTML-Dokuments. Noch bevor wir Styles vergeben, müssen wir darauf achten, dass die Outline unseres Dokuments in Ordnung ist. Ein Trick, den ich von Andi gelernt habe, lautet, eine Webseite ohne aktivierte Stylesheets anzusehen:

Links: So sieht unser Blog aus, wenn sämtliche Styles deaktiviert sind.
Rechts: Der einzige Unterschied zu unserer mobilen Variante ist der fehlende Seitenrand.

Das Grundlayout unserer mobilen Version ergibt sich aus dem Markup unseres HTML-Dokuments. Die Reihenfolge der einzelnen Elemente im HTML-Code hängt also nicht davon ab, wo sie sich bei einer Auflösung von 1.024px befinden, sondern wie sie auf einem mobilen Gerät angezeigt werden. Das ist die Grundlage für die weiteren Layouts, die sich an die Breite des Fensters anpassen.

Im Markup gibt es keine Sidebars

Auf der Präsentationsebene teilt sich unser Blog-Layout in 2 Spalten, was aber nicht unbedingt etwas mit unserem Markup zu tun haben muss.

Wie schon gesagt, hängt der Aufbau unseres HTML-Dokuments von der Reihenfolge der einzelnen Elemente in der mobilen Version der Webseite ab. Um zu erklären, wie wir das Layout auf größere Bildschirmbreiten anpassen können, werfen wir kurz einen Blick auf die Outline unseres korrekten HTML-Dokuments:

<body>
    <h1></h1>
    <div id="main"></div>       
    <div id="aside"></div>
</body>

Und jetzt werfen wir einen kurzen Blick darauf, wo sich die einzelnen Elemente bei einer Fensterbreite von 48em befinden:

Am Bildschirm sieht es so aus, als würden h1 und #aside direkt nacheinander kommen. Im Markup sehen wir aber, dass #main zwischen den beiden liegt.

Da h1 und #aside im Markup nicht untereinander liegen, können wir sie natürlich auch nicht in einen gemeinsamen Container mit dem Namen #sidebar oder besser #additional-content geben. Um trotzdem zu unserem gewünschten Layout zu kommen, lassen wir #main nach links und h1 und #aside nach rechts floaten:

@media screen and (min-width:48em) {

    h1, #aside {
        float:right;
        width:25%;
        }
    #main {
        float:left;
        width:66.66%;
        }
            
    }

Wie machen wir komplexere Layouts?

Bis jetzt war alles recht einfach und zum Glück wird es nicht wirklich schwieriger, wenn wir komplexere Layouts entwickeln. Es gibt nur eine Sache, die wir verstehen müssen, bevor wir verschachtelte Container verwenden können: Horizontales padding bekommen immer die inneren Elemente:

Die inneren Elemente jedes Artikels erhalten seitliches padding. Den Hilfscontainern, die um sie herum liegen, dürfen wir natürlich kein zusätzliches padding geben.

Das Markup eines Artikels sieht so aus:

<div class="article">
    <div class="article-header"></div>
    <div class="meta"></div>
    <div class="article-content"></div>
</div>

Um unser Layout richtig hinzubekommen, müssen wir also .article-header, .meta und .article-content folgende Styles verpassen, die wir bereits aus dem vorigen Artikel kennen und die wir auch h1 und #aside gegeben haben:

.article-content, .article-header, .meta {
    box-sizing:border-box;
    padding:0 1em;
    }

Für die richtige Positionierung der einzelnen Elemente, passen wir die Breite von .article-content und .meta an und lassen beide nach links floaten.

@media screen and (min-width:64em) {

    .article-content {
        float:left;
        width:75%;
        }   
    .meta {
        float:left;
        width:25%;
        }

    }

Ein Hinweis zu den Prozentzahlen: Insgesamt hat ein .article 8 Spalten oder anders gesagt 75% der gesamten Breite. Um Elemente innerhalb von .article eine Breite zu geben, wird 8 zum Ausgangswert für unsere Rechnungen. Das heißt: 6 Spalten innerhalb von .article sind nicht 50% (50% von 8 Spalten = 4 Spalten) sondern 75% (75% von 8 Spalten = 6 Spalten).

Und was ist mit Internet Explorer 6 bis 8?

Die alten Internet Explorer haben leider keine Ahnung, was box-sizing ist und machen es deshalb unmöglich, mit unserem Rastersystem zu arbeiten. Wer sich die HTML- und CSS-Datei unseres fertigen Blog-Layouts bereits genauer angesehen hat, wird bemerkt haben, dass ich eigene Styles gemacht habe, die aktiviert werden, sobald unser Blog mit einem Internet-Explorer angesehen wird, der älter als Version 9 ist. Sollte das der Fall sein, bekommt unser html-Tag die Klasse .ie:

<!--[if lt IE 9]><html class="ie" lang="de"><![endif]-->
<!--[if gte IE 9]><!--><html lang="de"><!--<![endif]-->

Die folgende Methode habe ich von Joni Korpi, der auch das Golden Grid System entwickelt hat. Die Idee lautet, ein simples Layout extra für alte Internet Explorer zu entwickeln. In unserem Fall sieht der zusätzliche Code so aus:

.ie body {
    width:48em;
    }
.ie h1, .ie #aside {
    float:right;
    width:13em;
    }
.ie #main {
    float:left;
    width:29em
    }

Auf diese Weise brauchen wir uns keine Sorgen mehr um veraltete Browser zu machen und können beruhigt an unserem Layout weiterarbeiten. Menschen die unseren Blog später in einem alten IE ansehen, werden nicht einmal merken, dass sie eine eigene Light-Version zu sehen bekommen.

So sieht unser Blog auf alten IEs aus. Das Layout ist im Gegensatz zu modernen Browsern fix und passt sich nicht an die Fensterbreite des Besuchers an.

Zum Schluss

Ich habe seit dem letzten Artikel einen Blick auf das Semantic Grid System geworfen. Im Großen und Ganzen sieht dieses Raster sehr gut aus. Es gibt nur eine Sache, die mich daran stört: Nicht nur die Spaltenbreiten sondern auch die Randzonen sind in Prozent angegeben und hängen von der Fensterbreite ab. Im Gegensatz zu unserem Rastersystem kann es also passieren, dass die horizontalen Abstände zwischen den Elemente zu eng werden:

Beim Semantic Grid hängen die horizontalen Abstände der Elemente von der Fensterbreite ab. Dadurch passiert es, dass der Abstand, wie bei diesem Screenshot, zu klein wird, um z.B. 2 Spalten Text klar voneinander zu trennen.

In unserem Raster-System machen wir die horizontalen Abstände, wie bereits mehrmals beschrieben, von der Schriftgröße bzw. der Zeilenhöhe abhängig. Auf diese Weise bleiben die Verhältnisse einer Seite stets klar und ersichtlich. Da unsere Methode mit Hilfe von box-sizing funktioniert, müssen wir eine Light-Version für alte IEs machen. Das ist zwar nicht perfekt aber auf jeden Fall besser, als die Randzonen unseres Rasters auch elastisch zu machen.

Für jeden der mit dem aktuellen Blog-Layout herumspielen möchte, hier noch einmal alle Dateien im Überblick:

Blog-Layout ohne Raster im Hintergrund

• blog-layout.html
• blog.css

Blog-Layout mit Raster im Hintergrund

• blog-grid.html
• grid.css

Blog-Layout ohne Styles

• blog-nostyles.html

Das Blog-Layout mit sichtbarem Raster braucht einige Hilfs-Container, um den Raster im Hintergrund anzeigen zu können. Ich schlage vor, diese Version zu verwenden, um die eigenen Layouts zu überprüfen und gleich sehen zu können, ob alles passt oder nicht. Wenn man eine Webseite schließlich online schalten möchte, kann man die Hilfscontainer einfach entfernen und erhält ein semantisch korrektes Markup.

Wie immer freue ich mich über jedes Kommentar zu diesem Raster-System. Mein Ziel ist es, ein solides und praktisches Framework für die Arbeit im Browser zu erstellen. Jeder, der mir dabei helfen kann, dieses Ziel zu erreichen, ist herzlich eingeladen, den aktuellen Stand auszuprobieren und wenn möglich auch zu kritisieren. Ich bin gespannt, was am Ende dabei herauskommen wird.

Selbstständige sind Menschen, die ihre eigenen Entscheidungen treffen und die niemanden brauchen, der ihnen den nächsten Schritt verrät. Menschen, die keine Angst davor haben, Fehler zu machen und die selbst die Verantwortung für ihre Entscheidungen übernehmen.

Die Zeiten sind vorbei, in denen sich Mitarbeiter darauf verlassen können, dass ihre Vorgesetzten wissen was zu tun ist. Das Management-Paradigma hat ausgedient und ist mittlerweile zu zeitaufwendig geworden, um den Anforderungen eines sich ständig ändernden Marktes gerecht werden zu können. Spätestens seit ein bedeutender Teil unseres Lebens online stattfindet, ändern sich die Anforderungen an Unternehmen und ihre Mitarbeiter so schnell, dass keine Zeit für die Trägheit des Managements bleibt.

Unternehmen, die in Zukunft erfolgreich sein wollen, brauchen deshalb Mitarbeiter die selbstsändig denken und arbeiten können. Mitarbeiter, die in Zukunft erfolgreich sein wollen, müssen lernen, selbst Entscheidungen zu treffen und nicht darauf zu warten, bis jemand kommt, der ihnen sagt, was sie zu tun haben.

Nur auf diese Weise können wir ständig den Status Quo herausfordern und veraltete Systeme und Modelle erkennen, um diese rechtzeitig hinter uns zu lassen und über eine bessere Lösung nachdenken zu können.

Als Interface-Designer müssen wir lernen mit dieser Herausforderung umzugehen, um unseren Benutzern ein erstklassiges Erlebnis bieten zu können. Am einfachsten geht das, wenn wir anfangen unsere Webseiten im Browser zu designen. Wie das geht und wie wir auch im Browser in den Genuss eines Rastersystems kommen, beschreibe ich in diesem Artikel.

Jedem, der es gewohnt ist, mit HTML und CSS zu arbeiten, empfehle ich, direkt die fertige Version unseres Rastersystems anzusehen und den Code selbst zu verstehen. Wer weniger Erfahrung mit Webdesign im Browser hat, erfährt in diesem Artikel Schritt für Schritt, wie er oder sie, selbst ein flexibles Rastersystem entwickeln kann.

Die Grundlagen

Als erstes müssen wir eine Sache verstehen: Breitenangaben in Pixel gehören der Vergangenheit an. Als es noch keine Tablets und Smartphones gab, war es in Ordnung, eine Webseite mit 960px Breite zu machen. Heute gibt es aber Geräte wie das iPhone mit 320px Bildschirmbreite genauso, wie Cinema-Displays mit 2.560px. Der beste Weg um mit dieser Vielfalt umzugehen, sind Breitenangaben in Prozent.

Um die richtige Spaltenbreite in Prozent zu berechnen, dividieren wir einfach 100 (gesamte Bildschirmbreite = 100%) durch die Anzahl der gewünschten Spalten. Brauchen wir 3 Spalten, dividieren wir also 100 durch 3 und erhalten die Spaltenbreite von 33,33%. Bei 6 Spalten wären es dementsprechend 16,66% und bei 12 Spalten wären es 8,33%.

Wenn unser Raster aus 3 Spalten bestehen soll, dividieren wir 100 durch 3 und wir erhalten die richtigen Breitenangaben in Prozent.

Ein Rastersystem besteht aber nicht nur als Spalten, sondern auch aus Randzonen. Diese Randzonen befinden sich jeweils zwischen 2 Spalten und sorgen dafür, dass die einzelnen Spalten genügend Abstand zueinander haben. Das ist z.B. für mehrspaltigen Text wichtig:

Ohne Randzonen zwischen den einzelnen Spalten, ist unser Rastersystem unbrauchbar.

Meiner Erfahrung nach kommt es häufig vor, dass diese Randzonen zu eng gewählt werden. Vor allem bei flexiblen Layouts passiert es schnell, dass der Abstand zwischen den Wörtern zweier Spalten so knapp wird, dass die Verhältnisse einer ganzen Seite unklar werden. Um dem entgegenzuwirken, geben wir die Breite der Randzonen nicht in Prozent an und machen sie statt von der Bildschirmbreite, von der Textgröße abhängig. Das hat den Vorteil, dass Spalten selbst bei großer Schrift, noch genügend Abstand zwischen sich bringen.

Die Breite der Randzonen entspricht genau der Zeilenhöhe des Texts. Sie bleibt von der Bildschirmbreite völlig unbeeinflusst.

So wird’s gemacht:

Wie das Ganze aussieht, wenn wir unser bisheriges Wissen in der Praxis anwenden, zeigt diese Demo-Version.

Wie ihr sehen könnt, erstreckt sich unser Rastersystem immer auf die gesamte Bildschirmbreite. Die Breite der einzelnen Spalten hängt von der Größe eueres Browser-Fensters ab. Wenn ihr die Größe ändert, werdet ihr feststellen, dass sich auch die Breite der Spalten ändert. Die Breite der Randzonen ändert sich hingegen nicht.

Bevor wir weitermachen, werfen wir einen kurzen Blick auf den HTML- und CSS-Code hinter diesem Beispiel. Zuerst der Inhalt des Body-Tags:

<div class="grid">
    <div class="wrapper">
        <div class="span"></div>
        <div class="span"></div>
        <div class="span"></div>
    </div>
</div>

Und dann die CSS-Datei:

/* main-styles */

body {
    margin:0;
    }
.wrapper {
    height:100%;
    }

/* grid */

.grid {
    bottom:0;
    position:absolute;
    top:0;
    width:100%;
    }
.grid .span {
    background:#FFB2B2;
    border-left:1em solid #FFFFFF;
    border-right:1em solid #FFFFFF;
    -webkit-box-sizing:border-box;
    -moz-box-sizing:border-box;
    -o-box-sizing:border-box;
    -ms-box-sizing:border-box;
    box-sizing:border-box;
    float:left;
    height:100%;
    position:relative;
    width:33.33%; /* 3 columns */
    }

Wie ihr sehen könnt, haben wir im body einen Container mit der Klasse .grid, welcher 100% Breite hat und absolut positioniert ist. Diese Angaben dienen dazu, dass unser Raster über die gesamte Seite verläuft. Innerhalb dieses Elements haben wir einen weiteren Container mit der Klasse .wrapper. Dieser Container hat eine Höhe von 100% und bewirkt, dass unser Raster auch ohne Inhalt angezeigt wird.

Schliesslich haben wir im div .wrapper 3 Container mit der Klasse .span. Diese 3 Container stellen unsere 3 Spalten dar. Sie haben jeweils eine Breite von 33.33% und auf der linken und rechten Seite einen border:1em. Dieser Border entspricht der Standard-Zeilenhöhe von 1 und stellt die Randzonen unseres Rastersystems dar. Wenn wir später eine Zeilenhöhe von 1.5 haben, stellen wir diesen Border einfach auf 1.5em.

Das Besondere an den Spalten ist ihr Attribut box-sizing, welches bewirkt, dass border und padding nicht wie üblich zur Breite eines Containers dazugerechnet werden, sondern sich innerhalb einer Box ausbreiten. Das ist wichtig, weil sonst eine width:33.33% und ein border:1em mehr als ein Drittel von 100% wären und unsere Spaltenbreiten somit zu breit würden.

Links: Im Standard Box-Modell werden padding und border zur width hinzugefügt.
Rechts: Mit Hilfe von box-sizing breiten sich beide nach innen aus.

Und wie wird daraus ein praktisches Rastersystem?

Man kann sagen, dass das was wir bis jetzt haben, ein passendes Raster für Smartphones ist. Bei einer Bildschirmbreite von 320px sind 3 Spalten bestimmt eine gute Wahl. Wir wollen jetzt von hier ausgehend, passende Rastersysteme für höhere Bildschirmauflösungen entwickeln. Dafür verwenden wir sogenannte Media Queries.

Media Queries stellen einen einfachen Weg dar, die Bildschirmbreite per CSS abzufragen. Auf diese Weise kann man abhängig von der Breite, verschiedene Styles vergeben. Gemacht wird das Ganze z.B. so:

@media (min-width:48em) {
    #styles
    }

Hierbei sei angemerkt, dass wir die Bildschirmbreite nicht in Pixel abfragen sollten, sondern in em. Ich werde in einem späteren Blog-Artikel noch erklären, warum wir (fast) immer em an Stelle von px verwenden sollten. Damit dieser Artikel nicht noch länger wird, belassen wir es aber vorerst dabei.

Für jeden, der die Verwendung von em nicht gewohnt ist, gibt es eine einfache Formel, um Pixelwerte in em umzuwandeln:

Ausgangswert in Pixel ÷ Textgröße des Elternelements = Wert in em

oder anders gesagt:

768px ÷ 16px = 48em

Unsere Media-Querie von oben macht also nichts anderes, als die darin befindlichen Styles zu aktivieren, sobald das Fenster genau 768px oder breiter ist. Mit Media-Queries können wir noch viele andere Dinge abfragen, wie z.B. die Drehung eines Smartphones (portrait oder landscape), für unsere Zwecke reicht die Abfrage der Bildschirmbreite aber völlig aus.

Damit diese Media-Querie auch auf mobilen Geräten funktioniert, schreiben wir folgende Zeile Code in unser HTML-Dokument:

<meta name="viewport" content="width=device-width"/>

Um unser Rastersystem für höhere Auflösungen anzupassen, fügen wir als erstes die nötigen Spalten in unser HTML-Dokument ein:

<div class="grid">
    <div class="wrapper">
        <div class="span col-3"></div>
        <div class="span col-3"></div>
        <div class="span col-3"></div>
        <div class="span col-6"></div>
        <div class="span col-6"></div>
        <div class="span col-6"></div>
        <div class="span col-12"></div>
        <div class="span col-12"></div>
        <div class="span col-12"></div>
        <div class="span col-12"></div>
        <div class="span col-12"></div>
        <div class="span col-12"></div>
    </div>
</div>

Die Anpassung im Markup macht aus unserem 3-spaltigen ein 12-spaltiges Layout. Um die Anzahl der Spalten an die Fensterbreite anzupassen, fangen wir damit an, die Spalten 4 bis 12 standardmässig auszublenden:

.col-6, .col-12 {
    display:none;
    }

Ab einer Bildschirmbreite von 48em ändern wir die Spaltenbreite von 33.33% auf 16.66% und blenden zusätzlich zu den ersten 3 Spalten auch die Spalten 4 bis 6 ein.

@media screen and (min-width:48em) {
        
    /* grid */

    .grid .span {
        width:16.66%; /* 6 columns */
        }   
    .col-6 {
        display:block;
        }
    
    }

Bei einer Mindestbreite von 48em ändern wir die Spaltenbreite von 33.33% auf 16.66% und erhalten 6 statt 3 Spalten

Bei einer Fensterbreite von 64em (1.024px) werden aus 6 Spalten schliesslich 12 (100 ÷ 12 = 8.33%).

@media screen and (min-width:64em) {

    /* grid */

    .grid .span {
        width:8.33%; /* 12 columns */
        }       
    .col-12 {
        display:block;
        }

    }

Mit Hilfe der Media-Queries landen wir schließlich bei einem Standard-Raster mit 12 Spalten.

Wir haben jetzt ein Rastersystem entwickelt, dass je nach Fenstergröße, in 3 bis 12 Spalten eingeteilt wird. Jetzt beschränken wir noch die maximale Breite unserer Webseite, in dem wir der Klasse .wrapper eine max-width: 74em verpassen und mittels margin: 0 auto vertikal zentrieren, und schon haben wir ein flexibles Rastersystem, das sich an die Auflösung unserer Besucher anpasst.

Arbeiten mit unserem neuen Rastersystem

Als nächstes wollen wir unser Rastersystem so anpassen, dass wir angenehm damit arbeiten können. Unser Ziel lautet, das Raster in den Hintergrund zu bringen und darauf eine Webseite zu gestalten. Beginnen wir wieder mit der HTML-Datei:

<div id="content">
    <div class="wrapper">
        <div class="wrapper" id="main-content">
        main-content
        </div>
        <div class="wrapper" id="additional-content">
        additional content
        </div>
    </div>
</div><!-- content -->

Als Beispiel wähle ich ein Standard-Layout, welches links einen breiteren Bereich für den Inhalt bietet und rechts daneben einen schmaleren Bereich für zusätzliche Informationen zeigt:

Links: main-content mit einer Breite von 66.66% bei einer Bildschirm­breite von mehr als 1.024 Pixel.
Rechts: additional-content mit einer Breite von 33.33%.

Um dieses Layout mit unserem Rastersystem zu erreichen, ergänzen wir unsere CSS-Datei um folgenden Inhalt:

#content {
    bottom:0;
    position:absolute;
    top:0;
    width:100%;
    z-index:99;
    }
#additional-content, #main-content {
    float:left;
    padding:0 1em;
    position:relative;
    }
#additional-content {
    width:33.33%;
    }
#main-content {
    width:66.66%
    }

Als erstes positionieren wir unseren #content genauso, wie wir das .grid positioniert haben. Damit der Inhalt über dem Raster liegt, geben wir dem #content einen z-index:99, während wir dem .grid einen z-index:1 verpassen.

Anschliessend positionierern wir #additional-content und #main-content relativ innherhalb von #content, ergänzen die beiden um jeweils ein padding links und rechts von 1em (=Randzonen) und lassen die beiden Container nach links floaten. Abhängig von der Breite der einzelnen Elemente werden sie dadurch entweder nebeneinander oder untereinander angezeigt.

Um zu sehen, wie sich die beiden Elemente bei den verschiedenen Auflösungen verhalten, schaut euch einfach die fertige Version unseres Rastersystems an und ändert die Fenstergröße.

Abschliessende Bemerkungen

Ich habe den Containern #additional-content und #main-content eine Hintergrundfarbe in RGB gegeben, weil ich sie auf diese Weise durchsichtig machen kann, ohne den Kontrast des Inhalts zu beeinflussen. Wie ihr sehen könnt, stoßen die beiden Container direkt aneinander. Der Abstand zwischen den beiden Elemente ergibt sich lediglich aus dem padding. Je nach Bildschirmbreite haben die beiden Elemente zusätzlich eine height:100% oder height:50%. Diese Angaben sind in der Praxis unnötig und dienen nur zu Demonstrationszwecken, um den Elementen eine Höhe zu geben, ohne sie mit Inhalt befüllen zu müssen.

So sieht unser Rastersystem auf einem Laptop aus …

… und so am iPod und am Kindle

Mein vorgeschlagenes Rastersystem besteht aus maximal 12 Spalten. Der Grund dafür ist, dass es sich als nützlich erwiesen hat, wenn die Spaltenanzahl eines Rasters durch 2, 3 und 4 dividiert werden kann. Auf diese Weise lassen sich die meisten Layouts realisieren. Wenn ihr die Spaltenanzahl dennoch ändern möchtet, braucht ihr nur den Prozentwert der width von .span zu ändern und dementsprechend die Breiten der Inhalts-Container darauf anpassen.

Wie in einem früheren Artikel bereits angemerkt, sind Interface-Designer auch Typografen. Dieser Artikel hat sich, wenn man so will, mit Makrotypografie oder dem Layout beschäftigt. Um wirklich sinnvoll mit diesem Rastersystem arbeiten zu können, müssen wir uns noch der Mikrotypografie widmen. Ich plane hierfür einen Artikel, in dem wir lernen, wie man Schriftgrößen wählt, Zeilenhöhen berechnet und einen vertikalen Rhythmus für seine Webseite entwickelt, der auf einem Grundlinienraster basiert.

Bis dahin freue ich mich auf jeden, der etwas zu diesem Rastersystem anzumerken hat. Ich weiß z.B. dass dieses System im derzeitigen Zustand nicht auf IE 6 und 7 funktioniert, was mir persönlich egal ist, wofür es aber auch eine Lösung geben wird. Für jeden, der sich für Rastersystem für Webdesigner interessiert, sind hier noch ein paar Links zu Seiten und Artikeln, welche mich zu diesem Rastersystem inspiriert haben. Ich wünsche viel Spaß beim Lesen und Herumexperimentieren.

Ergänzung

Hier ist ein Artikel, der beschreibt, wie wir mit diesem Rastersystem ein Layout für einen Blog entwickeln können.

Wie soll man z.B. den Arbeitsaufwand für die Programmierung einer Webseite schätzen, wenn man noch nicht weiß, wie das User Interface aussehen wird? Wie soll man das User Interface entwickeln, wenn man noch nicht weiß, was sich die Benutzer der Webseite erwarten? Wie soll man wissen, was sich die Benutzer erwarten, wenn man noch nicht mit ihnen gesprochen hat? Und vor allem: Wie soll man das alles in einem Angebot erkären?

Gleich als Erstes: Erklären sollte man in einem Angebot gar nichts. Die meisten Kunden durchsuchen ein Angebot nämlich nach genau 2 Informationen:

1. Wie viel muss ich dafür bezahlen?
2. Wie lange muss ich darauf warten?

Wenn wir diese beiden Fragen richtig beantworten, haben wir einen neuen Kunden gewonnen. Und dabei bringt eine perfekte Schätzung unseres Arbeitsaufwands ohnehin nichts.

Der richtige Preis

Der richtige Preis hängt nicht nur davon ab, wie viel unsere Arbeit wert ist, sondern vor allem davon, was unsere Kunden dafür bezahlen wollen. Wir sollten deshalb aufhören, Fantasie-Stunden zu verplanen und damit beginnen, unseren Kunden in den Mittelpunkt der Angebotslegung zu stellen.

Natürlich müssen wir ein Gefühl für den Umfang eines Projekts bekommen, um einen Preis festzulegen. Das brauchen wir nicht nur um einen fairen Preis für unseren Kunden zu finden, sondern auch dafür, einen fairen Preis für uns zu finden. Bei all der Rücksicht für unsere Kunden, müssen wir darauf achten, keine Projekte zu machen, die mehr Arbeit machen, als sie Geld bringen.

Ich denke der angebotene Preis hängt demnach von 3 Kriterien ab:

1. Erwartungshaltung unseres Kunden
2. Wirtschaftlichkeit für uns
3. Tatsächlicher Arbeitsaufwand

Die Reihenfolge stimmt übrigens. Die Erwartungshaltung unseres Kunden ist am wichtigsten, weil unser Kunde derjenige ist, der das Angebot annimmt oder ablehnt. Danach kommt die Wirtschaftlichkeit für uns, weil wir keinen zu niedrigen Preis anbieten dürfen. Schließlich spielt auch der Arbeitsaufwand noch eine Rolle. Er kommt aber am Ende, weil wir zur Zeit der Angebotslegung nur spekulieren können, wie lange wir wirklich für unsere Arbeit brauchen werden.

Den richtigen Preis zu finden, heißt diese drei Faktoren miteinander in Einklang zu bringen. Wichtig anzumerken ist dabei, dass der Preis nicht von unserer Erwartungshaltung abhängt. Wenn wir eine Anfrage eines Kunden erhalten, ist das Erste, was wir automatisch tun, uns Bilder der fertigen Lösung vor unserem geistigen Auge vorzustellen. Wir sehen bereits ein perfektes Design, das zum Aushängeschild unseres Portfolios werden wird. Das ist schön für uns, es darf aber keinen Einfluss auf den Preis für unseren Kunden haben.

Die richtige Dauer

Sobald wir den Preis gefunden haben, stellt sich noch die Frage, wie lange wir dafür brauchen. Oder besser gefragt: Wie lange dürfen wir dafür brauchen? Wenn wir bei einem Projekt 10.000 Euro verdienen, dürfen wir dafür keine 3 Monate brauchen. Wir müssen es in ein paar Wochen schaffen, sonst verbringen wir zu viel Zeit damit, Arbeiten zu erledigen, die nicht einmal unsere Miete bezahlen können. Und dann wird aus unserer Arbeit schnell ein anstrengendes Hobby.

Eine kürzere Projektdauer hat nicht nur den Vorteil, dass wir mehr Zeit für andere Arbeiten haben, sondern führt auch noch dazu, dass wir unserem Kunden einen besseren Preis anbieten können. Je kürzer wir dafür brauchen, desto weniger müssen wir dafür verlangen. Und wer Punkt 5 dieses Artikels kennt, weiß, dass sich Arbeit ohnehin solange ausdehnt, wie Zeit für ihre Erledigung zur Verfügung steht.

Der richtige Preis und eine möglichst kurze Projektdauer sind mindestens 80% des Angebots. Wenn die beiden stimmen, haben wir gewonnen, selbst dann, wenn der Rest des Angebots nicht hundertprozentig passt. Andererseits können wir eine Woche am perfekten Angebot herumtüfteln und ein Dokument setzen, dass einen Design-Award gewinnen sollte, und verkaufen trotzdem nichts, wenn wir die Erwartungshaltung unseres Kunden nicht verstanden haben.

Was meint ihr dazu?

Wir haben in den letzten Jahren vieles ausprobiert. Wir haben teilweise nach Stunden abgerechnet, teilweise den Arbeitsaufwand im Vorfeld stundengenau geschätzt und unsere Angebote teilweise so geschrieben, wie ich es in diesem Artikel erklärt habe. Was ist eure Erfahrung mit Angeboten? Was funktioniert für euch, was funktioniert nicht? Seid ihr mit uns einer Meinung oder findet ihr das lächerlich?

Es würde mich freuen, eure Ansichten zu hören und ich glaube, dass wir eine Menge voneinander lernen können, um in Zukunft bessere Angebote zu schreiben und bessere Arbeit zu machen.

Ein kurzer Auszug:

Es gibt diesen Trend, Parties für seine Kunden zu veranstalten. […] Kein Kunde, der bei Verstand ist – und das sind die Kunden, die wir uns wünschen – würde uns Vertrauen schenken, nur weil wir ihm oder ihr einen Vollrausch spendieren. […] Es spricht natürlich nichts gegen eine gute Verbindung zu Kunden, aber wir sollten nicht vergessen, dass es sich bei unseren Kunden nicht um Idioten handelt, die man mit ein paar Flaschen Wein bestechen kann. Aus dem Artikel 6 Dinge, die man über Kunden wissen sollte

Das klassische Argument für Schulnoten ist, dass man alle Schüler miteinander vergleichen kann. Man hat ein objektives System, dass auf einen Blick verrät, welche Schüler besser sind als andere. Und darin liegt auch das größte Problem: Es handelt sich bei dieser Objektivität um eine Illusion.

Noten sind ungerecht. Nicht nur weil manche Lehrer ungerecht beurteilen, sondern weil das Wissen eines Menschen nicht auf einer Skala von 1 bis 5 dargestellt werden kann. Selbst auf einer Skala von 1 bis 100 würde das nicht gehen, weil man Wissen nicht objektiv bewerten kann. Das ist aber genau was passiert, wenn am Ende eines Semesters eine Note von 1 bis 5 im Zeugnis stehen muss. Es werden irrwitzige und absolut nicht nachvollziehbare Systeme erfunden, um selbst mündliche Prüfungen und Gruppenarbeiten mit einer Note zu bewerten. Wir verzichten auf eine faire Beurteilung zu Gunsten scheinbarer Objektivität.

Das Schlimmste an Schulnoten ist, dass sie von vielen Menschen ernst genommen werden. Da man die Leistung eines Schülers mit einer Zahl zwischen 1 und 5 versieht, entsteht der Eindruck, diese Beurteilung wäre objektiv und würde etwas über die tatsächliche Leistung eines Schülers verraten. In Wahrheit verrät eine Note aber mehr über den Lehrer als über den Schüler. Ich hatte in Englisch in der Hauptschule nie eine bessere Note als eine 4, als ich dann in die HAK kam, hatte ich nur noch 1er. Ich wurde nicht während der Sommerferien zum Englischprofi – die Ansprüche meines neuen Lehrers waren nur sehr viel niedriger als die meines alten. Würde man meine Leistung nur auf die Note reduzieren, wäre ich aber von einem unterdurchschnittlichen Schüler zu einem Vorzeigeschüler geworden.

Dieses Beispiel zeigt das größte Problem mit Schulnoten noch einmal ganz deutlich: Sie vermitteln Objektivität, obwohl sie in Wahrheit nichts anderes sind, als beliebig austauschbare Zahlen. Zahlen, die von so vielen Faktoren abhängen, dass sie die Leistung eines Schülers nicht einmal ansatzweise darstellen können. Diese Zahlen erwecken aber den Eindruck als wären sie objektiv und würden eine solide Grundlage sein, um unterschiedliche Schüler miteinander zu vergleichen. Sie sind aber nichts weiter, als der Versuch ein quantitatives System für etwas zu finden, dass sich nicht in ein solches System einteilen lässt.

Wir sollten der Wahrheit langsam aber sicher ins Auge sehen: Schulnoten sind ungeeignet, um die Leistung von Schülern zu bewerten. Jedes weitere Semester, in dem wir Schüler mit Noten zwischen 1 und 5 beurteilen, ist ein Zeichen für unsere Unfähigkeit, veraltete Systeme und Denkweisen aufzugeben und stattdessen über eine geeignetere Lösung nachzudenken.

Die Seite kann unter http://simplease.at/webtypo.html gefunden werden. Für jeden, der sich dafür interessiert, wie man die einzelnen Schriften einbindet, noch ein kurzer Auszug aus der CSS-Datei:

#arial {
	font-family: Arial, Helvetica, sans-serif;
	}
#arial-black {
	font-family: 'Arial Black', Gadget, sans-serif;
	}
#bookmann {
	font-family: 'Bookman Old Style', serif;
	}
#comic-sans {
	font-family: 'Comic Sans MS', cursive;
	}
#courier {
	font-family: Courier, monospace;
	}
#courier-new {
	font-family: 'Courier New', Courier, monospace;
	}
#georgia {
	font-family: Georgia, serif;
	}
#impact {
	font-family: Impact, Charcoal, sans-serif;
	}
#lucida-console {
	font-family: 'Lucida Console', Monaco, monospace;
	}
#lucida-sans {
	font-family: 'Lucida Sans Unicode', 'Lucida Grande', sans-serif;
	}
#ms-sans {
	font-family: 'MS Sans Serif', Geneva, sans-serif;
	}
#ms-serif {
	font-family: 'MS Serif', 'New York', sans-serif;
	}
#palatino {
	font-family: 'Palatino Linotype', 'Book Antiqua', Palatino, serif;
	}
#tahoma {
	font-family: Tahoma, Geneva, sans-serif;
	}
#times {
	font-family: 'Times New Roman', Times, serif;
	}
#trebuchet {
	font-family: 'Trebuchet MS', Helvetica, sans-serif;
	}
#verdana {
	font-family: Verdana, Geneva, sans-serif;
	}

Ich hoffe, der Einen oder dem Anderen ist damit geholfen und freue mich natürlich über Ergänzungen und weitere Hinweise.

Wenn ein Programmierer über seine Arbeit nachdenkt, sieht er Programmcode und Datenbanken. Designer sehen Menschen und Interfaces. Programmierer sind nicht schlauer als Designer, sie können nur besser denken, weil sie sich nicht mit menschlichem Verhalten, sondern mit technischen Möglichkeiten auseinandersetzen.

Um als Designer zu erfahren, was funktioniert und was nicht, müssen wir Benutzer-Interviews führen, Szenarios entwickeln, Prototypen bauen und Usability-Tests durchführen. Programmierer sehen hingegen sofort, ob sie eine Datenbankabfrage richtig oder falsch gemacht haben. Der entscheidende Unterschied zwischen Designern und Programmieren ist, dass menschliches Verhalten verwirrend ist, während technische Möglichkeiten eindeutig sind.

Das kann ein Segen für verwirrte Designer sein, die seit Tagen nichts anderes tun, als über ein neues Feature nachzudenken. Die technischen Einschränkungen zu kennen ist unersetzlich, um gute Design-Entscheidungen treffen zu können und mindestens genau so wichtig, wie user-zentrierte Design-Methoden. Designer sehen die Möglichkeiten und Programmierer kennen die Einschränkungen. Gemeinsam können wir beide Welten in Einklang bringen und eine bessere Lösung entwickeln.

Ich hab es durch. Das Nummer 1 Buch auf Amazon. Die Steve Jobs Biografie. Am meisten beeindruckt hat mich, wie Jobs sich auf eine Rede zur Graduierung von Stanford-Studenten vorbereitete. Es war sein erstes Mal eine solche Ansprache zu halten und nach langer Überlegung entschied er sich gegen die angebotene professionelle Beratung.

Jobs begann seine Rede in Stanford schlußendlich mit der Anmerkung, dass er nun lediglich 3 Geschichten erzählen werde.

Today I wanna tell you three storys about my life. That’s it. No big deal. Just three stories. Steve Jobs in his Stanford Commencement Speech 2005

In der folgenden Viertelstunde lieferte er einen sehr persönlichen Rückblick eigener Erfolge und Rückschläge. Er erzählte vom Studienabbruch, der ersten Liebe und seiner Krebs-Erkrankung. Die Studenten hingen sichtlich an seinen Lippen und das trotz des lärmenden Flugzeugs am Himmel.

Perfekte Präsentationen erzählen Geschichten. Und Jobs war ein Meister im Geschichtenerzählen. Die bis ins kleinste Detail inszenierten Produktvorstellungen von Apple sind gleichzeitig großartig erzählte Geschichten mit Menschen in den Hauptrollen.

Geschichten zu erzählen und weiterzugeben ist eine von den ältesten und wichtigsten menschlichen Fähigkeiten. Früher konnte Wissen, in Geschichtenform weitergegeben, das Bestehen einer ganzen Bevölkerung garantieren. Heute erzählen wir unseren Kindern Geschichten vor dem Einschlafen und wenn wir abstrakte Dinge greifbarer machen wollen. (Jeder von euch kennt wohl die Geschichte von der Biene und der Blume). Wir Designer verwenden Geschichten, um zu beschreiben, welche Erfahrungen Menschen bei der Verwendung unseres Interfaces machen sollen.

Gut erzählte Geschichten helfen beim Verständnis und machen komplizierte Dinge einfach. Vor kurzem ist ein großartiger Geschichten-Erzähler gestorben. Lasst uns dafür wieder mehr davon erzählen.

Das ist ein Ausschnitt des Covers von Edward Tufte’s The Visual Display of Quantitative Information. Unser Lehrer Konrad Baumann hat es als Einstieg zur ersten Einheit „User Interface Design“ gezeigt und uns damals gefragt, worum es sich dabei handeln könnte.

Vor diesem Tag dachte ich immer, Design müsste in erster Linie schön sein. In dem Moment, als mir klar wurde, dass auf diesem Bild ein Fahrplan dargestellt wird, der die einzelnen Zugverbindungen zwischen zwei Städten zeigt, habe ich meine Auffassung von Design aber stark erweitert. Design muss nicht (nur) schön aussehen – Design muss kommunizieren.

Ein Fahrplan, der alle Zugverbindungen zwischen Paris und Lyon zeigt (Achsenbeschriftungen Links: Haltestellen; Oben: Uhrzeit)

Auf der vertikalen Achse werden alle Stationen zwischen den beiden Städten angezeigt. Auf der horizontalen Achse sind die 24 Stunden eines Tages aufgelistet. Diagonale Linien die von links oben nach rechts unten gehen, zeigen Fahrten von Paris nach Lyon. Striche von links unten nach rechts oben, zeigen Fahrten von Lyon nach Paris.

Die besondere Schönheit dieser Abbildung liegt darin, dass weder ein einziger Strich sinnlos ist, noch irgendein Kontrast zufällig gewählt wurde. Je stärker der Kontrast einer diagonalen Linie, desto schneller der Zug. Das heißt Hauptverbindungen haben einen stärkeren Kontrast, als Regionalzüge, die man auch daran erkennt, dass sie weniger steil sind – also mehr Zeit für dieselbe Strecke benötigen. Wie lange ein Zug an einer Haltestelle stehen bleibt, erkennt man an den „Hackern“ in den Diagonalen:

Auch die Kontraste der vertikalen Linien ergeben Sinn. Stunden sind stärker hervorgehoben, als halbe Stunden. Halbe Stunden sind wiederum stärker hervorgehoben, als 10 Minuten. Jedes noch so kleine Detail sieht genauso aus, wie es aussieht, weil es so am meisten Sinn ergibt. 100% Kommunikation, 0% Dekoration – das ist perfektes Design.

Alle Informationen, die wir bis jetzt von euch gehört haben, lassen sich grob in drei Kategorien einteilen:

• Alltag: Wie sieht der Tagesablauf aus?
• Arbeit: Wie macht man die Arbeit?
• Kunden/Selbstständigkeit: Wie kommuniziert man mit Kunden?

Wir haben davon gehört, dass sich einige eine Fixanstellung wünschen und Teil einer Familie werden wollen. Sie wollen (fast) die ganze Woche im Büro sein, um in den Arbeitsalltag hineinzukommen. Alle diese Ziele fallen unter die Kategorie „Alltag“.

Von anderen haben wir gelesen, dass sie etwas über unsere Arbeitsweise lernen wollen. Sie interessieren sich für Interviews mit Usern, Usability Testing und User centered Design, wollen selbstständig an Projekten arbeiten und aktiv in die Firma eingebunden werden. Alle diese Ziele fallen unter die Kategorie „Arbeit“.

Dann gibt es noch diejenigen, die wissen wollen, wie die Kommunikation zwischen Kunden und der Firma abläuft. Leute, die etwas über das Thema (unternehmerische) Selbstständigkeit wissen wollen und denen bei anderen Praktika, der Blick hinter die Kulissen gefehlt hat. Diese Ziele fallen unter die Kategorie „Kunden/Selbstständigkeit“.

Wie erwartet, haben wir gelesen, dass es keinen Sinn macht, wegen Pseudo-Tätigkeiten, wie informieren oder Recherche machen im Büro zu bleiben oder Arbeiten zu machen, die einfach sonst niemand machen will. Es scheint auch Leute zu geben, die wirklich Verantwortung übernehmen wollen, wenn sie dafür mitreden können und ihre eigenen Entscheidungen treffen dürfen. Das hört sich schon einmal vielversprechend an.

Wir werden uns morgen zusammensetzen und darüber sprechen, wie wir weitermachen. Wir haben bereits ein paar Ideen und melden uns hier im Blog, sobald wir etwas entschieden haben. Sollte euch etwas auffallen, dass wir in diesem Zwischenbericht vergessen haben oder etwas einfallen, an das ihr bis jetzt nicht gedacht habt, dann schreibt am besten ein Kommentar.

Es gibt zwei Fragen, die man sich bei jeder Design-Entscheidung stellen kann. Die eine Frage lautet „warum nicht?“, die andere „warum eigentlich?“. Bei der ersten Frage, sagt man standardmässig zu allem Ja, bei der zweiten braucht man erst einen wirklichen Grund um etwas zu machen.

Ich denke dabei an Dieter Rams – weniger, aber besser. Leute die dazu neigen, ständig zu fragen „warum nicht?“, machen am Ende viel zu viele Dinge auf einmal und tun sich damit selbst und ihrer Arbeit keinen Gefallen. Leute die fragen, „warum eigentlich?“ machen nur wenige Dinge, weil sie standardmässig alles in Frage stellen. Wenn sie etwas machen, machen sie es dafür richtig.

Ein Beispiel ist die Gestaltung einer Webseite. Es gibt Webdesigner, die ihren Kunden von allen möglichen Spielereien erzählen, über Twitter- und Facebook-Anbindungen philosophieren und erklären, was technisch alles machbar wäre. Ihre Frage lautet „warum nicht?“, und wenn ihre Kunden dieselbe Einstellung haben, kommt am Ende eine Webseite heraus, die man sich wie dieses schweizer Taschenmesser vorstellen kann. Leider neigen viele Menschen dazu, Dinge zu machen, nur weil sie es können. Es ist möglich, also sollten wir es auch tun. Einige scheinen so von technischen Möglichkeiten und Gadgets fasziniert zu sein, dass sie vollkommen vergessen, warum sie etwas überhaupt tun.

Als Designer sollten wir ständig fragen „warum eigentlich?“ und nichts ohne Grund machen. Wer sich schon einmal die Arbeiten von Dieter Rams angesehen hat, wird erkennen, dass hier alles einen Grund hat. Die Form der Geräte, das Layout der Knöpfe und die Relationen der einzelnen Elemente – nichts wurde hierbei dem Zufall überlassen.

Die Arbeiten von Dieter Rams sehen nach über 50 Jahren noch immer modern aus. Möglich ist dieses zeitlose Design nur, wenn man damit aufhört, alles zu machen, was möglich ist und beginnt, bei jeder einzelnen Design-Entscheidung zu fragen „warum eigentlich?“. Das Ergebnis ist so wenig Design wie möglich und das sollte immer das Ziel eines Designers sein.

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.Antoine de Saint-Exupery

Das Schlimmste was wir tun können, ist stehenzubleiben und in Erinnerungen an die gute, alte Zeit zu schwelgen. Nicht daran zu denken, was heute Sinn macht, sondern alten Lösungen blind zu vertrauen. Unser Leben ändert sich schneller als je zuvor, und wenn wir dabei nur zusehen, wird es an uns vorbeiziehen, während wir an Ideen und Überzeugungen von gestern festhalten.

Wenn man die 200.000 Jahre alte Geschichte des Menschen in einem Buch mit 200 Seiten erzählen würde, würden wir anfangs lesen, wie wir von Säbelzahntigern und anderen Raubtieren gefressen werden. Auf den ersten 150 Seiten des Buches würden wir mehr oder weniger nichts anderes lesen. Erst nach ¾ des gesamten Inhalts würden wir von primitiven Werkzeugen, ersten Höllenmalereien und der Zubereitung von Fleisch erfahren. Die Erfindung des Buchdrucks würden wir schliesslich im vorletzten Absatz wiederfinden.

In den vergangenen 10.000 Jahren hat sich unser Leben stärker verändert, als in den ganzen 190.000 Jahren davor. Ein Großteil der Welt, in der wir heute leben, ist erst in den letzten hundert Jahren entstanden. Im Buch mit den 200 Seiten, würden Dinge, die für unser Leben selbstverständlich sind, wie Autobahnen, elektrische Haushaltsgeräte und das Internet, nicht mehr als den Schlusssatz ausmachen.

Unsere Welt verändert sich seit einigen Jahren so schnell, dass wir diese Veränderungen innerhalb unseres Lebens sogar wahrnehmen können. Und das ist der Grund warum wir den Status Quo ständig herausfordern müssen. Wir müssen anfangen darüber nachzudenken, was heute Sinn macht und aufhören, daran festzuhalten, was gestern funktioniert hat. Der Status Quo ist immer ein Relikt vergangener Tage und gehört deshalb ständig hinterfragt. Wir müssen neuen Ideen gegenüber aufgeschlossen sein und unseren Stolz hinunterschlucken, wenn es darum geht, überholte Denkweisen aufzugeben.

Wir sollten sofort damit beginnen. Die Vergangenheit ist vorbei, sie kommt auch nicht wieder. Genauso wenig Sinn macht es, sich Gedanken über eine Zukunft zu machen, die es noch nicht gibt. Das Einzige, was wirklich existiert, ist die Gegenwart. Sie ist unsere Möglichkeit, etwas zu tun. Deshalb wird es nie einen besseren Zeitpunkt als ständig geben, um den Status Quo herauszufordern und über eine bessere Lösung nachzudenken.