Kürzere Time-to-Market mit Server-Driven UI

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.

Was ist SDUI?

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:

• Text, um den Nutzer zu informieren
• Input-Felder für die Erfassung von E-Mail/Benutzername und Passwort
• Checkbox für die Bestätigung der AGB's und des Datenschutzes
• Button zur Bestätigung der Registrierung und zum Ausführen des Logins

Bei der konventionellen Art der Frontend-Entwicklung würde der Workflow vereinfacht wie folgt aussehen:

• Positionierung der einzelnen Komponenten auf dem Bildschirm
• Styling der Komponenten
• Responsiveness für verschiedene Bildschirmgrößen / -auflösungen sicherstellen
• Übergabe der Formulareingabewerte an das Backend nach Bestätigung des Buttons
• Weiterleitung des Nutzers nach erfolgreicher Übergabe der Eingabewerte
• Anzeigen einer Fehlermeldung, wenn die Eingabewerte Fehlerhaft waren

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:

• Implementierung einer Funktion, welche Komponenten auf dem Bildschirm positioniert und die Responsiveness sicherstellt
• Implementierung einer Funktion, welche Daten aus dem Backend und Nutzereingaben an einzelne Komponenten verteilt
• Implementierung einer Funktion, welchen Daten / Nutzereingaben von Komponenten an das Backend weiterleitet
• Implementierung einer Funktion, welche Funktionen im Frontend auslöst bzw. das Frontend manipuliert
• Modularisierung und Styling der benötigten Komponenten

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.

Vorteile von SDUI

1 Cross-Plattform-Anpassung & Entfall von Updates durch die Nutzer

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.

2 Kürzere Iterationszyklen

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.

3 Für Nicht-Entwickler geeignet

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.

4 Wartbarkeit & einheitliches UI

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.

Herausforderungen bei SDUI

1 Versionierung

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.

2 Cross-Plattform-Apps synchron halten

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.

3 Grad der Modularisierung

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.

4 Skalierbarkeit vs. Flexibilität

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:

• der Funktionsumfang der App steigt, sinkt oder ändert sich grundlegend
• zusätzliche Anwendungsfälle bzw. Apps entstehen

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.

Fazit

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.:

• MVPs: MVPs dienen der Validierung des Funktionsumfangs einer Produktidee und des dahinterliegenden Geschäftsmodells. Kurze Entwicklungszyklen ermöglichen eine schnellere Reaktion auf das Feedback der Early-Adopter sowie die Iterationszyklen der Geschäftsmodellentwicklung kürzer zu halten.
• Apps deren Geschäftsmodell auf einer hohen Nutzerinteraktion oder In-App-Einkäufen basiert: SDUI kann helfen Conversion- und User-Experience-Optimierungen effizienter und effektiver zu gestalten. Für A/B-Tests werden einfach verschiedene Konfigurationsdateien angelegt. Nach vordefinierten Regeln können diese Konfigurationsdateien an gewünschte Nutzer übergeben werden. Gerade bei Smartphone- und Desktop-Apps kann durch den Entfall eines Updates eine breitere Basis an Nutzern erreicht werden.
• Produkte, die auf die individuellen Bedürfnisse der Endnutzer/Kunden anpassbar sein müssen: z. B. Dashboards