Web ≠ Print

Die verfügbare Fläche

Ich habe keinen Designberuf gelernt. Weder Print- noch Mediendesign. Ich kann nicht mal mit einem Stift gut zeichnen. Vielleicht kann ich deshalb auch nicht die Ignoranz vieler Designer verstehen, sich dem Medium, für das sie etwas gestalten sollen, so zu verschließen. Viele Gestalter haben ihr Handwerk von der Pike auf gelernt, haben auf Skizzenblöcken, auf Leinwänden oder auch Bierdeckeln gelernt, Farben und Formen auf verfügbarem Platz in Einklang zu bringen. Betonung auf verfügbarem Platz. Im Web gibt nicht eine verfügbare Fläche. Es gibt derer annährend unendlich. Jede Auflösung von 1x1 bis [setze hohe Zahl x hohe Zahl ein] Pixel ist theoretisch möglich, auch wenn die Extreme wenig sinnvoll erscheinen. Doch gibt es vor allem seit ansteigender Verbreitung von immer mehr unterschiedlicher Smartphones und Flatscreens eine Riesenbandbreite an verschiedenen Bildschirmen, Betriebssystem-Konfigurationen und damit an Auflösungen. Nix DIN A4 quer und damit 297x210mm. Man weiß einfach nicht, wie der Besucher die Seite betrachten wird. Mal schnell mit dem iPhone oder dem neuesten Kinodisplay auf Leinwandgröße. Vor zehn Jahren hat man sich noch an bestimmte Maße gehalten (meist 800x600) und hat damit gut 80% der verbreiteten Auflösungen erschlagen. Und wie wenn sich seitdem nichts getan hat, erhalte ich entweder Entwürfe in DIN A4 quer als PDF oder Photoshop-Dateien in 1500Pixel Breite, da der Designer gerade einen neuen 24Zöller bekommen hat.

Es gibt nicht DEN Bildschirm!

Die Probleme

• Sand im Getriebe vor Umsetzungsstart

  Damit kann man nichts anfangen. Im besten Falle erkennt man, dass der Gestalter Talent hat und super "Print kann". Das bringt mir, dem Projekt und damit dem Kunden aber herzlich wenig. Neben dem nun folgenden Marathon von Nachfragen und (in der Regel kaum vergütbaren) Beratungen gibt es ein ganz entscheidendes Problem: Der Kunde hat das Design schon abgenommen. Streng genommen ja nicht das Screendesign, sondern ein Printdesign. Das ist dem Kunden aber egal.

• Verzögerung im Projektblauf

  Im Zweifelsfall ging dem vermeintlichen Umsetzungssart bereits ein längerer Gestaltungsprozess mit mehreren Korrekturstufen voraus. Jetzt kommt der Entwickler und hakt nach, zumindest ist es seine Pflicht. Durch diese neuen, vorher nicht einkalkulierten Abstimmungen verzögert sich der Start der Umsetzung, ohne dass dem Kunden klar zu machen ist, warum. Denn er wird sich – vollkommen zurecht – fragen, warum eine solche Kommunkation nicht schon vorher stattgefunden hat.

Empfehlungen

• Mitdenken

  Es gibt nicht nur Euren Schirm, habt auch andere Schirme auf dem Schirm (Phrasenschwein). Auch im Photoshop lassen sich Fenster verkleineren und vergrößern. Vor allem: Denkt daran, dass es immer größer geht. Soll die Seite wirklich nur 800 Pixel breit sein und die restlichen 1120 (zum Beispiel) leerer, weißer Raum? Der Hintergrund ist wichtig, legt wenigstens eine Textur oder sonstige Flächen, Formen oder Bilder rein.

  Ach ja: Bei einem DIN A4-PDF ist die erste Frage folglich: Was ist außenrum? Bei einer Photoshopdatei ebenso: Gebt Informationen mit, was im Hintergrund jenseits der Arbeitsfläche passieren soll. Und vor allem überlegt Euch, ob das Layout auch als fluides (das heißt mitwachsendes) oder semi-fluides Layout (unterschiedliche Varianten je nach Breite, so wie auf dieser Seite) funktioniert. Den Begriff "semi-fluid" gibt es glaube ich nicht, aber er passt ganz gut, Stichwort ist hier: @media und CSS.

• Testen

  Macht einen Screenshot bzw. speichert den Entwurf als Grafik ab. Ruft es auf verschiedenen Schirmen/Smartphones auf. So bekommt Ihr schon einmal einen kleinen Eindruck, wie das ganze unter verschiedenen Bedingungen wirken kann.

• Präsentation

  Bitte, bitte, bitte: Schickt Eurem Kunden keine PDFs. Das passt nicht, dafür ist ein PDF weder gedacht noch geeignet. Im Gegenteil: Ihr wiegt den Kunden in Sicherheit, er wird denken, genau so wird es später aussehen. Und das kann es nicht. Dasselbe gilt für Powerpoint und Keynote. Brauche ich eigentlich kaum erwähnen, aber habe ich alles schon erlebt. Als Konsequenz gibt es eine Abnahme des Entwurfs und der Webentwickler muss quer schießen. Glaubt mir, das will keiner. Idealerweise baut Ihr einen Prototyp, der den Entwurf präsentiert. Oder zumindest erstellt Ihr eine HTML-Datei, die das Bild und den (gekachelten) Hintergrund auf verschiedenen Auflösungen realistisch darstellt.

Sonstiges

• Farben

  Glückwunsch zum kalibrierten Monitor. Eure Zielgruppe weiß nicht einmal was das ist. Selbst ich habe aus Gründen auch einen Monitor, der Farben dermaßen falsch und zu hell darstellt, dass Ihr Euch wundern würdet. Aber eure Zielgruppe weiß nicht, wofür diese Knöpfe an dem Schirm da sind und werden in der Regel eine Ansicht mit viel zu hellen Farben haben (Laptops mal ausgenommen). Also auch hier: Mitdenken, testen. Wichtigstes Stichwort: Kontrast.

• Zustände

  Nein, nicht die Zustände, die ich beim Anblick vieler Entwürfe kriege. Zustände sind: Was passiert, wenn man irgendwo mit der Maus drüber fährt (:hover), wenn man irgendwo klick (:active), oder wenn ein Menüpunkt gerade aktiv ist.

• Schriften

  Hier ist das Web endlich in Bewegung, man kann nun neben Times, Arial, Verdana und ein paar anderen auch individuelle Schriften nutzen. Vorausgesetzt, sie liegen als so genannte Webfont Kits vor. Kostenlose Kits gibt es zum Beispiel bei Fontsquirrel oder Google. Typekit ist ein kostenpflichtiger Anbieter mit sehr vielen Schriften im Angebot. Aber Achtung: Nicht jede Schrift eignet sich für unsere Sprache. Achtet darauf, dass auch alle relevanten Schriftschnitte (fett, kursiv) und vor allem Sonderzeichen und Umlaute vorhanden sind. Es ist auch nicht alles Gold, was glänzt, verschiedene Browser und Betriebssystem reagieren unterschiedlich auf die Schriften. Auch hier gilt wieder: Testen, testen, testen.

• Vollständigkeit

  Schön, wenn Ihr die Start- und eine Innenseite gestaltet habt. Wenn mir aber im Menü ein Downloadbereich, eine Sitemap oder ein Kontaktformular entgegenlachen, dann will ich nicht nur, nein ich muss wissen, wie das auszusehen hat. Ist doch auch irgendwo verständlich, oder?

• Skalierbarkeit - Willkommen in der Realität

  Last but not least: Die Menüpunkte einer Webseite sollten sich zwar in der ersten Ebene – bei anständiger Strukturplanung vorher – nicht mehr ändern, allerdings kommt sowas durchaus mal vor. Dann ist das Geschrei groß, wenn nicht mehr alles in eine Reihe passt. Für Submenüpunkte gilt: Die können auch mal länger sein als "Lorem" oder "Ipsum". Gleiches gilt für Headlines, Formularlabels usw. Ihr meißelt das Design nicht in Stein. Es muss leben dürfen, es braucht Freiräume zu entwickeln! Generell ist ein Lorem-Ipsum-Blindtext denkbar ungeeignet, schreibt lieber realistische Blindtexte. Und wenn Ihr schon dabei seid, schreib doch einfach in den Blindtext, was dort später mal erscheinen soll. Außerdem: Denkt an verschiedene Auszeichnungen des Textes: Listen, Links (auch den hover), Zitate und mindestens 3 Headline-Ebenen.

  Nachtrag (siehe Kommentare): Wenn Ihr Daten darstellen wollt, seien es Adressen, Downloadlisten, Newsheadlines im Archiv oder sonstige (tabellarischen) Informationen, denkt daran: Bei sehr vielen Informationen lassen sich solche Listen gerne durch Anfangsbuchstaben, Zeiträume oder durch ein simples Paging (z.B. 20 Elemente pro Seite) aufsplitten. Also wieder die Frage: Wie sieht eine solche Navigation aus? Was passiert, wenn...

Zusammenfassung

Diese Auflistung erhebt keinerlei Anspruch auf Vollständigkeit (Ergänzungen sind aber sehr willkommen!). Ich möchte gar nicht anfangen von Animationen, AJAX-Status-Feedback und Gridlayouts. Wenn obiges befolgt wird, ist man schon einmal auf gutem Weg. Und ich möchte keineswegs einem Printler ans Bein pinkeln, ich habe gar nichts gegen sie. Aber wie in jedem Arbeitsverhältnis zeugt es von Respekt, wenn man nicht nur das Rezept in sein Kochbuch schreibt, sondern auch an denjenigen denkt, der das ganze zubereiten soll. Und vor allem an denjenigen, der es letztlich essen muss.