praegnanz.de büro für intervernetzte medien

Unser Weblog

Unser ComputerBase-Workflow

Gerrit, 30.03.2015

Als wir Anfang 2014 die erste Anfrage für ein Redesign von ComputerBase erhielten, waren wir zunächst einmal skeptisch. Auch wenn Philip und ich früher selbstverständlich Motherboards geschraubt, Jumper gesetzt und sogar casegemoddet haben, so ist unsere aktive PC-Bastelzeit doch schon einige Jahre her. Und die mutmaßliche Zielgruppe von ComputerBase schien uns – vor allem aufgrund des Designs – geradewegs aus dieser Zeit entgegenzuspringen. Ob unsere Vorstellungen eines modernen, universellen Webs dazu kompatibel sein würden?

CB

Die drei Gründer und Geschäftsführer konnten uns jedoch schnell davon überzeugen, dass sie voll und ganz hinter den aktuellen Entwicklungen im Web stehen, man würde das nur gerade nicht so sehr am Design erkennen. Und tatsächlich: Ein Blick in den Quelltext bestätigte, wie nah man am Puls der Entwicklungen war: HTML5-Semantik, CSS3-Techniken, WebP-Bildformat – alles pfeilschnell vom Server ausgeliefert – Hut ab! Unter der Haube war alles auf Stand, und wir wurden ganz offenbar nur in Sachen Design gebraucht, nicht aber für die Umsetzung in ein neues Markup. Doch wie fängt man so eine Zusammenarbeit an? Ist das nicht ein Paradebeispiel für einen völlig hippen Responsive Workflow? Durchaus, irgendwie. Auf unsere Weise eben!

Der Rahmen

Zunächst einmal waren uns seitens der Werbevermarktung gewisse Grenzen gesetzt. ComputerBase ist als kostenloses Angebot von der Werbung abhängig, muss deren Realitäten akzeptieren. Die ideale Maximalbreite der Website beträgt somit 1000 Pixel – Grund sind unter anderem sogenannte Fireplace-Ads, also Anzeigen, die sich oben, links und rechts komplett um die Website herumlegen. Doch auch unabhängig von Werbebannern sind mehr als 1280 Pixel natürlich keine gute Idee, wenn man nicht unendlich lange Zeilen oder alternativ einen Friedhof voller Seitenboxen anschauen möchte.

Die kleinste unterstützte Breite hingegen liegt bei klassischen 320px, und von dort aus geht es stufenlos bis hin zu den erwähnten 1000px. Eine stufenbasierte Lösung, die bestimmte Werbeformate noch homogener hätte integrieren können, wurde schnell wieder verworfen. Ebenso die bis dato verwendete separate Mobilversion mit zurechtgestutzten Inhalten. Ähnlich wie andere Newsangebote im Netz sollte es schon ein einheitliches HTML-Gerüst mit responsivem CSS sein – keine Version soll benachteiligt sein, universelles Webdesign eben.

Mobile First – naja, so ähnlich

Wie nähert man sich nun so einer Mammutaufgabe? Denn ComputerBase ist nicht eine einfache Firmenwebsite, sondern ein komplexes Konstrukt mit vielen unterschiedlichen Bereichen, Inhaltstypen und Sonderfällen, die sich seit 1999, dem Jahr der Gründung, angesammelt haben. Wir entschieden uns, das Design „von innen nach außen“ aufzubauen und mit dem Kernstück zu beginnen – der Newsauflistung nebst Thumbnail (welches am Anfang übrigens noch farbcodierte Icons waren). Diese Newsauflistung verträgt ca. 320–600 Pixel Breite und eignet sich somit sowohl als einspaltiges Element für Smartphones, aber auch als Hauptspalte auf breiteren Viewports.

Ausgehend von diesem Kernelement entwickelten wir das gesamte Drumherum und bauten Schritt für Schritt die äußeren Schichten auf, bis das grobe Layout für alle Geräte stand. Insbesondere die Desktop-Startseite folgt dabei dem „neuen“ Paradigma im Webdesign, welches bekanntlich weg geht von einer Hauptspalte und einer davon völlig unabhängigen Seitenleiste. Vielmehr ist das Layout nun in mehrere vertikal gestapelte Bereiche aufgeteilt, die jeweils ihren eigenen Haupt- und Nebenbereich haben, sowie von horizontalen Thumbnail-Teaserleisten unterbrochen werden.

CB6

Die Artikel-Einzelansicht bricht komplett mit ihrer Seitenleiste und ist auf allen Geräten einspaltig, was ihr Luft zum Atmen gibt und gerade bei längeren Testberichten hochwertig und reichhaltig wirkt. Quasi zum Nulltarif lösen wir dadurch auch das Problem mit den Marginalboxen auf Smartphones und Hochkant-Tablets, die man bei nachträglicher Responsivierung nur schwer in den Griff bekommt. Es gibt sie einfach nicht :-)

Der Workflow

Wir haben über ein Jahr an ComputerBase v6 gearbeitet, und das in ständigem Austausch mit der Geschäftsführung, die gleichzeitig als Projektleiter und HTML-Prototyper fungierte. Wir haben jedes noch so unbedeutende Mikroelement des neuen Designs erst besprochen, dann per Photoshop skizziert, manchmal auch per WebInspektor gebaut, wieder besprochen, wieder geprototyped, und dann letztlich in die echten HTML/CSS-Templates aufgenommen. Besonders gerne genommen, vor allem im späteren Verlauf des Projektes: Der kombinierte WebInspektor-Photoshop-Workflow, und der geht so:

Wir laden den aktuellen Stand des Projektes in den Browser, und verändern per WebInspektor die Parameter, die sich am schnellsten dort verändern lassen, z. B. die Gesamtbreite einer Newsliste mit entsprechend neu umbrechenden Zeilen. Dann nehmen wir davon einen Screenshot, laden es im Photoshop und machen dort solche Veränderungen, die sich mit einem Pixelprogramm schneller umsetzen lassen, wie das freie Verschieben von ganzen Layout-Blöcken. Auch wenn es unorthodox klingt, ist so ein gemischter Workflow letztlich die effizienteste Methode für uns gewesen.

(Natürlich hatten wir ursprünglich einen rein browser- und gitbasierten Workflow angestrebt, diesen aber im Laufe der Wochen immer mehr vernachlässigt. Letztlich war Steffen vom CB-Team für den finalen Code verantwortlich, und wir haben ihm über Mockups häppchenweise zugearbeitet.)

Die Kontroverse

Noch nie durften wir eine Website entwerfen, die so viele Leser hat wie ComputerBase, und die ihren Lesern auch so am Herzen liegt. Es tummelt sich eine äußerst aktive Community im Forum, die dort seit vielen Jahren einen Lebensraum gefunden hat. So etwas ist uns natürlich grundsätzlich nicht fremd. Die Vehemenz allerdings, mit der das neue Design nun auf Nichtgefallen stößt, erstaunt uns seit der ersten Sneak Preview Anfang des Monats jeden Tag aufs Neue. Man übertreibt nicht, wenn man behauptet, dass dem CB-Team und uns eine leidenschaftliche Wut entgegengebracht wird.

Viele der Meldungen sind absolut nachvollziehbar und aus der Perspektive der Stammleser auch berechtigt, manche Kommentare sind jedoch auch sehr unsachliche und emotionale Affektäußerungen. Man kann hier in Reinkultur beobachten, wie eine Marke, die sich aus Logo, Webdesign und Inhalt zusammensetzt, vermeintlich in den Besitz der Community übergegangen ist und nun droht, sich dieser wieder zu entfremden.

Insbesondere weil auch unsere kleine Agentur nun Ziel der verbalen Attacken ist, möchte ich noch ein paar Worte dazu verlieren. Auch wenn es viele Leser in der Aufregung nicht mitbekommen haben, ist das neue ComputerBase-Design keine Auftragsarbeit, die Anfang 2014 bestellt und März 2015 geliefert wurde. Es handelt sich vielmehr um eine extrem enge und inzwischen auch freundschaftliche Zusammenarbeit zwischen dem Gründerteam, welches ComputerBase seit 1999 mit Herzblut betreibt und unserer visuellen Weberfahrung, die bis ins Jahr 1996 zurückgeht. Stichworte wie „WordPress-Template“ und „Ich bau euch in 15 Minuten was Besseres“ sind also nicht angebracht und entlarven massive Unkenntnis der Materie.

ComputerBase ist thematisch seit einigen Jahren deutlich vielfältiger als es der erste Eindruck vermitteln mag: iPhone, AndroidWear, StartUps und Netzpolitik gehören genauso zum Repertoire wie die Klassiker Grafikkarten, First-Person-Shooter und CPU-Kühler. Unsere Aufgabe bestand nicht zuletzt darin, eine für alle Themenfelder angemessene visuelle Darstellung zu finden, und insbesondere neue Leser nicht durch das inzwischen veraltete Design abzuschrecken.

Nicht alle alteingesessenen CB-Leser werden diesen Relaunch mitgehen wollen, das machen die Kommentare deutlich. Doch wir zählen darauf, dass die ComputerBase-Themenvielfalt nun offener, leichtgewichtiger und professioneller in Szene gesetzt wird. Also: Wem eine unabhängige und ehrliche Technik-Berichterstattung am Herzen liegt, und wer sich designtechnisch im Jahr 2015 wohler fühlt als im Jahr 2003 – hier bitte klicken ;-)

Kommentare [26]

Die einzige richtige Richtung für Älter/Neuer-Pfeile (update)

Gerrit, 18.03.2015

sieht natürlich so aus wie bei uns im Blog und dies ist das mentale Modell dazu:

Update 19.3.2015, 8:30

Immer noch nicht überzeugt? Dann erklärt mal, wie ihr euch die Sache mit einer detaillierteren Paginierung vorstellt. Jetzt kommt mir nicht damit, dass dies ein völlig anderer Kontext ist. Ist es nämlich nicht! Im user-centric design ist die Leserichtung entscheidend, nicht ein komischer Zeitstrahl. Diese Zeitstrahl verläuft nämlich auf Blogs und Newsbereichen primär mal von unten nach oben*, ist also eh schon falsch anders.

* Es hat sich als Paradigma durchgesetzt, dass in persönlichen Chats und Messengern, wo direkte Konversationen statt newsähnliche Meldungen durchlaufen, die Zeitachse von oben nach unten verläuft. Wahrscheinlich aus historischen Usenet-Gründen oder so.

Kommentare [19]

Websites sind teurer geworden

Gerrit, 16.03.2015

In den letzten Monaten kam es einige Male zu einer Situation, die ich vorher kaum erlebt hatte: Festpreisangebote für Websites, die wir sorgfältig kalkuliert hatten, wurden als zu teuer abgelehnt, und wir kamen mit den potenziellen Neukundinnen nicht ins Geschäft. Keine tragische Sache, aber für mich durchaus etwas Neues. Bisher war es so, dass die Firmen, welche sich an uns wandten, eine recht realistische Vorstellung von unserem Aufwand hatten. Doch in den letzten Jahren hat sich tatsächlich einiges verändert, und auch wir haben einige Zeit gebraucht, um unsere eigene Arbeitsweise neu zu bewerten und zu kalkulieren.


Legendäres Symboldbild, © by Zing Design, Neuseeland

Was war passiert?

Vor ca. zwei Jahren haben wir beschlossen, dass wir in Zukunft keine neuen Websites mehr ohne responsiven Ansatz anbieten würden. Zum einen hielten wir es für eine Selbstverständlichkeit, über die man in aufgeklärten Kreisen gar nicht mehr diskutieren müsste. Zum anderen wollten wir unsere weniger aufgeklärten Kunden schützen vor einer Website, die bereits zum Launchzeitpunkt veraltet sein würde und kurze Zeit später sowieso nachgerüstet werden müsste. Dieses sogenannte Responsive Retrofitting ist zwar möglich, aber meist entwürdigend, qualitativ minderwertig und kostet immer 50–100% mehr, als man vorher geschätzt hatte. Darüber hinaus gehört zu einer echten Responsivität inzwischen auch die Benutzung von »Retina«-Elementen, wo immer es möglich ist – also hochaufgelöste fotografische Motive, sowie vektorbasierte grafische Elemente. Gerade letztere verlangen in vielen Fällen einen gewissen technischen Aufwand, wenn sie klug und ressourcenschonend eingebunden und angezeigt werden sollen.

Doch eine Website muss heute nicht nur responsive sein, sondern sie sollte auch den aktuellen Designparadigmen entsprechen und sich idealerweise positiv vom Feld der Mitbewerberinnen abheben; Die Menschen sind ja nicht blind und erkennen die emotionale Kraft von hochwertigen, großformatigen Einstiegsbildern oder gar Videos (siehe airbnb). Sie sind fasziniert von subtilen Animationen, die per Scrollevent getriggert werden (siehe iPhone-6-Produktseite). Aber in erster Linie wollen die meisten Kunden keine Abstriche machen, was die Reichhaltigkeit der inhaltlichen Struktur angeht. Die Sitemap-Entwürfe, die wir bekommen, strotzen häufig vor Navigationspunkten und Ebenen, so dass man mit den responsiven Blick bereits innerlich zu Schwitzen beginnt. Denn es gibt leider kaum gut erprobte Designpatterns für Websites, die in traditioneller Desktop-Denke geplant sind, aber dann mit Mobile-First-Paradigma umgesetzt werden sollen. Und man macht sich keine Vorstellung davon, wie hartnäckig und beratungsresistent bisweilen die Kundinnen sein können, und wie wenig sie sich immer noch für die mobile Benutzung interessieren.

Hohe Komplexität der Inhaltsstruktur auf der einen Seite, ein offenes, modernes, leichtgewichtiges und superflexibel adaptives Layout auf der anderen Seite, das klingt entweder nach viel Aufwand oder nach halbgaren Kompromissen. Unser Ziel ist es, letztere zu vermeiden und lieber den harten, ehrlichen Weg einzuschlagen. Von daher trauen wir uns zunehmend, mit höheren Aufwandsschätzungen zu jonglieren. Das ist absolut keine Profitgier und auch keine Unverschämtheit, sondern schlicht die Folge unserer Erfahrungswerte, was individuelles Webdesign heute für den Dienstleister bedeutet. Insbesondere, wenn ein Kunde sich bereits im Vorfeld als sehr gestaltungsfreudig, meinungsstark und detailverliebt erweist.

Wer mit uns eine Website plant, bei der individuelle Ideen und spezielle Wünsche – seien sie funktional oder visuell – eine große Rolle spielen, der muss sich darauf gefasst machen, dass wir diese Wünsche ernst nehmen, aufgreifen und eine mediengerechte Umsetzung für die Realität des Jahres 2015+ anpeilen, statt sie einfach 1:1 für einen 1.280px-Non-Retina-Screen hinzupfuschen. In vielen Fällen bedeutet dies eine Erhöhung im Vergleich zu einem 2010er-Budget. Die Webwelt ist komplexer geworden, und unsere Dienstleitung mit ihr. Die Inflation kommt natürlich auch noch dazu.

Die preiswerte Alternative ist im Übrigen richtig gut geworden – darüber berichtet der Schwesterartikel zu diesem Beitrag. Damit können wir freilich nicht konkurrieren, denn wir stehen nun einmal für die traditionell-handwerkliche Herangehensweise, bei der das Design den vorhandenen Inhalt aufgreift und hochwertig in Szene setzt, und bei der Sonderwünsche und clevere Ideen mit Sorgfalt erfüllt werden können – insbesondere, wenn sie frisch und unkonventionell quergedacht sind. Um ein technisches Problem zu lösen, müssen wir nicht erst auf ein Theme-Update warten oder eine Supportmail an Jimdo schreiben. Wir kennen unseren Code und können schnell auf Probleme und Wünsche reagieren – langjährige praegnanz.de-Kunden heben das immer wieder lobend hervor.

Die schnelle Baukastenlösung ist verlockend, weil sie absolut real und auch legitim ist. Doch sehr häufig stellt sich erst mitten im laufenden Projekt heraus, dass es eben doch die individuellen Wünsche gibt – von kleinen visuellen Anpassungen bis hin zu komplizierten Interaktionswelten. Entweder geht ein Auftraggeber davon aus, dass »das doch sicher mit abgedeckt« sei, oder er wusste zum Zeitpunkt der Beauftragung selber noch nichts von diesem Wunsch. Und genau an diesem Punkt fällt das Baukastensystem oftmals in sich zusammen, denn Sonderwünsche sind eine komplizierte Angelegenheit, wenn die Projektinfrastruktur grundsätzlich auf dem Zusammenstecken fertiger Teile basiert. Manche Kundinnen sind bereit, diese Einschränkung hinzunehmen und mit dem zu leben, was irgendwie alle haben. Glücklich schätzen kann sich jedoch die Kundin, die am Anfang etwas mehr Geld in die Hand genommen hat, um gleich eine maßgeschneiderte, aber zugleich skalierbare und flexible Basis zu beauftragen.

Man mag argumentieren, dass wir uns mit den vorangegangenen Ausführungen als hochnäsige Edelschmiede aufstellen, die den Kontakt zum Jedermann-Web verloren hat, doch wir sehen es anders: Jeder kann heute eine professionell wirkende Website haben und muss dafür nur noch wenig Geld ausgeben, und diesen Umstand wollen wir gar nicht negativ bewerten! Doch sobald die Wünsche an die Gestaltung des Auftritts individueller werden, steigt der Aufwand und damit der Preis an. Leider tut er dies jedoch nicht linear, sondern eher nach dem 80/20-Prinzip, wenn nicht sogar exponentiell. Wir helfen gerne dabei, die tatsächlichen Kosten zu kalkulieren und runde Pakete zu schnüren, die den Ansprüchen unserer Kundinnen gerecht werden, und die vor allem ausbaufähig und flexibel sind für zukünftige Entwicklungen. Wenn Ihnen das gefällt, freuen wir uns selbstredend auf Ihren Anruf oder Ihre Mail :-)

Disclaimer: Wenn wir von »indviduellen Lösungen« sprechen, meinen wir damit nicht etwa hauseigene Content-Management-Systeme oder gar Website-Entwicklung auf App-Framework-Basis. Wie jeder weiß, lieben wir unsere Open-Source-CMSe! Nur dass uns die Arbeit mit eher minimalistischen Systemen wie Kirby und ProcessWire, sowie eigenen Themes für Drupal und WordPress deutlich weniger Bauchschmerzen bereitet als das Herumdoktern an fertigen Theme-Systemen oder gar SaaS-Lösungen.

Kommentare [4]

Websites sind billiger geworden

Gerrit, 16.03.2015

Standards haben im Web einen guten Ruf, und das absolut zu Recht. Da muss man nicht einmal an den Siegenszug der Web-Standards-Bewegung erinnern. Best Practices, gelernte Bedienungskonzepte und narrensichere Architektur begleiten schon immer den Arbeitsalltag von Webdesignerinnen und können von daher kaum genug gelobt werden! Es gibt im modernen Webdesign ein buntes und abwechslungsreiches Set an bewährten und millionenfach erprobten Designpatterns, mit denen man vorzüglich bedienbare, emotionale und technisch blitzsaubere Websites bauen kann. Schaut man sich erfolgreiche Netzauftritte an, lernt man schnell, dass übermäßige Innovation und Wow-Faktor letztlich nur störend sind.

Niemand will im Jahr 2015 noch Killer-Websites oder individuell ausgedachte Usability-Höllen. Vielmehr setzt man allerortens auf das, was der User kennt. Und diese Taktik ist absolut nichts Schlechtes. Denn nur, indem man das Webdesign in den Hintergrund treten lässt, kann sich die Nutzerin auf die Inhalte konzentrieren, und auf die kommt es schließlich an.

Was wir also heute benötigen, ist ein modulares Baukasten-System, mit dem man erfolgreiche Designpatterns aneinanderreihen kann, um diese mit seinen Inhalten – seien es Texte, Fotos oder Videos – zu befüllen. Ob hierbei Inhalt oder Designbausteine zuerst da sind, spielt kaum eine Rolle. Im Zuge eines agilen Workflows kann man von allen Seiten eines Projektes beginnen und aufeinander zuarbeiten, bis sich am Ende alles zu einem runden Nichts stimmigen Ganzen vereinigt hat.


Der Igel ist klug und gewinnt mit Bewährtem: seinem Aufenthaltsort!

Glücklicherweise sind die Tools für unsere modularen Baukästen bereits da. Sie sind beinahe kostenfrei, und sie benötigen kaum noch Einmischung durch einen individuell arbeitenden Designer. Die allgegenwärtigen Werkzeuge heißen Bootstrap, Divi, Jimdo und The Grid, und sie stehen stellvertretend für verschiedene Stufen der Designstandardisierung im Web.

  • Das Bootstrap-Framework wurde als Tool zum schnellen Prototyping gestartet, wird aber heute von vielen Backend-Programmiererinnen verwendet, um ohne Hilfe eines Frontendlers oder gar Designers zu raschen und gut aussehenden Nutzeroberflächen zu gelangen. Es versteht sich von selbst, dass sich tonnenweise Bootstraps in produktiver Umgebung befinden. Der prototypische Charakter verschwindet nämlich schnell, wenn das Projektbudget langsam zu Neige geht.
  • Divi ist das ausgefeilteste WordPress-Theme, das es für Geld zu kaufen gibt. Es enthält nahezu sämtliche Webdesign-Patterns der letzten fünf Jahre, klärt uns über die Bedeutung des Wortes Blurb auf, ist ultra-modular und anpassbar, selbstverständlich responsiv und sieht einfach immer gut aus. Divi nutzt WordPress primär als Basis-Framework und installiert quasi ein zusätzliches CMS im CMS, welches nach eigenen Regeln funktioniert und besser und sauberer wirkt als das, was WordPress im nackten Zustand zu bieten hat, und der eingebaute Page Builder macht das alles sogar per Drag & Drop verfügbar.
  • Auch mit Jimdo wird der zukünftigen Website-Betreiberin 90% des Aufwandes abgenommen, den sie mit manueller Erstellung gehabt hätte. Es ist die alte Idee des 1&1-Homepage-Builders, aber auf Steroiden, und in gut. In 5 Minuten kommt man vom Entschluss zur fertigen Website. Okay, ein paar Inhalte sollte man noch eintippen, aber im Grunde ist es das. Professionelle Seitenlayouts und – natürlich – Patterns sind dabei, alles responsiv. Eine App zur nativen iOS-Webbefüllung sowieso, es ist wie ein Divi-Theme, nur dass ich noch nicht einmal WordPress selber aufsetzen muss.
  • Der endgültige Nirwana-Zustand ist aber erst mit The Grid erreicht. Ein System, das per Künstlicher Intelligenz die Website von ganz automatisch erstellen wird. Ich stelle mir das so vor, dass man einen Ordner mit ungeordneten Bildern und Texten rauflädt, und eine fertige, perfekt gestaltete und auf allen Geräten stimmige Website zurück erhält. Was genau es wirklich kann, muss noch getestet werden, aber die Erwartungen sind hoch.
  • Bonustrack: Google Fonts ist eine der wichtigsten Ressourcen, wenn es um Webtypografie in der realen Welt geht. Die 600 freien Schriften aus dem allgegenwärtigen Google-Katalog sind eine Art Grundversorgung, vergleichbar mit Strom aus der Steckdose oder Trinkwasser aus dem Hahn. Kaum ein moderner Homepage-Baukasten, der ohne die extern gehostete Unterstützung von Open Sans und Co. auskommt.

Fassen wir zusammen: Wenn ich mit all diesen modernen Tools und den millionenfach bewährten Designpatterns großartige, moderne Websites bauen kann, warum benötige ich noch die Hilfe eines Webdesign-Unternehmens, welches darauf besteht, jedes Projekt von vorne bis hinten neu zu programmieren? Ist das nicht eine Einstellung von gestern bis vorgestern? Für alles gibt es heute Frameworks und Module. Warum soll ausgerechnet im Frontend das Rad jedesmal neu erfunden werden, und das für teures Geld? Websites im Jahr 2015 müssen nur noch in Sachen Inhalt und Informationsarchitektur individuell geplant werden. Design und Technik kommen von der Stange, und sind mit den oben genannten Tools sicherlich besser als alles, was das Jahr 2010 jemals hervorgebracht hat.

Wenn Sie beim Lesen dieser Zeilen heftig mit dem Kopf genickt haben, dann sind wir möglicherweise nicht die richtige Agentur für Sie. Sollten Sie aber leise Zweifel an der Argumentation haben, dann lesen Sie gerne hier weiter.

Dieser Beitrag wurde zum Teil inspiriert durch diesen Blogkommentar von praegnanz.de-Leser Jürgen.

Kommentare

Aufrüsten gegen den Minderwertigkeits­komplex

Gerrit, 05.02.2015

Früher war alles besser war Webdesigner noch ein recht gut abgegrenzter, einzelner Beruf, den begeisterungsfähige, technikaffine und geschmackssichere Menschen wunderbar erlernen und ausüben konnten. Ob alleine oder in einer Agentur spielte dabei kaum eine Rolle. Manchmal erhielt man Unterstützung von einem klassischen Grafiker, manchmal konnte eine Webmasterin im Projekt Hilfestellung leisten. 90% der benötigten Arbeiten im Kontext „Website“ konnten von einer Person geleistet werden.

Seit Mitte der Nullerjahre gab es dann verstärkt Webapplikationen mit Serverkomponente , und seit diesem Jahrzehnt werden diese immer stärker mit clientseitiger Logik und Dynamik ausgestattet, bis hin zu reinen Frontend-Apps. Dazu kommt eine Vielfalt an Endgeräten und Nutzungssituationen und – schwupps – ist der Beruf des Webdesigners nicht mehr so klar abgegrenzt wie früher! Es wird spezialisiert wie nichts Gutes, und viele Kolleginnen, die sich früher eventuell allroundmäßig „Webdesignerin“ genannt hätten, sind heute Frontend-Entwicklerinnen. Als solche haben sie nur noch am Rande mit visueller Gestaltung zu tun, und auch das Wissen über die Serverseite – sprich: Datenbanken, CMSe und Serverperformance – überlassen sie anderen Experten.

Nun stehen sie also da, die Frontend-Entwickler, und suchen nach einer neuen Identität für sich und ihre Tätigkeit, und ein bisschen nackt fühlt man sich ja schon. Man kann auf sich alleine gestellt kaum noch eine halbwegs gescheite Website, geschweige denn eine Applikation bauen, dafür braucht es ein Team! Und wenn man sich die einzigen Frontend-Sprachen anguckt, die man zur Verfügung hat, sind diese konzeptionell 20 Jahre alt, nicht mehr sehr praxisnah, zu theoretisch und wirken nicht einmal sonderlich professionell. Blöd! Da hat man den Anspruch, ein richtiger Programmierer zu sein, will sauberen Code schreiben, um auf hohem Niveau für das Frontend zu entwickeln, und womit muss man klarkommen? HTML, CSS und JavaScript? Ernsthaft? Die gleiche Technologie, mit der seit 1997 hässliche Websiten für den Netscape Navigator gebaut werden?

Wahrlich: Die nackten Webstandard-Technologien müssen für junge, gut ausgebildete Informatiker eine echte Zumutung sein! So hatten sie sich das nicht vorgestellt, dass alle richtigen Programmierer über sie lachen und mit dem Finger auf sie zeigen! Richtige Programmierer schreiben C#, Objective-C oder Ruby, sie haben mächtige Entwicklungsumgebungen, feste Typen, Runtimes, VMs. Sie vergleichen Compilergeschwindigkeiten und beobachten die Effizienz von Garbage-Collectoren. Sie deployen auf Devices und testen automatisiert, ob ihre Apps zu häufig crashen. Das sind die Freuden, die das native Programmieren ausmachen! Und natürlich die Tatsache, dass man – zumindest gefühlt – im Bereich der nativen Anwendungen mehr Geld verdienen kann.

Meine steile These ist, dass sich aus dem oben beschriebenen Missverhältnis in den letzten vier bis fünf Jahren eine Art Gegenbewegung gebildet hat, die Frontend-Entwickler weltweit zusammengebracht hat, um gegen die gefühlte Verniedlichung ihres Berufes anzukämpfen. Um gemeinsam die Kränkung wieder wettzumachen. Um die Frontend-Entwicklerin professioneller werden, oder zumindest wirken zu lassen.

Das Resultat dieser – teilweise neidgetriebenen – Anstrengungen ist die Explosion von Meta-Programmierung im Frontend-Bereich. Man hat das Gefühl, dass sich heute fast niemand mehr herablässt, noch normales HTML, CSS und JavaScript zu schreiben. Alles wird kompiliert: HAML zu HTML, SASS zu CSS, CoffeeScript zu JavaScript. Um den ganzen Meta-Code wieder zusammenzusetzen, benötigt man neben Node.js auch einen Package-Manager in Form von npm, ein Build-Tool wie Grunt, Gulp oder Broccoli, sowie groteske Mengen an Node-Plugins für die genannten Build-Tools. Doch als ob wir noch nicht genug Abstraktionsstufen hätten, kommen Tools wie Bower und Yeoman noch obendrauf und automatisieren das automatisierte Automatisieren von automatischem Frontend-Code, der aber in weiten Teilen sowieso „Out of the Box“ von Bootstrap geliefert wird. Und wenn man im Jahre des Herrn 2015 ernsthaft einen Job als Frontend-Dev haben möchte, sollte man ganz schnell noch ein paar Brocken Backbone, React.js und AngularJS lernen, sonst wird das eher nichts.

Mal Spaß beiseite: Viele der genannten Tools sind natürlich sinnvoll und können Zeit sparen, und es ist nicht cool, sich über ihren Einsatz lustig zu machen. Dennoch macht sich seit einiger Zeit bei mir das Gefühl breit, dass das Waffenarsenal der Frontend-Devs mehr und mehr zum Selbstzweck wird, sowie zur Rechtfertigung, dass man eben doch mithalten kann mit den echten Programmieren und ihren fetten IDEs und Prozessen. Dass man automatisierte Toolchains und Deployment-Techniken beherrscht. Und dass man damit ein genauso ernstzunehmender Programmierer sein kann.

Mag alles sein. Ein bisschen Kindergarten scheint mir aber ebenfalls im Spiel zu sein. Kaum eine Woche vergeht, ohne dass man seine Toolchain grundlegend aufrüsten, oder eventuell sogar um eine weitere Automatisierungs- oder Abstraktionsschicht ergänzen muss, um ständig up to date zu bleiben. Ich frage mich, ob die jeweiligen Projekte tatsächlich so umfangreich und hochkomplex sind, oder ob nicht auch einfach ein latenter Minderwertigkeitskomplex verantwortlich ist, der ganz selbstverständlich auftritt, wenn man an einfache und primitive Techniken gefesselt ist, wie sie HTML, CSS und JavaScript in Vergleich zu kompilierten Sprachen darstellen.

Ich für meinen Teil möchte sagen – auch im Interesse einer einfachen und nachvollziehbaren Arbeitsweise: Behaltet die Verhältnismäßigkeit im Auge! Könnt ihr den Einsatz all eurer Tools wirklich gut begründen? Oder ist es nur Angeberei und behindert euch und eure Kollegen bzw. Nachfolger? Verbringt Ihr mehr Zeit beim Feintunen eures Gruntfiles als mit dem Entwurf einer eleganten und gut dokumentierten Programmarchitektur? Ein bisschen weniger Frickeln und ein bisschen mehr Pragmatismus tut manchmal auch ganz gut. Vielen Dank, der alte Mann hat fertig.

Kommentare [25]