Full-Stack Entwicklung - Funktion und Design
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.
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 über die Jahre schon mehrere Web Content Management Systeme in unterschiedlichen Sprachen (VBScript, ASP.NET/C#, PHP, Vue.js) von Grund auf selbst entwickelt, um genau diese Pipeline nach eigenen Wünschen umzusetzen.
Digitalisierung beginnt im Kleinen
Seit Jahren in vielen Diskussionen gerne genutztes Hype-Schlagwort, bedeutet sinnvolle Diagitalisierung für mich in erster Linie, im Unternehmensalltag Reibungspunkte beim Umgang mit Daten zu reduzieren und somit Verwaltungsaufgaben zu vereinfachen. Meist sind es schon die typischen Medienbrüche, die das Erfassen von unternehmensrelevanten Daten und deren Aufbereitung für interne Prozesse verkomplizieren und redundante Pflegearbeiten erfordern.
Einfaches Beispiel: ein Außendienstmitarbeiter füllt beim Kunden ein Wartungsformular auf Papier handschriftlich aus und reicht dieses wieder zurück in der Firma beim Innendienst ein. Dort werden die Daten wiederum manuell z.B. in ein CRM System eingepflegt. Hier tritt schon das Problem auf, dass jeder Außendienstmitarbeiter ein Formular unterschiedlich ausfüllt und der Innendienst sich selbst relevante Informationen zur Auftragsverarbeitung zusammenreimen muss. Selbst wenn der Außendienstmitarbeiter ggf. schon elektronische PDF-Formulare zur Dateneingabe nutzt und diese per E-Mail an die Firma sendet, besteht weiterhin ein Bruch zu internen Schnittstellen, da die PDF-Daten nicht wirklich strukturiert vorliegen.
Eine saubere Lösung zum Lückenschluss wäre eine zugriffsgeschützte Web-Anwendung, die z.B. einen Satz an Wartungsformularen auf sämtlichen gängigen Endgeräten im Web-Browser online verfügbar macht. Diese Formulare erfassen die Eingaben strukturiert und speichern sie so auf einem Server in einer zentralen Datenbank ab, dass die Daten auf Knopfdruck je nach Erfordernissen z.B. über CSV-Export für andere Anwendungen im Unternehmen digital verfügbar gemacht werden können.
Einmal sinnvoll strukturiert erfasst, bieten die Daten die Basis für erweiterte Funktionalität der Web-Anwendung. So könnten zum Beispiel digital erfasste Wartungsdaten einer bestimmten Kunden-Anlage bzw. Gerät zugeordnet werden und bieten vielfältige Möglicheiten der nachträglichen Auswertung. Z.B. wie oft treten welche Fehler auf, welche Komponenten müssen besonders oft ausgetauscht werden, sind bestimmte Zulieferteile besonders unzuverlässig etc.
So oder so erlaubt die strukturierte Erfassung von Prozessdaten einen reibungsloseren Datenaustausch im Unternehmen und spart somit immer Zeit und Kosten in der Verwaltung. Und die verbesserte statistische Auswertung von Prozessendaten kann weitere Schwachstellen aufdecken und zusätzliches Einsparpotential offenlegen.
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, browser-basierter Anwendungen für alle gängigen Plattformen zur Verfügung.
Der Vue.js Framework stellt eine hervorragende Basis zur effizienten Entwicklung datengetriebener Benutzeroberflächen mit clientseitigem Rendering dar.
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, wird aber mit umfassender Unterstützung durch die gängigsten Browserhersteller endlich relevant. 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.
Die Schaltzentrale einer PWA ist der zu einer bestimmten Domain im Web-Browser im Hintergrund arbeitende service worker, der nicht nur die Kommunikation mit dem Web-Server verwalten kann, sondern in dem auch eingehende WebPush Nachrichten auflaufen. Je nach gefordertem Umfang ist es möglich, Teile der PWA offline verfügbar zu machen. So könnten z.B. Formulare auch offline ausgefüllt und die erfassten Daten in einer lokalen IndexedDB im Browser zwischengespeichert werden. Ist das Endgerät wieder online, können die erfassten Daten mit dem zentralen Web-Server synchronisiert werden. Diese Offline-Funktionlität macht z.B. für Arbeitsumgebungen Sinn, in denen technisch bedingt temporär kein Internetzugang für ein mobiles Endgerät verfügbar ist.
Der Entwicklungsaufwand für eine PWA kann je nach gewünschter Funktionalität einigermaßen hoch sein, insbesondere, wenn eine 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 für den Benutzer 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.
Stand Frühjahr 2023 hat auch Apple für neuere Geräte ab iOS 16.4+ / iPadOS 16.4+ die wichtigen APIs WebPush und Notifications im Safari implementiert. Die Standards scheinen eingehalten worden zu sein - ältere PWA, die diese Features bereits seit Jahren nutzen, funktionieren sofort. Allerdings muss bei Apple für die mobilen Endgeräte die PWA leider zwingend vom Benutzer auf dem Homescreen hinzugefügt (quasi installiert) werden, bevor WebPush zu der Website möglich ist. Ob es in Zukunft dabei bleiben wird? Das wäre natürlich ein herber Rückschritt, da es eine zusätzliche Hemmschwelle zur vollen Nutzung von WebPush aufbaut und aus Sicht des App-Betreibers absolut kontraproduktiv ist. Ältere Apple Geräte, die nicht mehr auf OS 16 upgraden können, bleiben beim Thema WebPush und Notifications sowieso komplett außen vor...
Kann in unternehmensinternen Anwendungen die Wahl von Endgeräten und Browser (Installation auf dem Homescreen) kontrolliert werden, so sind PWA eine sehr gute Möglichkeit, maßgeschneiderte Digitalisierungsprozesse im Unternehmen abzubilden. Und das im Gegensatz zu nativen Apps ohne den Umweg über AppStores. Ihre 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 der Progressive Web App am optimalsten um. Aber auch in Firefox oder Samsung Internet funktionieren die wichtigsten APIs schon sowohl unter Windows 10/11 als auch Android (und teilweise ab 2023 auch Apple Safari 16.4+). Voraussetzung ist immer eine möglichst aktuelle Browserversion.
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 je nach Projekt viel Zeit damit zu verbringen, Bootstrap so hinzubiegen, dass es den eigenen Anforderungen genügt, bin ich auch in der Lage, alle benötigten CSS und Komponenten von Grund auf 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.
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.
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.
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.
Die effizienteste Maschine ist die, mit möglichst wenigen beweglichen Teilen
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 werden kann. 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.