alps hypertexte

Im englischsprachigen und deutschsprachigem Raum wird derzeit darüber diskutiert, ob Designer auch das Frontend per XHTML/CSS entwickeln können sollen. Wie bei den meisten mit "komt-drauf-an" beantwortbaren Fragen, stört mich daran schon die beigelegte Suggestion. Soll jemand etwas können ...? Na, schön wär's für sie/ihn.

"Aber in Branche XY ..."

Alle Argumente, die Analogien zu anderen Industrien herstellen: in die Tonne damit. Andere Industrien, andere Begebenheiten. Man kann nicht pauschal sagen, ein Designer muss nicht coden können, weil ein Buchkritiker auch nicht Bücher schreiben oder ein Architekt die Statik seines Gebäudes nicht selber berechnen muss. Andere Branchen, andere Situationen. Beim Bau geht es unter anderem auch um "Sicherheit am menschlichen Leibe", wenn eine Decke bei der Hauseinweihungsparty nicht einstürzen darf. Angesichts diverser Unterschiede und geschichtlicher Entwicklungen sind in anderen Branchen die Positionen entsprechend ausdifferenziert oder nicht. Die Web-Branche ist immer noch jung. Das Non-Plus-Ultra der Webentwicklung ist noch lange nicht gefunden und die Verfahrensweisen auf jeder Ebene (von Projekt-Mangement bis Coding) wandeln sich mit großer Geschwindigkeit.

Richtig, die Branche ist erwachsen(er) geworden und die Zeiten, in denen man als One-Man-Show die ganze IT einer mittelständischen Firma am Laufen hielt, sind lange vorbei. Job-Definitionen sind feiner geworden und die Spezialisierung in einzelnen Bereichen gestiegen. Doch sind wir hierbei irgendwo in der Mitte der Entwicklung, die morgen, nächstes Jahr oder in 3 Jahren schon wieder ganz anders aussehen kann.

Erst differenzieren, später aber doch "Verständnis" zeigen?

Das Webstandard-Blog hat mit den "Phasen der Enwtwicklung eines Webprojektes" ein schönes Modell des Produktionsprozesses aufgezeichnet. Dies ist die klassische Situation. Nicht die am weitesten verbreitete, aber sehr klassisch. Wenn die einzelnen Phasen in einem Unternehmen durch mindestens einen Mitarbeiter repräsentiert wären, wäre das schon ein Grad an Ausdifferenzierung der Jobdefinition, den sich nur Unternehmen ab einer gewissen Größe leisten können. Kleinere Unternehmen können es sich nicht leisten, die Phasen des Produktionsprozesses zuerst in einzelne Stellen aufzuteilen und dann zu erwarten, dass diese genug Verständnis füreinander aufbringen werden.

Wieviel Verständnis wäre denn nötig, um noch relativ effizient zu bleiben? Nehmen wir das Verständnis des Screendesigners gegenüber der Arbeit eines XHTML/CSS-Coders. Dieser kommt im Produktionsprozess vor dem Coder dran und arbeitet dem Coder damit zu. Wieviel Verständnis müsste dieser aufbringen, damit im wirtschaftlichen Sinne ein besseres Ergebnis erzielt wird, als wenn diese beiden Prozesse ("Screendesign" und "Frontend-Development") von einer kompetenten Person ausgeführt werden würde? Dies ist die Kernfrage dieser Diskussion.

Dafür müssen wir wissen, wie komplex das Frontend sein soll. Der einfachste Fall wäre

a) Fixes Layout, nur Berücksichtigung moderner Browser ab IE7 und FF3

Etwas komplexer wäre

b) Elastisches Layout mit Unterstützung moderner Browser ab IE7 und einer Gnadenbehandlung für IE6/FF2.

Hardcore wäre

c) Frontend ist intelligent fluid (also nicht grenzenlos, wegen Zeilenbreite), soll fast identisch in allen Browsern ab IE6/ff2 aussehen und auf iPhone und anderen Devices auch eine gute Figur machen.

Von a) bis c) muss das Verständnis des Designers für den Frontend-Coder rasant ansteigen. Bei a) ist es noch so, dass der Designer fast nichts über XHTML/CSS wissen muss. Solche Frontends lassen sich fast immer mühelos (im Sinne von kostengünstig) umsetzen, auch ohne Verständnis untereinander.

Bei b) sieht es schon ganz anders aus. Elastisches Layout bedeutet, es soll mit der Schriftgröße skalieren (auch im IE6 und FF2). Und damit fallen die ganzen bequemen CSS3-Techniken mit abgerundeten Buttons und Schatten und Pipapo schon flach. Da müssen sliding doors-mäßige PNG- und GIF-Grafiken her, damit ein Navigations-Tab auch bei 3-4-facher Schriftvergrößerung noch nach einem Tab aussieht. Das heisst, der Screendesigner kann zusätzlich zu seinem Mockup schonmal von jedem Button, Tab und abgerundeter/schattierter Box eine Posterversion erstellen, die die größeren Zooms im IE6 und FF2 bedient. [Nebenbei: Ich habe seit 1997 noch keinen Grafiker getroffen, dem ich das in solchen Fällen nicht ausgiebig erklären musste.]

Bei den c)-Projekten muss der Grafiker schon mit dem Frontend-Entwickler verheiratet sein, um das nötige Maß an Verständnis mitzubringen. Denn fluid bedeutet

• Wie sieht die Site bei 1024x800 px Auflösung aus?
• Wie sieht die Site bei 1650x1050 px Auflösung aus?
• Wie sieht die Site bei 800x600 px Auflösung aus?
• Wie sieht die Site bei 320x480 px Auflösung aus?
• ...

... und so weiter. Designern, die ihre Mockups gleich in den entsprechenden verschiedenen Auflösungen ausgeliefert haben, bin ich noch seltener begegnet, als Designern, die schonmal etwas von sliding doors gehört haben. Das heisst, je komplexer das Frontend im Browser wird, desto weniger Verständnis hat ein nichtcodender Designer für die spätere Umsetzung. Er kennt vielleicht die Regel, das abgerundete Elemente 2-3 mal soviel Implementationszeit in c)-Projekten kosten, als die eckigen Pendants, aber das war's dann auch schon.

Die Moderne

Es hängt also von der Projekt-Komplexität und dem Budget ab, wieviel XHTML und CSS ein Designer verstehen sollte, um ein Projekt nach wirtschaftlichen Maßstäben zu realisieren. Hast du ein einfaches Projekt und eine nicht zu kleine Firma, kannst du dir locker Designer leisten, die kein XHTML und CSS verstehen. Je kleiner die Firma (und damit das Budget für ein Projekt) und komplexer das Projekt, desto unrealistischer wird die Beschäftigung eines Designers, ohne praktischem Code-Verständnis.

Die Teams, die Webanwendungen rauskloppen werden immer kleiner und effizienter. IT-Projekte sind immer noch sehr teuer und schwer kontrollierbar; der Bedarf nach Optimierung hält an. Oft sitzen Teams auch verstreut über den Kontinent und halten nur über's Netz Kontakt. Den Kollegen alle 15 Minuten stören und nachfragen ist da nicht immer, da sollte schon jeder sein Fach beherrschen. Wo Knappheit herrscht, entstehen Ideen und neue Wege und so sollte man sich vielleicht nicht die Frage stellen, ob oder wieviel XHTML/CSS ein Designer können muss, sondern eher, wieviel Design ein Coder verstehen sollte .

Denn wer sagt, dass Screendesign (am Grafikprogramm) ein notwendiger Schritt im Produktionsprozess ist?

Immer mehr Teams gehen zu sogenannten XHTML/CSS-Mockups über; das Screendesign findet wieder direkt im Browser statt. "Wieder" denn so war es auch ganz zu Anfangs, als einer noch alles (Von Konzeption bis zum Backend) gemacht hat. Meagan Fisher beschreibt in Make Your Mockup in Markup sehr anschaulich, wie solche Mockups gemacht werden. Jetzt beherrsche noch (d)ein Framework und rechne aus, wie schnell ein detailgetreues XHTML-Mockup steht und wieviel davon gleichzeitig schon Teil des Frontend-Codes darstellt. Mit diesem Verfahren sind Produktivitätssteigerungen um das 2-3-fache gegenüber der klassischen Aufteilung Screendesign/Frontend-Code möglich. Deshalb denke ich, dass in Zukunft mehr Firmen auf diesen Zug aufspringen werden.

Bis dahin sollten eher die klassischen Frontend-Coder, die bisher nur PSD-Mockups umgesetzt haben, einige Design-Grundlagen erlangen und zum Beispiel damit anfangen, Sachen wie text-shadow: rgba(0, 0, 0, 0.7) .125em .125em .75em; aus ihrem Repertoire zu verbannen.