Kolumne

EnterpriseTales: Responsive Design vs. Multi-Channel-Architektur – wer gewinnt?

Lars Röwekamp

Smartphones und Tablets gewinnen immer stärker an Bedeutung. Bereits heute gibt es deutlich mehr Mobile Devices als Laptops und Desktoprechner zusammen. Als Anbieter einer Webanwendung kann man es sich kaum noch leisten, die mobile Zielgruppe zu vernachlässigen. Zum Glück gibt es Responsive Design. Aber reicht das wirklich aus, um alle Welten sinnvoll zu bedienen?

Responsive Design vs. Multi-Channel-Architektur

Während man noch vor wenigen Jahren mittels User-Agent-Erkennung, Content-Weichen und anschließendem Redirect den aufrufenden Browser mit dem für ihn optimierten Content versorgt hat, nutzen Webentwickler heute technologische Hilfsmittel wie CSS Transistions, Media Queries, Grid-basierte Layouts, Breakpoints und JS Image Libraries für diese Aufgabe.

Der wesentliche Unterschied zwischen den beiden Varianten liegt darin, dass es früher mehrere, für bestimmte Auflösungsbereiche vorgefertigte Content-Varianten gab, während heute eine gemeinsame Content-Basis plus ein wenig Voodoo dafür sorgt, dass die gerenderte Ausgabe auf allen Geräten optimal daherkommt.

Dank Grid-Layout und Breakpoints weiß das UI, wie viele Kacheln des Grids bei einer vorgegebenen Auflösung in eine Zeile passen und wann ein Umbruch erfolgen muss. Zwischen zwei Breakpoints wiederum können Images, Abstände und andere visuelle Elemente on-the-fly skaliert werden, sodass bei der Veränderung der Fenstergröße keine Sprünge, sondern fließende Übergänge entstehen (Abb. 1). So weit, so gut, sollte man meinen.

Abb. 1: Responsive Design auf dem Desktop, Mobile und Tablet

Responsive Design reicht nicht (immer) aus

Leider geht das UI-Pattern Responsive Design davon aus, dass die Funktionalität auf einem mobilen Gerät und einem Desktop oder Laptop identisch ist. Unterschieden werden lediglich die visuelle Aufarbeitung und das Layout des darzustellenden Contents. Die Praxis allerdings belegt an unzähligen, völlig überladenen und kaum sinnvoll zu bedienenden Apps, dass neben den rein visuellen UI-Aspekten vor allem auch eine anständige UX über Erfolg bzw. Misserfolg einer App entscheidet. Und hier gilt für Mobile-Apps nach wie vor die Devise: weniger ist mehr.

W-JAX
Mike Wiesner

Data- und Event-driven Microservices mit Apache Kafka

mit Mike Wiesner (MHP – A Porsche Company)

Niko Köbler

Digitization Solutions – a new Breed of Software

with Uwe Friedrichsen (codecentric AG)

Software Architecture Summit 2017
Dr. Carola Lilienthal

The Core of Domain-Driven Design

mit Dr. Carola Lilienthal (Workplace Solutions)

Sascha Möllering

Reaktive Architekturen mit Microservices

mit Sascha Möllering (Amazon Web Services Germany)

Möchte man dem UX-Anspruch gerecht werden, gilt es, die Funktionalität auf dem Mobile auf ein sinnvolles Minimum zu reduzieren. Zu diesem Zweck kann man entweder die bereits vorhandene Funktionalität – ausgehend von der Maximalvariante – Schritt für Schritt reduzieren oder alternativ – Mobile First als Ausgangsbasis – mit einer Minimalvariante starten und diese sukzessive erweitern. Im ersten Fall spricht man von Graceful Degradation, im zweiten von Progressive Enhancement.

Der wesentliche Unterschied der beiden Varianten besteht darin, dass bei Mobile First plus Progressive Enhancement die mobile Variante im Fokus des visuellen, aber auch des fachlichen Designs steht. Die mobile Variante spiegelt auf jeden Fall den entscheidenden Mehrwert der Webanwendung wider und deckt die dafür notwendigen Use Cases ab. Die Variante für Desktop und Laptop erweitert diese lediglich um zusätzliche, sinnvolle, aber nicht essentielle Funktionalitäten. Bei dem Ansatz Graceful Degradation dagegen startet das Design mit der Desktop- bzw. Laptopvariante und schmeißt für die Mobile-Variante alles raus, was nicht umsetzbar ist. Das Endresultat ist nicht selten ein gefühlter Kompromiss an die zu unterstützende, mobile Umgebung und fühlt sich nicht wirklich rund an.

Es stellt sich natürlich die Frage, warum man den Ansatz der Graceful Degradation überhaupt in Betracht ziehen sollte, wenn Mobile First plus Progressive Enhancement scheinbar die besseren Resutate liefert? Mobile First setzt voraus, dass man auf der grünen Wiese starten kann. Dieses Szenario ist leider bei über Jahre gewachsenen Webanwendungen nicht gegeben und Graceful Degradation somit ein guter, wenn nicht der einzig realisierbare Kompromiss.

Channel, wir brauchen Channel

Auch wenn wir mit den beiden Ansätzen Graceful Degradation und Progressive Enhancement einen wichtigen Schritt in die richtige Richtung gegangen sind, bleibt nach wie vor ein generelles Problem bestehen. Auch bei diesen Ansätzen wird davon ausgegangen, dass sich die Funktionalitäten von Mobile und Desktop/Laptop decken oder zumindest ein Subset davon bilden. Aber ist das in der Realität tatsächlich der Fall und ist das wirklich sinnvoll?

Eine gute Mobile-App schafft Mehrwert insbesondere durch die Nutzung von Features, die nur das Mobile Device liefert: Kamera, GPS, NFC, Beschleunigungssensor, Zugriff auf andere Apps oder OS-Funktionalitäten. In Konsequenz bedeutet das, dass die Use Cases von Mobile und Desktop/Laptop deutlich auseinandergehen können. Hinzu kommt, dass das Nutzungsverhalten einer App in der Regel stark von dem einer klassischen Webanwendung abweicht.

Der App-User ist nicht gewillt, mehrseitig Prozesse auszuführen oder umfangreiche Formulare auszufüllen. Er möchte sein Device aus der (Hosen-)Tasche holen, auf einen Blick die für ihn relevanten Informationen sehen, um dann das Device wieder wegstecken zu können. Wir brauchen also eine Anwendungsarchitektur, die es erlaubt, unterschiedliche Use Cases oder Use Cases in unterschiedlichen Granularitäten auf verschiedenen Kanälen zu bedienen.

Lesen Sie auch: Mobiler Mehrwert – warum gute Apps mehr sind, als responsive Website-Versionen

Zu theoretisch? Nehmen wir als Beispiel eine typische Aktivitäts-Tracking-Anwendung. Mit der App lassen sich Bewegungszeiten messen, eigene Touren (Radfahren, Laufen, Wandern oder Kanufahren) aufzeichnen oder vorgegebene Touren anderer Nutzer nachfahren. Innerhalb der Webanwendung wiederum können Touren für ein Zielgebiet ausgesucht und bewertet oder eigene Touren detailliert beschrieben und bebildert werden. Natürlich gibt es auch gemeinsame Use Cases, wie die Visualisierung der Bewegungsdaten, als Dashboard.

Bereits dieses kleine Beispiel zeigt, dass Responsive Design und ein damit verbundenes Rendering auf Seiten des Servers für das Gros der Use Cases nicht wirklich zielführend ist. Sinnvoller wäre eine Architektur, bei der der Client gezielt Daten für die Visualisierung der für ihn relevanten Use Cases anfragen und dann selbstständig rendern kann. Die Anfrage der Daten könnte via RESTful-Web-API in Form von JSON-Objekten erfolgen, die Visualisierung im Rahmen einer Single Page Application (Web Channel) oder nativen bzw. hybriden App (Mobile Channel).

Die via API zur Verfügung gestellten Daten sind dabei für die verschiedenen Kanäle durchaus identisch – eine Tour ist eine Tour –, die mit den Daten verbundenen Use Cases dagegen nicht. Je nach Komplexität der Use Cases kann es durchaus sinnvoll sein, neben oder alternativ zu der rein ressourcenbasierten REST-Schnittstelle API Gateways zur Verfügung zu stellen. Die Gateways übernehmen dabei die Aufgabe, Use-Case-spezifische Aggregate zu bilden, um so die Anzahl der notwendigen Client-Server-Calls zu minimieren. Weichen darüber hinaus die Datenmodelle der verschiedenen Clients deutlich voneinander ab, da z. B. auf einem Mobile-Client weniger detaillierte Informationen benötigt werden als auf einem Desktopclient, können diese durch spezialisierte API Gateways aufbereitet werden. Abbildung 2 zeigt eine entsprechende Architektur inklusive SPA-Webclient.

Abb. 2: Multi-Channel-Architektur inklusive SPA-Webclient

Neben der beschriebenen REST-Schnittstelle verdeutlicht Abbildung 2 noch weitere Besonderheiten. Um dem Nutzerverhalten eines Mobile-Users gerecht zu werden, erlaubt die dargestellte Architektur neben dem klassischen, Pull-orientierten Request-/Response-Modell zusätzlich ein Push-orientiertes Event-/Notification-Modell. Traffic zwischen Clients und Server wird so nur dann erzeugt, wenn auf dem Server tatsächlich neue Daten vorliegen. Als weitere Besonderheit finden wir in Abbildung 2, neben den bereits erwähnten Business-/Domain-Services, eine weitere Ebene von getrennten Plattformservices. Mithilfe dieser Ebene wird auch auf Ebene der Enterprise-Ressourcen die Möglichkeit geschaffen, bedarfsgerecht zu skalieren, d. h. einzelne, hochfrequentierte Plattformservices häufiger zu deployen als andere. Möchte man in dem Kontext die Provisionierung beschleunigen, bietet es sich an, diese Plattformservices (PaaS) in die Cloud zu verlagern.

Fazit

Webanwendungen ausschließlich für Desktopbrowser zu entwickeln, ist heutzutage nicht mehr zeitgemäß. Zu stark ist mittlerweile die Verbreitung von Smartphones und Tablets. Responsive Design via Mobile First plus Progressive Enhancement oder via Graceful Degradation ist ein erster Schritt in die richtige Richtung. Das gilt allerdings nur dann, wenn die Use Cases beider Welten nahezu deckungsgleich sind oder zumindest ein Subset bilden. Ist das nicht der Fall, muss eine andere Lösung her, die die Besonderheiten der verschiedenen Kanäle bestmöglich unterstützt und gleichzeitig den einzelnen Kanälen die größtmögliche Flexibilität ermöglicht.

Mithilfe von Multi-Channel-Architekturen lässt sich diese Flexibilität erreichen. Durch die Auslieferung von Daten statt gerenderter Views, die Verwendung von Push ergänzend zu Pull und die Modularisierung der Business- und Serviceschicht inklusive deren Bereitstellung via Cloud entsteht ein flexibles und skalierbares System. Neue Features, egal für welchen Kanal, können schnell und effizient realisiert werden. Eine schnelle Time-to-Market ist nicht mehr nur Wunsch, sondern Realität! In diesem Sinne: Stay tuned!

Mehr zum Thema:

Responsive Design: „Ladegeschwindigkeit ist wichtiger!“

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.