9. Februar 2014 - Pascal Szewczyk

Die Suche nach dem heiligen Workflow-Gral

Früher war ich einfacher Webentwickler. Ich konnte so ziemlich alles, mehr oder weniger, was gebraucht wurde, um Websites in Internet zu schieben. Inklusive Design und Backende-Entwickler. Heute bin ich Experte für Reponsive Webdesign. Denn damit verdiene in letzter Zeit hauptsächlich mein Geld.

Das führt dazu, dass mir ein paar Sachen in der "echten Welt" aufgefallen sind, die ich hier gerne ausführen möchte.

Zähne knirschende Zähne

In den letzten Projekten sind viele zähneknirschende Situationen auf mich eingeschlagen und obwohl es sehr viel darüber zu lesen gibt, wird das Thema immer und überall noch viel zu sehr unterschätzt.

Ich muss ein wenig ausholen.

In letzter Zeit arbeite ich viel mit Demandware. Das ist eine Shoplösung für (sehr, sehr) große Firmen und war schon ein SaaS-Anbieter als Software-as-a-Service noch gar nicht erfunden war.

Demandware Entwicklung funktioniert so, dass die eigentliche Shop-Instanz auf einer Sandbox liegt und Änderungen an den Files direkt live auf die Sandbox übertragen werden, wo sie dann begutachtet werden können. Ein bisschen ist das so wie früher, als man mit FTP-Live auf dem Server rumgefummelt hat.

Der Vorteil ist, dass die komplexe Shop-Infrastruktur nicht lokal auf dem Rechner liegt sondern halt im Web. Das sogrt dafür, dass es kein großes gefummel gibt, um die komplexen Prozesse im Hintergrund lokal auf der eigenen Kiste zu bekommen. Der Nachteil ist, dass die Shop-Infrastruktur leider nicht lokal auf dem Rechner liegt sondern eben im Web. (sic!) In der Bahn mit Demandware zu arbeiten ist nahezu unmöglich und funktioniert nur in sehr homöopathischen Dosen.

Üblicherweise arbeitet man bei Demandware damit, dass man das standardisierte Theme kopiert und es soweit anpasst, dass es vom Look and Feel dem Endkunden schlussendlich gerecht wird. Standardisierung ist ein großes Thema in großen Buden. Mir als Advokat für die Entwickler-Happiness ist das aber ziemlich egal. Ich will ein gutes, von mir erzeugtes, Endprodukt und keine formalistischen Einschränkungen.

Wir haben also das Standardisierte-Desktop-Theme genommen und da irgendwie eine Responsive Lösung reingekloppt. Mit Anlauf und viel roher Gewalt. Es gab viele gute Gründe das zu tun. Einer davon waren die realen Gegebenheiten, die es zu diesem Schritt haben kommen lassen.

Das hat mich ein wenig darüber nachdenken lassen, ob man nicht doch irgendwie aus einer Responsive-Webdesign-Management-Perspektive nicht vielleicht doch auch so arbeiten könnte. Also ein fertiges Desktop-CSS mit geschickten Refactoring-Management in einen guten responsiven Zustand zu bekommen. Um es abzukürzen, die antwortet lautet: Nein.

Erst jetzt bemerken wir, dass der erste Wurf ganz okay war aber für die Weiterentwicklung muss man ständig große Extrarunden drehen, um alle Sachen angemessen zu testen.

Kurz überschlagen muss man jedes erweiterte oder neue Feature nun in folgenden Kontexten zu testen.

  • Internet Explorer 9
  • Internet Explorer 10
  • Internet Explorer 11
  • Firefox Windows
  • Firefox Mac
  • Chrome Windows
  • Firefox Mac
  • Safari auf dem iPad Landscape
  • Safari auf dem iPad Portrait
  • Safari auf dem iPhone 5 Landscape
  • Safari auf dem iPhone 5 Portrait
  • Safari auf dem iPhone 6 Landscape
  • Safari auf dem iPhone 6 Portrait
  • Android 5
  • Chrome
  • Firefox
  • Android 4
  • Stockbrowser
  • Chrome
  • Firefox

Ich komm sehr schnell auf über 20 Testcases. Diese immer bei jeder Änderungen zu testen ist weitreichend schwierig, was dazu führt, dass man nicht immer alles in allen Umgebungen testen kann. Es geht also nur mit einem architektonischen Ansatz, der es zulässt im Frontend gut arbeiten zu können.

(Übrigens am Ende findet Irgendjemand noch einen Bug auf einem Windows Phone 8.1 und obwohl man es unter geschäftlichen Apsekten überhaupt nicht rechtfertigen kann, warum dieser Bug jetzt ernsthaft gefixt werden muss bei einem quasi negativen Marktanteil. Hast du schon mal was von dem Verizon Ellipsis™ 7 Tablet gehört? Ich schon. Und diese ganzen Spezial-Devices hab ich noch gar nicht einberechnet.)

Vor allem weil Altlasten, die früher im Desktop noch gut funktionierten, aber nun im mobilen Bereich nicht mehr richtig laufen. Situationen mit denen Niemand gerechnet hat, die aber zu Frustration führen. Auf allen Seiten. Kunde findet's doofs, Entwickler findet's doof.

Der Masterplan als These

Dem Backend-Futzi es mal so richtig zeigen. Auf dem Bild sind zwei hübsche Frauen die sich prügeln

Mein aktueller Gedankenansatz geht dahin, dass man sich – so weit es geht – bei der effizienten Entwicklung eines Frontends vom Backend distanzieren muss.

Die Backend-Rowdys waren früher auf dem Entwickler-Schulhof immer die starken Jungs, die mit den Kippen, die mit den Killer-Phrasen gekommen sind „geht nicht – haut ab“.

Geht nicht, ist mir aber egal. Ich möchte hier ein super Front-End entwickeln mit einer super Usability, schön schnell, sehr performant. Da kann ich faule Ausreden von Halbstarken einfach nicht gebrauchen.

Ich glaube wir werden in nächster Zeit erleben, dass die Backend-Dudes in Webprojekten nicht mehr am längeren Hebel sitzen sondern die Frontendler sagen was zu gehen hat und was besser nicht getan wird. Jedenfalls hoffe ich das sehr.

Das mit dem Design

Schlimmes Stockphoto - Endlich zusammen mit der hübschen Desigerin arbeiten.

Wir wissen und ich habe es auch schon selbst dankbar erlebt, dass iterative Designprozesse am Besten sind. Ein Feature zusammen mit Konzepter und Designer skizzieren und möglichst schnell im Browser entwickeln. Was mich schon die ganze Zeit davon abhält dass als letztmögliche beste Idee zu akzeptieren ist – mal wieder – die Realität.

Große Firmen habe keine kleinen Entscheidungswege und am Ende muss tatsächlich jemand sitzen und Sachen „abnehmen“. Das wird vermutlich auch weiterhin besser in einem blödem Photoshop-Dokument passieren, welches schön unterschreib-kompatibel ausgedruckt werden kann.

Doch es bleibt dabei, wenn der hochentwickelte Frontend-Experte erst darauf schaut, nachdem Konzept mit Kunden und Designer die tollsten Dinge ausgedacht haben, wird am Ende kein Produkt mehr aus dem Browser gekrochen kommen, was noch irgendwie die Note “sehr gut” erhalten kann. Eher ausreichend. Niemand wird Frontend-Experte wenn er sich mit ausreichend zufrieden geben möchte. Dafür ist der Job einfach zu schön und verlangt zu viel ab.

Wir als Frontendler wollen ein gutes Produkt. Der Kunde will ein gutes Produkt. Warum machen wir nicht einfach ein gutes Produkt?

Der Frontend-Experte sollte direkt von Anfang an im Boot sitzen. Er ist der Einzige, der sagen kann, was geht und was besser nicht so sinnvoll ist. Der Designer macht weiterhin seinen Job aber eben ein wenig nach hinten gerückt und in enger Absprache mit dem Frontendler.

Zu allererst eine mobile Version, die inhaltlich und konzeptionell mit dem Kunden abgesprochen werden kann. Dies dient als Basis für die Medium sowie Large und eventuell noch weiteren Varianten. Alle haben schon Mobile-First gehört und die Vorteile liegen eigentlich auf der Hand und trotzdem geht es immernoch nicht in die Köpfe rein. Es ist halt einfacher etwas aufzublasen als einzudampfen.

Zurück zum Workflow

workflow

In der idealen Welt bauen wir statische Templates die in einem idealen Umfeld ideal heranwachsen können. Auf dieser Basis können Probleme schon frühzeitig mit dem Endkunden diskutiert und erläutert werden. Responsive Webdesign hat auf dem Weg zum Nutzer immer einen Haufen Probleme, die ein Photoshop-Dokument nicht vorhersehen kann. Auch der beste Frontend-Dude wird nicht immer sofort verstehen, welches die Probleme an welcher Stelle sind. Oft sieht man es erst beim anpacken und vieles auch erst beim einfügen von realistischen Texten. Ein perfektes gelayoutetes Design-Dokument mit “Max Mustermann” fliegt beim ersten Kontakt mit der Realität und einer real existierenden Person, wie die ehemalige Bundesjustizministerin “Sabine Leutheusser-Schnarrenberger” einem gerne mal um die Ohren.

Statische Dateien können einfacher getestet werden auf allen Devices als schon mit den Backend-verknoteten Informationen.

Ein simples Beispiel: im eingeloggten Zustand muss ein CSS/HTML-Modul für die Dokumenten-Ansicht geändert werden.

  • Auf allen Devices auf die Test-URL gehen.
  • Einloggen
  • Vielleicht noch ein Formular ausfüllen
  • bis Seite 3 kommen

Oder ihr habt statisches HTML, welches ihr beispielsweise über ein Sync-Tool gleichzeitig an all eure Testgeräte sendet und so immer im Blick habt was gerade passiert.

Ich weiß, was Effizienter ist, dass man so arbeiten kann, entscheidet sich aber viel weiter früher. Will man so arbeiten? Meine Antwortet lautet im Moment: Ja

Und das geht nur, wenn wir Frontend-Entwickler so früh wie möglich mit am Tisch sitzen. Schon in der Briefingphasem, um sowohl Kunden als auch Konzepter beraten zu können was geht und was besser keine gute Idee ist. Gehen tut ja immer alles, was richtig und wichtig ist, steht auf einem anderen Blatt.

Auf gehts. Wir haben spannende Zeiten! Lasst euch nicht ärgern. Wir sind die Guten.

comments powered by Disqus