Vom Design zum Front-End: Fragwürdiges

Eine PSD ist noch keine Website

Letztes Update:

Toll ist, wenn beim Bau einer Website oder -applikation KonzepterInnen, DesignerInnen, Front-EndlerInnen und ProgrammiererInnen von Anfang an an einem Tisch sitzen; und das machen, was sie am besten können – und zwar so früh wie möglich innerhalb der Entwicklung. In der Praxis ist es allerdings nicht selten, dass ein Design „fertig“ erstellt und anschließend an die Coding-Abteilung übergegeben wird. Das ist nicht immer ganz ohne.

Für eingeschworene ganzheitlich denkende Entwickler und Designer ist das manchmal eine undankbare Übergabe. Besonders, wenn dann auch noch Aufwandskalkulationen - sprich: Budgetfragen - eine Rolle spielen. Eine PSD, ein paar Inhalte - was kost'n das? Selten machen sich „Nur-Designer“ Gedanken über Verhalten der Website bei Interaktion mit dem Nutzer. Und herrje, gibt es da viele Interaktionen.

Fragen vom Front-End ans Design, ans Konzept und den Kunden in spe

Verhalten des Layouts

Ein Screendesign ist meist statisch, da es als Bild vorliegt. Eine Website ist es nicht. Der Browser, der Nutzer, selbst die Inhalte können ein Design beeinflussen. Aber wie reagiert dann das Design? Auch wenn der Design/Technik-Trend „responsive Design“ mittlerweile (hoffentlich) guter Stil ist, kann das je nach Vorlage unterschiedliche komplex werden. Da ist es besser, noch einmal nachzufragen.

  • Wie verhält sich das Layout bei Browsergrößenveränderungen? Skaliert der Inhalte fluide mit? Skalieren sowohl Text- als auch Bildinhalte? Ändern sich Mehrspaltenlayouts bei bestimmten Browsergrößen und wenn ja, wie? Gibt es minimale oder maximale Ausdehnungen der Seite?
  • Was geschieht bei einer Textgrößenänderung (Textzoom)? Soll ein vollständiger Seitenzoom erfolgen oder sollen tatsächlich nur Textinhalte proportional skalieren? Wie verhalten sich dann Bereiche mit fixierter Breite, wenn der Inhalt über die Grenzen hinaus wächst?
  • Wie weit geht ein mögliches responsives Design? Gibt es bereits Adaptionen des Designs für Tablets und Smartphones? Oder - noch besser - können wir sogar „Mobile First“ arbeiten?
  • Gibt es ein Konzept, mit dem „Fold“ umzugehen? Sollen beispielsweise bestimmte Elemente so gut wie möglich über dem Fold gehalten werden? (Der Fold ist der Punkt, an dem der Inhalt der Website über die Höhe des Browserfensters hinaus geht. Vergleichbar mit dem Falz bei Zeitungen. Aufgrund der vielen verschiedenen Geräte, auf denen eine Website dargestellt werden kann, ist der Fold meist keine feste Größe und gänzlich unbekannt.)
  • Soll ein Grundraster-orientierter vertikaler Rhythmus aufrecht erhalten werden?

Interaktionsdesign

Viele DesignerInnen aus dem Print-Bereich ärgern sich über Restriktionen des Webs im Vergleich zum Druck - zum Beispiel die selten 100%ige Kontrolle über Dimensionen und Positionen oder die verschiedenen Darstellungsqualitäten von Schriften. Doch im Interaktionsdesign liegen die Möglichkeiten des Webs, die es im Druck nicht gibt - und meist auch noch nicht im Photoshop-Design formuliert wurden.

  • Gibt es fix positionierte Elemente, die beim scrollen ihre Position nicht verlassen?
  • Hat das Scrolling sonst noch Einfluss auf einzelne Elemente? Gibt es zum Beispiel bereiche, die ihr Aussehen ab einer bestimmten Scrollhöhe verändern oder sind parallax-Effekte erwünscht?
  • Gibt es ein verbindliches Gestaltungsschema für interaktive oder dynamische Elemente, beispielsweise für Hover-Effekte oder Animationen?
  • Wie verhalten sich bestimmte Bereiche auf Touchscreens? Reagiert die Seite auf Swipes oder andere Touchscreen-Gesten auf eine bestimmte Weise?
  • Gibt es Bereiche, dessen Inhalte sich dynamisch ändern? Beispielsweise ein schnelles Nachladen von Inhalten per Ajax, ein Lazy-load oder eine Accordeon-Navigations-Struktur?

Code und Kompatibilität

In einer idealen Welt coden wir alle für ein Gerät, auf dessen Kapazitäten und Nutzung wir uns verlassen können. Diese Welt ist aber leidergottseidank alles andere als ideal. Daher beginnt die Frage nach Code und Kompatibilität mit dem Klassiker: welche Browser erhalten welche Unterstützung? Zusammen mit einzelnen Features bietet sich die Erstellung einer Browsermatrix an, wo klar definiert ist, welche Browser/Betriebsystem/Techink-Konfigurationen welche Art von Unterstützung erhalten.

  • Welche Browser sollen die Seite mit allen Features und so „hübsch“ wie möglich darstellen, welche Browser erhalten abgespeckte Versionen, welche überhaupt keine Unterstützung? Im Fokus stehen hier meist ältere Internet-Explorer-Versionen oder spezielle mobile Browser.
  • Sollen bestimmte Features nach dem Prinzip der Graceful Degradation oder des Progressive Enhancements realisiert werden?
  • Gibt es Vorgaben/Konventionen in Bezug auf den Code, für weitere oder nachfolgende EntwicklerInnen? Beispielsweise: werden Einrückungen mit Leerzeichen oder Tabulatoren gemacht, werden Variablennamen auf eine bestimmte Art gewählt, wie werden Kommentare verfasst?
  • Für eine spätere Übergabe: welche Anforderungen werden an die IDE (Integrated development enviromnent - integrierte Entwicklungsumgebung) gestellt? Welche Bibliotheken oder Preprocessoren werden verwendet, wie muss/darf der Server aufgesetzt sein? Wird eine Versionskontrolle wie Git verwendet?

Inhalt

DesignerInnen und auch CoderInnen arbeiten gern mit Blindtext und Platzhalterfotos. Doch irgendwann ist der Punkt erreicht, an dem der „echte“ Inhalt Platz finden muss. Dieser Platz sollte zuvor geplant und reserviert werden können. Das gilt gerade für die Inhalte, die man nicht auf den ersten Blick und schon gar nicht im Design sieht.

  • Stellt das Design bereits alle Arten von eingesetzten Medien dar? Wenn nicht, welche Art von Medien werden in welchem Umfang noch eingesetzt?
  • Bildet das Design alle geplanten Darstellungsformen ab? Diese Frage zielt darauf ab, ob weitere Seiten einfach nur mit Austausch von Inhalten im gleichen Layout erscheinen oder ob es noch weitere Layoutvariationen für verschiedene Seiten gibt.
  • Liegen Formulierungen für Meta-Tags for? Titel, Beschreibung, Schlüsselbegriffe, etc?
  • Gibt es Wording-Konventionen für alt- und title-Attribute?
  • Liegen alle eingesetzte Schrift- und Medienformate als Vorlage vor? Gibt es für jedes Medium auch eine entsprechende Weblizenz (insbesondere bei Schriftarten)?
  • Gibt es bereits Grafiken für Favicons, Touch-Icons, Open Graph-Images?
  • Liegen Logos, Icons und sonstige grafischen Elemente hochauflösend oder als Vektorgrafiken vor?

Unsichtbare Disziplinen

Auch wenn sich vieles hier als guter Standard aufdrängt, ohne Absprache und gemeinsames Verständnis für diese Art von Arbeiten kann es zu finanzfolgenschweren Missverständnissen kommen.

  • Werden spezielle Anforderungen an die Barrierefreiheit der Website gestellt?
  • Gibt es Konzepte oder Anforderungen zur Suchmaschinenoptimierung?
  • Sind semantische Anreicherungen (Microformats, RDFa) für bestimmte Elemente geplant?
  • Soll die Performance der Website noch auf eine bestimmte Art optimiert bzw. auf bestimmten Geräten getestet werden?
  • Wie soll die Website auf abgeschaltetes JavaScript reagieren?

Risiken und Nebenwirkungen

Die Auflistung hier ist nicht vollständig und die Beantwortung der Fragen ersetzt auf keinen Fall ein oder mehrere ausführliche Briefings. Eigentlich ist sie mehr eine Krücke, ein minimales Hilfsmittel, wenn es bereits zu spät für den Idealfall (nämlich die interdisziplinäre Arbeit von Anfang an) ist.

Aber sie kann helfen, eine erstes Gefühl für den Aufwand der Umsetzung zu bekommen und entsprechende Schätzungen erleichtern. Und vielleicht schafft sie es sogar, Missverständnisse und spätere Ärgernisse (weil das ja alles wieder gar nicht so aussieht wie im Design) gering zu halten.