Buzzword-Bingo? Mobile first & Offline first

Inhaltsverzeichnis

In der Softwareentwicklung stößt man zwangsläufig immer auf die beiden Fachtermini Mobile first und Offline first. Da sie im Nachhinein oftmals nur mit immensem Aufwand implementiert werden können, sollten sie nicht (nur) auf Ihrer Buzzword-Bingo-Karte stehen, sondern ganz am Anfang der Projektplanung.

Auf die Fachtermini Mobile first und Offline first stößt man im Umfeld mobiler Apps fast schon zwangsläufig. Aus gutem Grund, denn beide Themen stellen nicht nur zentrale Elemente einer plattformübergreifend guten User Experience (UX) dar, sondern sind nachträglich oftmals nur mit immensem Aufwand in eine bestehende Software zu integrieren. Ganz am Anfang der Projektplanung sollten sie auch deswegen stehen, weil sie von den Anforderungen in ihrem Projekt hochgradig getrieben sind.

Smartphones und Tablets sind keine Neuheiten. Endgültig zum Durchbruch verholfen haben diesen Gerätekategorien wohl das Erscheinen des iPhones und iPads in den Jahren 2007 und 2010. Mobile Endgeräte sind aber nicht angetreten, um Desktop-PCs und Laptops komplett zu verdrängen. Alle Gerätekategorien haben ihre Daseinsberechtigung und ihren Anwendungszweck: Smartphones und Tablets können einfach mitgenommen werden und haben eine lange Akkulaufzeit. Laptops und Desktops haben mehr Power und mit Tastatur und Maus weitaus genauere Eingabemethoden. Legen wir unsere Buzzword-Bingo-Karte also erst einmal beiseite und schauen uns an, was sich hinter beiden Begriffen verbirgt.

Mobile first

Das Designprinzip Mobile first bedeutet nicht etwa, dass unsere Software zuerst oder sogar ausschließlich auf Mobilgeräten laufen muss. Stattdessen geht es darum, beim Entwurf von Eingabemasken oder Funktionen zunächst bei Smartphones und Tablets anzufangen. Dort steht weniger Bildschirmfläche zur Verfügung und die vorherrschende Eingabe über Touchbedienung ist weniger genau als die Eingabe per Maus. Auf Mobilgeräten würde man üblicherweise nur die wichtigeren Informationen anzeigen, Formularsteuerelemente und Schaltflächen größer und mit mehr Abstand zueinander gestalten. Was auf dem Mobilgerät schon gut funktioniert, kann für die Desktop-Ansicht weiter ausgebaut und zum Beispiel um weitere Use Cases ergänzt werden, die auf Mobilgeräten schlichtweg nicht sinnvoll wären. Auch die Größe von Steuerelementen und deren Abstände können hier wieder verringert werden. Somit steht für jede Gerätebauform eine sinnvolle UX zur Verfügung.

Erstrebenswert ist dabei die Verwendung einer einzigen Codebasis für das Frontend. Nicht (nur) deswegen, weil wir Programmierer gerne faul sind. Sondern vor allem, weil sich die Entwicklung von eigenen Frontends für Mobile und Desktop und dann eventuell noch für verschiedene Plattformen für viele Independent Software Vendors (ISVs) schlichtweg nicht rechnet.

Responsive Design in Aktion

Um das Versprechen dieser Single Codebase einzuhalten, benötigen wir ein Frontend, das auf Mobilgeräten wie Desktops gleichermaßen funktioniert. Zur Umsetzung dessen existieren Ansätze wie Adaptive und Responsive Design. Beide haben gemein, dass sie sich den Bildschirmabmessungen anpassen, in den meisten Fällen der zur Verfügung stehenden Breite (siehe Abb.). Die Bildschirmabmessungen werden somit optimal genutzt. Je nach verwendeter Technologie gibt es verschiedene Möglichkeiten, ein solches Layout umzusetzen. Im Umfeld der Universal Windows Apps (UWP) gibt es beispielsweise das Adaptive Layout, das sich an bestimmten Triggerpunkten ändert. iOS hingegen kennt das Auto Layout, um auf Änderungen zu reagieren.

Bekannte Frameworks zur Umsetzung eines Responsive Design in der Webwelt (HTML, JavaScript, CSS) sind Bootstrap oder Foundation. Web- oder Hybrid-Apps bedeuten jedoch nicht zwangsläufig, dass Ihre App auf allen Plattformen und im Web gleich aussehen muss: Mithilfe plattformspezifischer CSS-Anpassungen, allen voran der Verwendung der jeweiligen Systemschriftart (Segoe UI auf Windows, Roboto auf Android, San Francisco auf iOS/macOS) kann man sich der Plattform durchaus angleichen. So arbeitet beispielsweise das HTML-basierte Mobile-App-Framework Ionic. Es kann aber auch eine strategische Option sein, „meine App“ auf allen Plattformen wie „meine App“ aussehen zu lassen. Mit diesem Konzept arbeiten beispielsweise Spotify oder Instagram. Damit wird die Brand Identity über Gerätegrenzen hinweg gewahrt. Beide Ansätze lassen sich auch mischen.

Offline first

Mobilgeräte kann man einfach in die Tasche stecken und mitnehmen. Genau diese neue Freiheit nutzen Ihre Anwender, für uns als Entwickler wirft sie aber ein Problem auf: Längst nicht überall gibt es (stabiles) Internet – jeder, der im Zug mit einem Tablet in der Hand schon einmal durch einen Tunnel gefahren ist, kennt das Problem. An anderen Orten steht vielleicht nur ein Balken EDGE zur Verfügung, einen Meter weiter aber schon die volle LTE-Power. Ärgerlich wäre es, wenn Ihr Anwender bei einer schlechten Internetverbindung Ihre Anwendung nicht mehr sinnvoll benutzen kann. Wünschenswert ist also, dass unsere App auch offline – zumindest im Rahmen der Möglichkeiten – funktioniert.

Microsofts Notiz-Tool OneNote geht mit gutem Beispiel voran: Hier können die Anwender auch ohne Internetverbindung Notizen in ihre Notebooks tippen. Sobald wieder eine Internetverbindung zur Verfügung steht, werden die Änderungen mit OneDrive oder SharePoint synchronisiert. Ganz generell braucht die lokale App also einen eigenen Datenspeicher, der über einen Service mit einem entfernten Datenspeicher synchronisiert wird (siehe Abb.). Da der eigene Datenspeicher bei direkten Web-API-Aufrufen nicht erforderlich wäre, ist die Einführung desselben eine grundlegende Entscheidung und sollte daher ganz am Anfang getroffen werden: Offline first. Ein nachträglicher Einbau ist mitunter hochkomplex und aufwändig. Spannend wird es dann, wenn ein anderer Anwender zur gleichen Zeit Änderungen vorgenommen hat – es also zu einem Konflikt kommt. Wie diese Konflikte aufzulösen sind, ist allerdings hochgradig abhängig von ihren Anforderungen und ihren Use Cases. Es könnte legitim sein, schlicht die neuere Änderung zu wählen oder den Benutzer zur Auswahl einer Änderung aufzufordern, wie es OneNote tut.

Drei Problemstellungen der Offline-Implementierung

Bei der Implementierung solcher Anwendungen ergeben sich drei Probleme. Alles beginnt bei der Erkennung der Konnektivität. Mit absoluter Sicherheit kann lediglich gesagt werden, dass kein Internet verfügbar ist – etwa, wenn das LAN-Kabel gezogen und/oder mobile Datenverbindungen deaktiviert sind. Ob Internet aber verfügbar ist, lässt sich nur durch Ausprobieren herausfinden. In mobilen Netzen kommt die Eigenschaft dazu, dass Round-Trip-Zeiten besonders unvorhersehbar sind. Wer mit dem Smartphone schon einmal durch einen Tunnel gefahren ist, kennt das Problem.

Das nächste Problem ist, die Daten offline zu halten. Alle Daten müssen in einem lokalen Datenspeicher abgelegt sein, auf den über einen lokalen Datenservice zugegriffen werden kann. Der Zugriff auf Daten muss ausschließlich über diesen lokalen Dienst geschehen. Mogeln sich manche Abfragen doch direkt zum entfernten Web-Service durch, bricht die Offlinefähigkeit Ihrer Anwendung an genau dieser Stelle (siehe Abbildung). Dies ist ein beliebter Fehler in der Implementierung von Anwendungen, der je nach Ausmaß nur schwer zu beheben ist. Die Schwierigkeit bei zwei getrennten Datenspeichern ist, diese auf demselben Stand zu halten. Damit kommt also die Synchronisierung ins Spiel und mit ihr die Konfliktbehandlung. Wie Sie sich dieser annehmen, ist wie oben beschrieben durch Ihre Anforderungen bestimmt.

Die dritte Herausforderung ist, Ihre App offline verfügbar zu machen. Das bedeutet, dass alle Abhängigkeiten Ihrer Anwendung auf dem Zielgerät in irgendeiner Form persistiert sein müssen und auch hier kein Nachladen von externen Quellen erforderlich sein sollte. Assets und Abhängigkeiten sollten also vollständig in Ihrem Programmpaket oder App-Bündel liegen. Im Web implementiert man Clients, die offline verwendet werden sollen, oftmals in Form einer Single-page Web Application (SPA) – eines Fat-Client, der ebenfalls alle Abhängigkeiten enthält.

Die Implementierung von Mobile first und Offline first sind also komplexe Szenarien, die von Beginn an bedacht werden müssen. Zu späterem Zeitpunkt sind diese Punkte oftmals nur mit hohem Aufwand zu integrieren. Fällt die Entscheidung zugunsten dieser beiden Paradigmen, müssen sie auch unbedingt eingehalten werden – sonst bricht die UX ihrer Anwendung. Denken Sie daher rechtzeitig über diese Punkte nach. ()