Nutzer von Social-Media-Apps kennen es: Auf mysteriöse Weise ändert sich das Aussehen der Smartphone-App, Funktionen kommen hinzu oder verschwinden. Ein und dieselbe App verfügt bei Freunden bereits über Funktionen und Designs, welche in der App auf dem eigenen Smartphone noch fehlen. All dies geschieht ohne ein Update über den App Store bzw. Play Store. Instagram-Nutzer, die über mehrere Benutzerkonten verfügen, können dieses Verhalten der App sogar über ihre verschiedenen Konten hinweg auf demselben Endgerät beobachten. Wie ist dies möglich?
Die Antwort auf des Rätsels Lösung ist: Server-Driven UI (SDUI).
In diesem Artikel werde ich erklären was SDUI ist und wie es sich von der herkömmlichen Art und Weise ein Frontend zu programmieren unterscheidet. Abschließend gehe ich auf die Vorteile und Herausforderungen ein.
Um zu verstehen was am SDUI anders ist, muss zunächst klar sein wie ein User Interface bzw. Frontend üblicherweise entwickelt wird. Schauen wir uns das vereinfacht anhand eines praktischen Beispiels an. Angenommen wir entwickeln eine App und möchten ein Login- und Registrierungsformular einbauen. Für die Formulare benötigen wir folgende Komponenten:
Bei der konventionellen Art der Frontend-Entwicklung würde der Workflow vereinfacht wie folgt aussehen:
Für die Formulare legen wir jeweils eine eigene Datei an und durchlaufen jeweils diesen Workflow. Das Styling und die Responsiveness werden uns im zweiten Durchlauf jedoch leichter fallen, da wir überwiegend die gleichen Komponenten verbauen. Abschließend müssen wir die App noch Updaten (App Store, Play Store und/oder Server bei Web-Apps bzw. Desktop-Apps).
Später entscheiden wir uns, bei dem Registrierungsformular ein weiteres Input-Feld anzulegen. Den geschilderten Workflow durchlaufen wir für das neue Feld erneut. Abschließend laden wir noch die aktuelle Version der App hoch. Damit das aktualisierte Formular dem Nutzer zur Verfügung steht, muss dieser im Falle einer Smartphone- oder Desktop-App die App updaten.
Nun zum Vergleich der Workflow bei einem Frontend mit SDUI:
Für die Login- sowie die Registrierungsansicht wird nun im Backend jeweils eine Konfigurationsdatei (z. B. im JSON-Format) angelegt. Die Datei enthält Information über die zu verwendenden Komponenten, zur Positionierung der Komponenten, zu Backend-Endpoints für die Input-Felder sowie zu Funktionen, die ausgelöst werden sollen, wenn der Nutzer den Button betätigt.
{ "id" : "login", "margin": 10, "isElevated" : false, "content" : [ { "justify": "center", "padding": "15px 0px 0px 0px", "items" : [ { "item": "textInput", "size": 12, "fullWidth": true, "label": "Benutzer", "placeholder": "Ihre E-Mail-Adresse", "value": "/valueUser" } ] }, { "justify": "center", "padding": "15px 0px 0px 0px", "items" : [ { "item": "textInput", "size": 12, "fullWidth": true, "label": "Passwort", "placeholder": "Geben Sie Ihr Passwort ein", "value": "/valuePassword" } ] }, { "justify": "center", "padding": "15px 0px 0px 0px", "items" :[ { "item": "button", "size": 12, "label": "Login", "action": "/btnOnClick", "type": "primary" } ] } ] }
Beispiel einer Konfigurationsdatei im JSON-Format für ein Login-Formular
Beim Öffnen der App oder beim Besuch unserer Seite durch den Nutzer fragt das Frontend zunächst die Konfigurationsdatei beim Backend an. Nach dem Erhalt interpretiert das Frontend die Konfigurationsdatei und baut das User Interface entsprechend auf.
Entscheiden wir uns später, wie zuvor schon, dem Nutzer ein weiteres Feld im Registrierungsformular verfügbar zu machen, müssen wir den gesamten Workflow nicht erneut durchlaufen. Wir legen lediglich in der Konfigurationsdatei des Registrierungsformulars ein weiteres Feld an. Öffnet der Nutzer das nächste Mal die App, ist das neue Registrierungsformular verfügbar.
Diese Vorgehensweise funktioniert auch für komplett neue Ansichten. Möchten wir z. B. ein Umfrageformular erstellen, legen wir dieses einfach in der Konfigurationsdatei mit den benötigten Komponenten und Backend-Endpoints an. Da wir dafür keine neuen Komponenten im Frontend implementieren müssen, erhalten die Nutzer die neue Ansicht beim nächsten App-Start.
Die Unterschiede zwischen einem herkömmlichen Frontend und einem Frontend mit SDUI werden nun deutlich. Bei einem konventionellen Frontend ist das User Interface im Code quasi festgeschrieben. Änderungen am User Interface können somit nur durch Änderungen am Code des Frontend herbeigeführt werden. Die Änderungen kommen im Falle einer Smartphone- und Desktop-App beim Nutzer nur dann an, wenn dieser ein Update der App durchführt.
Im Gegensatz dazu werden bei einem Frontend mit SDUI lediglich modularisierte Komponenten und Funktionen zur Interpretation einer Konfigurationsdatei bereitgestellt. Das User Interface wird "on the fly" auf dem Endgerät nach Erhalt der Konfigurationsdatei aufgebaut. Änderungen in der Konfiguration führen direkt zu Veränderungen im User Interface. Voraussetzung dafür ist, dass alle benötigten Komponenten modularisiert im Frontend verfügbar sind. Updates eines Frontend mit SDUI sind also immer nur dann nötig, wenn neue Komponenten hinzukommen sollen. Ein Nutzer muss die App somit nicht jedesmal updaten, um die neuesten Funktionen zu erhalten.
Den ersten Vorteil habe ich bereits erwähnt, nämlich die in vielen Fällen entfallende Notwendigkeit einer Aktualisierung der App und eines Updates durch die Nutzer. Dieser Vorteil nimmt an Bedeutung zu, wenn man bedenkt, dass die meisten Apps für mehr als nur eine Plattform verfügbar sind. Wo bisher doppelter Aufwand betrieben werden musste, z. B. bei nativen Android- und iOS-Apps, lassen sich die Apps mit einem SDUI auf beiden Plattformen mit nur einer Konfigurationsdatei anpassen. Selbiges gilt für Apps, die gleichzeitig als Desktop-App und Web-App verfügbar sind.
Bei Web-Apps fällt bekanntlich ein Updaten durch die Nutzer weg, da über den Web-Server immer die Version der App an den Nutzer geliefert wird, die wir festlegen. SDUI hat allerdings mehr Vorteile als nur Nutzer-Updates zu umgehen. Diese Vorteile haben wir während eines Kundenprojekts kennengelernt, bei dem wir die Möglichkeit hatten, das Konzept des SDUI erstmalig anzuwenden.
Der Kunde vertreibt in seinem Portfolio ein Frontend für Touchscreens, mit dem sich verschiedene Prozesse abbilden sowie Daten aus einer Datenbank anzeigen und manipulieren lassen. Für jeden ihrer Kunden muss dieses Frontend laufend angepasst werden, da bei jedem Kunden individuelle Prozesse bestehen, bestehende Prozesse angepasst, neue geschaffen und alte abgeschafft werden.
Und genau hier liegt das Problem der bisherigen Software bzw. die Stärken der neuen Software mit SDUI. Während bei der alten Software mühselig der Code im Frontend über mehrere Tage bis Wochen für jeden Kunden angepasst werden musste, sind es nun einzelne bis mehrere Tage. Dadurch, dass lediglich eine Konfigurationsdatei angelegt werden muss und sich das Frontend um den Rest kümmert, sparen sich die Mitarbeiter unseres Kunden Zeit, welche sie nun für ihre Dienstleistung und für eine intensivere Beratung ihrer Kunden nutzen können.
Ein weiterer Vorteil liegt darin, dass keine Kenntnisse in der Frontend-Entwicklung vorhanden sein müssen, um neue Prozesse abzubilden bzw. bestehende anzupassen. Jeder Mitarbeiter, der mit dem JSON-Format vertraut ist und sich in die Dokumentation einliest, ist in der Lage zumindest das User Interface grafisch aufzubauen. Auch die Sicherstellung der Kommunikation mit der Datenbank und Ausführung von Funktionen ist in den überwiegenden Fällen kein Hexenwerk.
Aufgrund der benötigten Konfigurationsdatei und durch die Modularisierung der Komponenten sind die Entwickler dazu gezwungen bestehende Komponenten wiederzuverwenden, anstatt sich ein weiteres Duplikat mit kleinen Änderungen einfallen zu lassen. Das führt zu einer schlankeren und einfacher wartbaren Code-Basis. Außerdem profitieren die Endnutzer dieser Software von einem einheitlichen User Interface.
Bei Smartphone- und Desktop-Apps werden wir nicht vollständig dafür sorgen können, alle Nutzer mit der aktuellsten Version der App auszustatten. Kommt es zu dem Szenario, dass unser Frontend eine neue Komponente benötigt, müssen die Nutzer ihre App updaten bevor diese Komponente nutzbar wird. Wir müssen also sicherstellen dem Nutzer abhängig von seiner App-Version die korrekte Konfigurationsdatei zu übermitteln.
Ist eine App über mehrere Plattformen hinweg verfügbar, müssen wir bei Änderungen sicherstellen, dass jedes Frontend auf dem aktuellen Stand ist, um die Konfigurationsdateien abbilden zu können. Fügen wir eine neue Komponente hinzu, muss diese über alle Plattformen hinweg integriert werden. Außer wir möchten plattformspezifische Funktionen anbieten.
Bei der Integration einer neuen Komponente stellt sich die Frage wie viele Schnittstellen zu der Komponente später benötigt werden. Zu wenige Schnittstellen führen zu einem eingeschränkten Funktionsumfang einer Komponente, welcher unter Umständen nachgebessert werden muss. Problematisch ist hierbei, dass die Endnutzer erneut Updaten müssen, um die nachgebesserte Komponente zu erhalten. Zu viele Schnittstellen führen zu einem höheren Integrationsaufwand, einer aufgeblähten Code-Basis sowie einem insgesamt komplexeren System. Eine hohe Komplexität des Systems kann ebenfalls die Komplexität der Konfigurationsdatei erhöhen. Die Erstellung und Anpassung des User Interface wird evtl. schwieriger.
Mit der Zeit sammeln sich unter Umständen zahlreiche Komponenten an, die nicht immer oder nicht mehr Verwendung finden. Dies kann aus den folgenden Gründen geschehen:
Ein große App kann zu langen Downloadzeiten, einem hohen Speicherplatzverbrauch und schlechter Performance führen. Dies sind Gründe für einen Nutzer sich gegen die Verwendung einer solchen App zu entscheiden. Ist eine möglichst große Nutzerbasis wichtig für den Erfolg der App, gilt es die App-Größe möglichst klein zu halten. Mit zahlreichen Komponenten im Frontend erhalten wir aber eine höhere Flexibilität. Wir müssen also unter den Gesichtspunkten der Flexibilität und Skalierbarkeit abwägen, welche Komponenten im Frontend an den Nutzer ausgeliefert werden sollen.
Geeignet ist ein SDUI besonders für Anwendungsfälle, bei welchen es auf kurze Entwicklungszyklen im Verlauf der Produktlebenszeit ankommt. Ist außerdem eine Cross-Plattform-Verfügbarkeit der App eine Anforderung können sich erhebliche Zeit- und Kostenersparnisse ergeben. Anwendungsfälle wären z. B.:
Was denkst du?