Funktion und Design

Typischerweise sind UX Design und Programmierung arbeitsteilig getrennt. Das geht so weit, dass sogar Backend- und Frontendprogrammierer für den kleinsten Button erst mal ein Meeting abhalten müssen, damit das gewünschte HTML Element überhaupt ausgegeben wird, um es dann per CSS zu stylen. Natürlich erst nachdem der Designer das nette Bildchen dazu geliefert hat ;-) Für diese Arbeitsteilung gibt es gute organisatorische Gründe. Aber das erzeugt auch viel Reibungsverluste. Typischer O-Ton mancher Backendentwickler: "Oh Mann, ich hasse HTML".

Ich liebe HTML

Das ist immer noch die einfachste Möglichkeit, Informationen auf standardisiertem Weg einer maximalen Zielgruppe bereitzustellen. Meine Stärke ist, dass ich alle Teilprozesse aus einer Hand abbilden kann. Vom UX Design über die serverseitige Konzeption und Programmierung von Datenbankstruktur und dynamischer Code- und Daten-Generierung bis hin zum CSS-Styling und der Programmierung der Benutzeroberfläche und Geschäftslogik mit JavaScript und Frameworks.

Kurz gesagt: wenn ich für die UX ein Element benötige, kann ich es von vorne bis hinten selbst erstellen und das gewünschte Verhalten programmieren. Der Weg von den serverseitigen Daten zum Client bis zum gerenderten DOM Element und wieder zurück ist für mich vollkommen transparent. Genaugenommen habe ich schon mehrere Web Content Management Systeme in unterschiedlichen Sprachen (VBScript, ASP.NET/C#, PHP) von Grund auf selbst entwickelt, um genau diese Pipeline nach eigenen Wünschen umzusetzen.

HTML / CSS responsive Web-Layouts

Die gerne genutzten Bootstrap und Bootstrap Vue sind mächtige Frameworks zur Umsetzung von UX. Entscheidende Vorteile sind die Wahrung eines konsistenten Erscheinungsbildes und bei Bootstrap Vue das automatische Rendern von Accessability features. Leider bringt das Ganze aber auch einen großen Overhead beim Laden, Parsen und Rendern mit sich und erzeugt Abhängigkeiten von weiteren Libraries. Zudem verhalten sich die Components nicht immer wie gewünscht. Auch die adaptiven breakpoints z.B. von modals sind nicht immer zufriedenstellend für die eigene Anwendung adaptierbar.

Statt also viel Zeit damit zu verbringen, Bootstrap so hinzubiegen, dass es den eigenen Projektanforderungen genügt, bin ich auch in der Lage, alle benötigten CSS und Komponenten selbst zu programmieren. Getreu dem Motto: die beste Maschine ist die, mit den wenigsten beweglichen Teilen. Speziell auf die Aufgabe zugeschnittener HTML, CSS und JS Code verringert die Lade- und Renderzeiten.

Nichts desto trotz lohnt sich der Einsatz von Bootstrap Vue bei der Zusammenarbeit mehrerer Entwickler, da für alle Beteiligten ein konsitenter Funktionsumfang bereitsteht und die UX ein einheitliches Erscheinungsbild erhält.

Glücklicherweise sind wir mittlerweile auf dem Stand, dass alle wichtigen modernen Browser auch den vollen Satz an modernen HTML, CSS und JavaScript Funktionen unterstützen. Statt also wie jahrelang erforderlich einen Haufen Zeit auf Internet Explorer Inkompatibilitäten zu verschwenden, können wir uns als Entwickler endlich weitgehend auf die eigentliche Umsetzung der gewünschten UX konzentrieren.

Und da wir die Endgeräte von morgen nicht absehen können, führt kein Weg an einem responsiven Layout vorbei. D.h. die Inhalte füllen den Viewport für mobile devices möglichst effizient aus und passen sich an jede Viewportbreite dynamisch an. In die andere Richtung würde ich dem Satzspiegel immer Grenzen setzen, da bei tendenziell immer größer werdenden Desktop-Monitoren sonst irgendwann durch überlange Textzeilen die Lesbarkeit nicht mehr gewährleistet ist.

PWA Progressive Web Apps mit Vue.js

Aus der jahrelangen Erfahrung zeigt sich, dass wahrscheinlich 90 Prozent aller datenbasierten Anwendungen auch ohne eine native App abgebildet werden können. Mit HTML5 und modernen Browser-Features haben wir mittlerweile einen ordentlichen Baukasten zur Erstellung mobiler Anwendungen für alle gängigen Plattformen zur Verfügung.

Nach jahrzehntelangem Serverside Rendering und mühsamen Anfängen mit AngularJS (1) bin ich mittlerweile absolut überzeugter Vertreter von Vue.js. Dieser Framework stellt eine hervorragende Plattform zur Entwicklung datengetriebener Benutzeroberflächen mit clientseitigem Rendering dar. Hat man HTML, CSS und JavaScript einigermaßen verinnerlicht, ist man dank der deklarativen Syntax in Vue schon halb zu Hause.

Das Grundkonzept, die UX von vorne herein durch Daten zu steuern, statt umgekehrt aus den Benutzeraktionen ggf. am Ende Daten zu generieren, sowie die bidirektionale Datenbindung stellen eine immense Beschleunigung des Entwicklungsprozesses dar. Die Frage ist nicht mehr: kann ich das clientseitig überhaupt irgendwie hinbekommen? Vielmehr kann man die gewünschte Programmlogik fast wörtlich deklarativ in ein HTML-Template Fragment "gießen" (hier empfiehlt sich immer eine Aufspaltung in Components). Das modulare Konzept der Components lässt zudem eine maximale Wiederverwendbarkeit des geschriebenen Codes zu. Zudem haben App und Components einen definierten lifecycle und auch der Datenaustausch über custom events ist schlüssig.

Die verbesserte Reactivity in Vue 3 über Proxies löst u.a. auch Probleme mit nachträglich hinzugefügten Datenstrukturen. Zudem können globale Objects von vorne herein in allen Components voll reactive verfügbar gemacht werden. Die größte Stärke sind aber sicherlich Computed Properties, die eine effizient gecachte Umformung bzw. Filterung der zugrundliegenden Datenstrukturen zur Laufzeit ermöglichen und diese voll reactive für ein optimales Rendering im Template bereitstellen. Und auch das Thema Lokalisierung ist dank Erweiterungen wie Vue I18n praktikabel lösbar. Kurzum: da kommt echt Freude auf :-)

Das Thema Progressive Web Apps (PWA) ist nicht mehr ganz neu, setzt sich aber langsam durch. Neben neuen JavaScript APIs, die eine Erweiterung der klassischen HTML5 UX in Richtung systemnaher Funktionen bringen sollen, ist sicherlich die Installierbarkeit ein wichtiges Feature. Hat der Benutzer die PWA auf seinem Endgerät installiert, präsentiert sich die Anwendung eher wie eine "normale" App und man hat losgelöst von den üblichen Browser Controls (Adresszeile, Settings, ...) die Spielwiese des Viewports quasi für sich alleine. Anders ausgedrückt: die PWA kapselt, ein Mal installiert, die eigentliche Funktionalität einer WebApp ohne aber einen normalen Webbrowser darzustellen. Das erübrigt in gewissem Umfang eine Einschränkung der Zugriffssteuerung über das System.

Der Entwicklungsaufwand kann je nach gewünschter Funktionalität einigermaßen hoch sein, insbesondere, wenn eine echte Offlinefunktionalität angestrebt wird. Aber als reduzierte UX für sinnvolle datenbasierte Unternehmensanwendungen ist die PWA eine interessante Erweiterung einer bestehenden HTML5 basierten Webanwendung. Der Punkt ist, dass der Zugriff z.B. aus dem Homescreen des Smartphones einfacher ist und die Möglichkeiten der Fehlbedienung durch die ausgeblendeten Browser Controls stark reduziert sind. Zudem ist die Möglichkeit, über WebPush zeitnah Daten an einen oder alle relevanten Clients zu senden und ggf. sogar systemeigene Notifications auszulösen, ein deutlicher Pluspunkt gegenüber einer "klassischen" Webanwendung mit zyklischem pull.

Leider hinkt Apple bei der Implementierung wichtiger Features (WebPush und Notification APIs) im iOS/ipadOS Safari hinterher. Aber grundsätzlich funktionieren installierbare PWA auch schon in den aktuellen iOS/ipadOS Safari Versionen. Kann in unternehmensinternen Anwendungen die Wahl von Endgeräten und Browser kontrolliert werden, so sind PWA eine sehr gute Möglichkeit, Digitalisierungsprozesse im Unternehmen abzubilden. Und das im Gegensatz zu nativen Apps ohne den Umweg über AppStores. Die unternehmenseigene PWA kann mit eigenem normalen Web-Hosting genau so umgesetzt und deployed werden, wie Sie es für richtig halten. Ohne dass ein AppStore Betreiber dazwischen funkt.

Momentan setzt Google Chrome (auch Microsoft Edge Chromium) das Konzept am optimalsten um. Aber auch in Firefox oder Samsung Internet funktionieren einige wichtige APIs schon sowohl unter Windows 10 als auch Android. Voraussetzung ist immer eine möglichst aktuelle Browserversion.

Sollte Apple endlich voll einsteigen, so könnten PWA die seit Jahren beschworene Zukunft von Apps auf mobilen Endgeräten darstellen.

Webbasiertes Content Management und Datenverwaltung

Seit den Anfängen des world wide web stehen wir als Entwickler immer wieder vor ähnlichen Problemen. Abseits der klassischen Bereitstellung von statischen HTML-Inhaltsseiten via FTP Upload besteht die Notwendigkeit, Inhalte komfortabel und zeitnah erstellen und pflegen zu können. Zudem wachsen ständig die Anforderungen bezgl. mobile usability und technischen Dateiformaten, die in der alltäglichen Pflegearbeit von einem Redakteur kaum zu berücksichtigen sind.

Es gibt die gängigen Open Source Web Content Management Systeme wie WordPress, Joomla oder TYPO3, die weltweit millionenfach im Einsatz und für ihre jeweilige Aufgabe gut erprobt sind. Tatsächlich erfüllt aber eher nur TYPO3 die Anforderungen an ein Enterprise CMS.

Die genannten und andere CMS sind unter der Haube sicherlich mächtige Werkzeuge und prinzipiell auf Modularität ausgelegt. Aber für meinen Geschmack erzeugt das gelegentlich unnötigen Overhead bei der Integration eines CMS für ein konkretes Kundenprojekt. Zudem ist bei vielen die Medienverwaltung im Backend eher unpraktisch umgesetzt. Dabei fallen selbst bei Websites mittlerer Größe schon oft Dutzende von Grafiken und/oder PDF an, die sinnvoll auch mehrsprachig im Backend verwaltet werden müssen.

Da kann man sich manchmal nur wundern, warum die CMS Entwickler es für ausreichend halten, Bilder nur als komplett beschnittene Mini-Thumbnails zu präsentieren, oder in Auflistungen Dateinamen abzuschneiden. Spätestens, wenn ähnliche Inhalte in mehrere Sprachen hochgeladen wurden, findet ein CMS Redakteur kaum noch Daten wieder. Und dass Mehrsprachigkeit oft über plugins implementiert wird ist mir ziemlich rätselhaft. Schon jede kleine Website für eine Ferienwohnung hat bei uns mindestens zwei Sprachen. Wir leben schließlich in einem offenen Europa.

Aus dieser Praxiserfahrung heraus habe ich seit den 2000er Jahren mittlerweile mehrere Versionen von Content Management Systemen auf unterschiedlichen Plattformen entwickelt, von denen z.B. nextshop CMS bis heute aktiv in vielen Kundenprojekten im Einsatz ist.

Das jüngste CMS4D basiert auf PHP/MySQL und legt den Schwerpunkt auf die Verwaltung und Konfiguration von Daten für Web-Apps. Das System ist darauf konzipiert, auch in einer gängigen shared hosting Umgebung mit limitierten Resourcen möglichst performant dynamische Inhalte zu rendern und auszuliefern. Mehrsprachigkeit ist integraler Bestandteil der Websitestruktur und Datenpflege, ebenso wie eine mögliche grundlegende Steuerung der Frontendausgabe über angemeldete Benutzer/Gruppen. Ein grundlegendes Kategorie- und News-System ist ebenfalls integriert. Vor allen Dingen stellt aber auch der Media Bereich im Backend erweitere Möglichkeiten zur Verwaltung von hochgeladenen Dateien bzw. im CMS erstellten Daten bereit. Neben einer frei erweiterbaren virtuellen Ordnerstruktur gibt es einen aussagekräftigen Listview mit einschaltbaren Thumbnails, Suchfunktion und Datentypfilterung, der auch das Verwalten von hunderten oder tausenden Bilddateien komfortabel ähnlich einem Windows Explorer ermöglicht.

Convention over configuration

Dabei liegt der Schwerpunkt nicht auf möglichst offener Architektur (die eierlegende Wollmilchsau), wie es bei Open Source Systemen zur plugin Integration weitgehend erforderlich ist. Vielmehr konzentriert sich die Programmierung auf die typischen Schwerpunktaufgaben eines CMS und versucht diese möglichst effizient mit möglichst wenig Resourcenverbrauch abzuarbeiten.

Anders ausgedrückt: das System folgt dabei eher dem Grundsatz, dass die Lösung einer speziellen Aufgabe auch möglichst auf diese Aufgabe hin optimiert wird. Es gibt klare Regeln, die nicht konfigurierbar sind, da die möglichen Ausnahmen im "echten Leben" sowieso nicht relevant werden. Einen Prozess weitgehend konfigurierbar zu machen erzeugt meist nur unnötigen overhead, der die Frontendausgabe ausbremst.

Dabei ist CMS4D aber bezüglich der Erweiterbarkeit für neue projektspezifische "Zahnräder" dennoch ausreichend modular aufgebaut. Die Implementierung erfolgt in reinem PHP Code entweder über die zu den Knoten der hierarchischen Webstruktur frei zuordenbare Controller Scriptseiten oder individuell in einer Inhaltsseite über projektspezifisch implementierte Funktionsmodule. In beiden Fällen ist keine Ebene mit dubiosen Metasprachen zwischengeschaltet. Letztendlich geht es auch fast immer "nur" darum, im Alltagsbetrieb in einem gestalteten Rahmen der Website dynamische Daten an bestimmten Stellen im Layout auszugeben. Hierbei kann eine Inhaltsseite beliebig viele gemischte statische und dynamische/datenbasierte Inhalte ausgeben. Ein Redakteur kann sich somit weitgehend auf die inhaltliche Arbeit konzentrieren. Bild- und Layoutberechnungen erfolgen weitestgehend automatisiert im projektspezifisch vordefinierten Rahmen.

CMS4D arbeitet für die Frontendausgabe der Layout-, Daten- und Textinhalte ohne serverseitigen Caching-Mechanismus. D.h. alle Inhalte werden möglichst bei jedem Speichern im Backend einmalig so vorberechnet, dass sie für die Frontendausgabe optimiert ausgelesen und gerendert werden können. Bilder werden hingegen nur einmalig optimert gerendert und ab dann effizient aus einem Cache ausgeliefert. Hierbei ist zu betonen, dass grundsätzlich ein Transcoding von hochgeladenen JPG zum insbesondere von Google Pagespeed gewünschten WebP Format automatisch durchgeführt wird. Zudem werden die Bitmaps automatisiert auf die im Seitenlayout tatsächlich verwendeten Bildbreiten heruntergerechnet, so dass möglichst immer nur die je nach Endgerät erforderlichen Bitmapdaten vom Server geladen werden. Hierbei werden auch zusätzliche dynamische picture sources zu gängigen Viewportbreiten automatisch im Cache vorberechnet. Die Inhalte/Transport/ClientCaching sind grundsätzlich möglichst gut für Google Pagespeed optimiert.

Übrigens zeigt diese Website im Seitenfuß immer die tatsächlich beim Rendern einer bestimmten Inhaltsseite benötigte Rechendauer an. Das sind z.B. auch in einem shared hosting bei aktivem PHP-FPM ca. 10-50 Millisekunden bis zur Rückgabe des ersten Byte des HTML Stammdokumentes.

PHP / MySQL / SQL / HTML / JavaScript / CSS / Vue.js / node.js / JSON / SVG / PDF / QR-Code / ASP.NET / C# / XML / XSLT