praegnanz.de büro für intervernetzte medien

Unser Weblog

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

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