praegnanz.de büro für intervernetzte medien

Unser Weblog

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 [26]

Mein kleiner 2015er WordPress-Rant

Gerrit, 23.01.2015

Beginnen wir mit steilen Thesen: WordPress ist schwierig, obwohl es einfach erscheint. WordPress ist für Standardwebsites, obwohl es alle Arten von Websites betreiben kann. WordPress ist eine kurzsichtige CMS-Wahl, obwohl es Weltmarktführer ist.

In letzter Zeit verdichten sich bei Kunden, Kollegen und Freunden die Hinweise, dass es vielleicht doch keine so gute Idee war, komplett auf WordPress zu setzen, als es um die Umsetzung eines neuen Webprojektes ging. Ich will versuchen zu erklären, warum das so ist.

Seit zehn Jahren ist WordPress nun dabei, sich von einer kleinen Bloggingsoftware zum weltweit meistgenutzten Website-Baukasten zu entwickeln. Diese Entwicklung ist weitestgehend abgeschlossen, auch wenn noch viel Legacy-Code und eine ganze Reihe von Paradigmen an die gute alte Blogging-Zeit erinnert. Alle Funktionen, die WordPress zu einem „großen“ CMS machten, stecken allerdings in Themes und Plugins. Grundsätzlich ist natürlich gegen einen relativ schlanken Core und relativ mächtige Plugins nichts einzuwenden. Das fundamentale Problem ist jedoch die verfluchte Vielfalt und die Konkurrenz innerhalb der Plugin-Szene. Ich habe aufgehört zu zählen, wieviele Plugins es für die Verwaltung von Custom Post Types und Custom Fields gibt. Derzeit scheinen CTP UI und ACF brauchbare Plugins zu sein, aber wer weiß schon, wann diese wieder explodieren oder neue WP-Versionen nicht mehr unterstützen? Ihr wisst, was ich meine. Man kann ja froh sein, dass WordPress mit den Schnittstellen für Custom Post Types, Custom Fields und Custom Taxonomies eine Art Standard innerhalb des System geschaffen hat, doch dieser Standard ist so rudimentär, dass alle entsprechenden Plugins trotzdem zusätzliche Schichten an Logik und Daten ablegen müssen, um halbwegs benutzerfreundlich zu sein.

Natürlich besteht bei allen CMSen das Problem, dass zu viel festgelegte Funktionalität im Core schädlich ist, und dass man auf Plugins angewiesen ist. Doch in den meisten Fällen existieren für die wichtigsten und am häufigsten benötigten Anwendungsfälle auch gewisse „große“ Standardplugins, welche eine hohe Qualität aufweisen, oftmals auch vom Core-Team entwickelt werden und von daher zu allem kompatibel sind, und auf jeden Fall weiterentwickelt werden, wenn sie nicht – wie im Falle von Drupal – schlussendlich in den Core wandern. Eine gewisse Standardisierung der Core-Schnittstellen schafft Verlässlichkeit und Orientierung bei den Plugin-Entwicklern und Vertrauen bei den Benutzern, weil die Wahrscheinlichkeit, dass Plugin A mit Plugin B gut zusammenarbeitet, hoch ist.

Bei WordPress hat sich dieses Kompatibilitätsproblem zu einem absurden Schauspiel entwickelt. Plugins machen damit Werbung, dass sie zu bestimmten, populären Themes kompatibel sind, Plugin A setzt Plugin B voraus, aber warnt davor, Plugin C gleichzeitig installiert zu haben. Magazin-Themes empfehlen den Einsatz eines bestimmten Plugins, weil sonst bestimmte Features nicht funktionieren würden, kommen aber selbst mit 3 Tonnen Plugin-ähnlichem Code daher, so dass inzwischen die Unterscheidung zwischen Theme und Plugin kaum mehr gegeben ist. Es ist ein Dschungel.

Und weil sowohl Themes als auch Plugins so pupseinfach zu installieren ist, macht es jeder Amateur ohne Hemmungen, und kombiniert munter Dinge, die sich überkreuzen und gegenseitig kaputt machen. Ansprüche an das Design, die Ladezeiten, ein elegantes Markup oder zumindest halbwegs aufgeräumten Code sind dabei schon lange nicht mehr vorhanden.

WordPress also nur ein populäres Amateur-System? Ja und nein. Inzwischen bin ich der Meinung, dass es genau zwei verschiedene, valide Anwendungsfälle gibt:

1. Die reine Laiennutzung: Fertiges Theme installieren und mit Bordmitteln anpassen, einige Plugins dazu klicken, die nicht allzu krasse Dinge anstellen, fertig. Bei dieser Nutzungsart ist es sehr wichtig, dass man keine zu hohen Ansprüche hat, was einerseits die Ästhetik, andererseits die Machbarkeit bestimmter Funktionen angeht. Wer individuelle Wünsche hat, die über das normale Standardblog oder die kleine Standardwebsite hinausgehen, findet entweder ein Plugin, welches sofort perfekt passt, oder lässt es sein.

2. Die reine Profinutzung: Ein eigenes Theme wird von Grund auf neu aufgebaut. Jedes Plugin wird sorgfältig auf Professionalität, Langlebigkeit, Stabilität und Kompatibilität geprüft. Im Zweifel lieber selber im Theme die gewünschte Funktionalität programmieren. Jeder Wunsch nach individuellen Funktionen wird zweimal in Frage gestellt und dem Kunden möglichst ausgeredet. Das Versprechen einer funktionierende Website erlischt, sobald Kunden eigenständig Plugins installieren (Ja, damit sind vor allem SEO- und Social-Media-Button-Plugins gemeint!).

Zwischen diesen Extremen gibt es nicht viel. Wir haben sehr schlechte Erfahrungen gemacht mit dem Anpassen von fertigen Themes, trotz Childtheme-Technik, insbesondere bei responsiven Themes. Die Möglichkeit, „schnell mal eben“ gigantische Funktionsumfänge in Form von praktischen Plugins herbeizuzaubern, ist verführerisch, doch zu welchem Preis? Die Kunden wollen immer mehr von der Sorte, werden falsch erzogen!

Ach, wenn das so einfach ist mit den eigenen Widget-Bereichen, dann will ich gleich sechs Stück haben. Wissen Sie was? Ich installier mir einfach ein Plugin und knall mir gleich 14 Widgetbereiche rein!

Es ist diese verführerische Illusion, dass alles so einfach ist. Die Themes, Plugins und Widgets greifen doch alle ineinander, ergänzen sich, lassen sich sogar anpassen, und alles ohne Code! Was muss dann erst eine richtige, erfahrene Webagentur aus dem System herausholen können? Doch leider arbeiten erfahrene Webagenturen meist ein bisschen anders, verlassen sich ungern auf Baukastenmodule mit unbekanntem Code und wollen alles unter Kontrolle haben beziehungsweise auf eine stabile CMS-Codebasis setzen, deren Paradigmen und Schnittstellen gut dokumentiert und zukunftsicher sind. Nur so kann man Webprojekte umsetzen, die mit den Wünschen der Kunden mitwachsen, ohne irgendwann die Grätsche zu machen.

Uns fällt es immer schwerer, im vollen Bewusstsein neue Projekte mit WordPress anzufangen. Zu oft ahnen wir, dass die Kunden immer mehr wollen, wenn sie einmal das Schaufenster mit den Süßigkeiten gesehen haben, oder dass sie mit den besprochenen, minimalem Anpassungen an das Standard-Theme nicht zufrieden sind. Doch ganz ehrlich: Meist sind es wir selber, die keine Lust auf den Stress haben, die ganze Arbeit von Anwendungsfall 2 für das Budget aus Anwendungfall 1 zu erledigen.

Kommentare [19]

Freefont-Advent 24/24 – Source Sans/Serif/Code Pro

Gerrit, 24.12.2014

Die Source-Schriftsippe von Adobe schließt diesen kleinen Adventskalender ab, mit dem ich einen Überblick bieten wollte, was heutzutage mit kostenlosen Schriften aus dem Netz so alles geht. Im Vergleich zu 2004, als ich unter anderem mit der Artikelserie Die Freie Schrift der Woche dieses Blog populär machen konnte, hat sich das Angebot unfassbar weiterentwickelt, in Quantität und auch Qualität. Open-Source-Schriften sind eine echte Erfolgsstory des Internet, denn nur über digitale Vernetzung, weltweite Verbreitung und die Chance auf Ruhm und Ehre wird ein Anreiz für Schriftentwerfer geschaffen, ihre Babys kostenlos für die Gestalter dieser Welt herausgeben. Dass die meisten freien Schriften ihren kommerziellen Verwandten trotzdem noch unterlegen sind, liegt dabei in der Natur der Sache und bekräftigt, dass es für beide Lizenzmodelle Anwendungsfälle gibt. (Siehe dazu auch mein Essay Freie Schriften – Anspruch und Wirklichkeit von 2011.)

Zurück zur Source-Famile und ihrem Herausgeber Adobe. Die Source Sans Pro erschien im Sommer 2012 und war von Anfang als echte Open-Source-Schrift geplant, die aber den gleichen Qualitätsmaßstäben unterworfen sein sollte wie die kommerziellen Adobe-Schriften, beispielsweise Warnock oder Chaparral. Dabei erbt die Source Sans einige Eigenschaften der klassischen amerikanischen Gothic-Schriften, ist dabei jedoch insgesamt offener und humanistischer. Wie auch die Open Sans von Google ist sie als Webfont derzeit extrem populär, vor allem weil sie so universell einsetzbar ist. Sie hat sich zu einer Art Standardschrift entwickelt und könnte von daher als „Neue Arial“ bezeichnet werden. Wenn einem nichts charakteristischeres einfällt, greift man halt auf die Source Sans zurück, das ist immer noch besser als gar keinen Webfont zu verwenden. Klingt tragisch, ist aber wohl pragmatische Realität :-)

Ein paar Monate nach der Source Sans erschien die dazu passende Monospace-Variante „Source Code“, und erst diesen Sommer folgte dann die „Source Serif“. Letztere leider noch ohne kursiven Schnitt – aber das kann ja noch kommen.

Mit der Source-Sippe hat man eine professionelle und nach allen Maßstäben der Kunst gestaltete Schrift an der Hand, die den meisten typografischen Herausforderungen gewachsen ist. Auch hier gilt natürlich die Warnung, dass man keine Originalitätspreise gewinnen wird. Aber welche wahrhaft erfolgreiche Schrift von Weltformat konnte das jemals von sich behaupten? Es sind die subtilen Details und die perfekt abgestimmten, immer wieder aufs neue feinjustierten Formen, die aus einer „ganz netten“ eine „ganz große“ Schrift machen. Die Source ist schon jetzt ein Klassiker, der die typografische (Netz-)Landschaft geprägt hat und weiter prägen wird!

In diesem Sinne: Frohe Weihnachten allen LeserInnen, KundInnen und FreundInnen!

Kommentare [4]

Freefont-Advent 23/24 – Comic Jens

Gerrit, 23.12.2014

Das hat uns gerade noch gefehlt! Die Comic Jens ist die Antwort des Berliner Fontengineers Jens Kutílek auf die populäre Unfall-Systemschrift von Microsoft. Klingt zunächst mal nicht spektakulär, ist es auch nicht wirklich, aber dennoch: Man muss sie einfach mögen! Die Comic Jens kommt nämlich nicht nur mit einer für den Laien kaum unterscheidbaren Formensprache, ist aber der zu lange in der Sonne gelegenen Originalschrift in vielerlei Hinsicht haushoch überlegen. Stichwort „alternative Glyphen“ und „Ligaturen“. Wie es sich eigentlich für eine Handschrift-Imitation gehört, gibt es nämlich Abwechslung bei den Buchstabenformen, je nach Kontext – im oberen Beispiel schön am kleinen e zu erkennen.

Richtig schön ist das alles immer noch nicht, aber ein Stück weit erträglicher, oder?

Kommentare [1]

Freefont-Advent 22/24 – Exo 2

Gerrit, 22.12.2014

Die Exo 2 ist eine überarbeitete und in kleinen Schriftgraden besser lesbare Version der kaum älteren Exo. Diese Schrift hat eine interessante Geschichte hinter sich. Ursprünglich 2009 als studentisches Projekt von Natanael Gama angefangen, konnte dieser im Jahr 2011 über Kickstarter 7.500 Dollar einsammeln, um den Entwurf in Ruhe als komplette Open-Source-Schrift auszubauen und unter anderem bei Google Fonts unterzubringen. Zur Weihnachtszeit 2013 – knapp 2 Jahre nach der Erstveröffentlichung folgte dann bereits die verbesserte Version 2.

Die Exo Sans ist als kubische Groteskschrift gleichermaßen ein Fest für Freunde der Science-Fiction und der dänischen Schriftkultur (wir erinnern uns). Sie steht in der Tradition von Eurostile/Microgramma und Klavika, kommt sehr schlicht rüber, hat aber einige spannungsreiche Details zu bieten, die sie vor der visuellen Eintönigkeit einer komplett konstruierten Schrift rettet. Sie ist wirklich schick und schafft den Spagat zwischen reiner Headlineschrift und (eingeschränkter) Mengensatztauglichkeit. Exo ist nur auf den ersten Blick Massenware, und bietet mit den vollen 9 Fetten in regular und italic auch das ganze Programm an Abstufung, das man für feingeschliffene Online- und Offlinetypografie benötigt.

Kommentare