Nachdem wir uns im ersten Teil mit der App als Produkt beschäftigt haben, werden wir uns in diesem Teil der Technik widmen,denn all die Nutzerzentrierung hilft wenig, wenn die Funktionalitäten nicht auch das liefern, was vom Nutzer erwartet wird. Doch was bedeutet eigentlich “Technik” im Kontext einer mobilen App? In erster Linie natürlich die App an sich, also heutzutage entweder iOS oder Android.
Frontend vs. Backend
Diese beiden Technologien sind allerdings nur die Spitze des Eisberges. Eine App ist weit mehr als nur ein natives Frontend. Gerade umfangreichere Apps benötigen häufig eine entsprechende Backend-Infrastruktur. Eine Airline-App beispielsweise kann noch so modern, aufgeräumt und an die Plattform angepasst sein – wenn die Daten, die angezeigt werden sollen, nicht stimmen (oder erst gar nicht erscheinen), hilft auch die benutzerfreundlichste Oberfläche nicht weiter.
Es ist daher wichtig, alle Bestandteile als “Gesamtkunstwerk” zu betrachten und einen Blick dafür zu entwickeln, wo innerhalb dieser Systemlandschaft die einzelnen Bestandteile zu verorten sind.
Komplizierte und rechenintensive Operationen sollten hierbei, so weit wie möglich, im Backend stattfinden, um die mobilen Endgeräte zu entlasten. Ebenso wichtig ist es, sich bewusst zu machen, wie schnell Änderungen und Neuerungen umgesetzt werden können.
Nehmen wir als Beispiel den (nicht gerade realistischen, aber anschaulichen) Fall einer Mehrwertsteuerberechnung. Eine hypothetische Shopping-App zeigt Produkte und deren Preise an. Eine Möglichkeit wäre, nur die reinen Nettopreise vom Backend auf das mobile Endgerät zu übertragen und die App alle zusätzlichen Berechnungen, wie z.B. die Steuerberechnung, selbst durchführen zu lassen.
Eine Konsequenz dieser Entscheidung wäre, dass sobald sich die Regeln zur Steuerberechnung ändern, immer auch ein Update der App notwendig wird (die Berechnungslogiken sind schließlich hart innerhalb der App hinterlegt). Weigert sich der Benutzer allerdings, ein solches App Update auszuführen, werden ihm nun jedoch potentiell falsche Werte angezeigt. Gerade im Falle von Steuerberechnungen kann dies schnell rechtliche Auswirkungen haben, die sich nicht mehr einfach ignorieren lassen.
In diesem kleinen Beispiel ist schnell erkennbar, dass die Steuerberechnung im Backend erfolgen und die App “nur” noch alle berechneten Werte darstellen sollte.
In anderen Fällen ist die Entscheidung nicht ganz so leicht zu treffen, sondern bedarf einer intensiveren Analyse der Vor- und Nachteile. Ist eine Neuberechnung bestimmter Daten auch dann erforderlich, wenn beispielsweise keine Verbindung zum Internet vorhanden ist? In diesem Falle muss die Berechnung direkt auf dem Gerät stattfinden, da schlicht und ergreifend keine Möglichkeit existiert, andere Systeme abzufragen.
Es erfordert daher immer eine Einzelfallbetrachtung, um den besten Platz sowohl für die Verarbeitung, als auch für die Speicherung von Daten zu finden.
Nativ vs. plattformneutral
Gerade große Unternehmen wollen ihre Services auf beiden großen Plattformen, iOS und Android, zur Verfügung stellen. Da hierbei unterschiedliche Technologien (Objective C bzw. Swift auf der einen und Java bzw. Kotlin auf der anderen Seite) zum Einsatz kommen, wird hier – notwendigerweise – mehr Aufwand benötigt als z.B. bei einer Webseite, die auf allen Plattformen im Browser gleich angezeigt wird.
Es wirkt daher verlockend, die App lediglich als Container zu nutzen, um dynamische Webseiten auszuliefern. Was jedoch gerne vergessen wird, ist die Tatsache, dass die mobilen Plattformen nicht nur eine Entwicklungstechnologie voraussetzen bzw. vorgeben, sondern gesamte Interaktionskonzepte. Material Design beispielsweise ist nicht einfach nur eine Sammlung an Komponenten, die zusammengesetzt ein Eingabeformular bilden, sondern eine Designsprache. Die “Human Interface Guidelines” von Apple beinhalten ebenso deutlich mehr als nur einen Satz an Komponenten.
Natürlich ist es möglich, eine App als abgespeckten Webbrowser zu “mißbrauchen” und anstatt eine eigene UI mit nativen Komponenten zu erstellen einen WebView das Rendering erledigen zu lassen, doch widerspricht dies der grundlegenden Idee einer nativen App. Wenn lediglich eine Webseite angezeigt werden soll, wieso wird dem Nutzer dann nicht einfach direkt eine (mobil optimal dargestellte) Webseite angezeigt?
Als Nutzer merken wir zudem relativ schnell, wenn das Design und die Interaktionen innerhalb der App nicht mit der Plattform kompatibel sind. Nach relativ kurzer Zeit bekommen wir ein Gefühl dafür, wie sich eine iOS App oder eine Android App anfühlt. Bewusst und unbewusst erwarten wir bestimmte Muster und Verhaltensweisen, die sich aus dem Design der Plattform ableiten lassen. Weicht eine App von diesen Mustern und Verhaltensweisen ab, so fühlt sie sich für uns nicht mehr “richtig” oder “gut” an.
Der folgende Tweet bringt es auf den Punkt:
Weniger direkt aber genauso verwirrend sind Anpassungen, die bereits auf nativer Ebene erfolgen, aber dennoch zum Ziel haben, die Plattformkonzepte auszuhebeln. Mehr als einmal habe ich gehört “Die Funktionalität muss aber in iOS genauso aussehen wie in Android, damit wir unsere Benutzer nicht verwirren”.
Diese Anforderung ist auf mehreren Ebenen schädlich für das Benutzererlebnis. Zunächst müssen wir uns die Frage stellen, wer denn hier nicht verwirrt werden soll? Die meisten Benutzer haben sich auf eine Plattform festgelegt. Nur wenige Nutzer haben sowohl ein Android als auch ein iOS Gerät und nutzen die gleiche App auf beiden Geräten. Die Zielgruppe ist also relativ klein.
Zudem ist es ein Trugschluss, dass ein Nutzer erwartet, dass eine App überall gleich aussieht. Im Gegenteil: Wie bereits oben erwähnt, erwarten wir bestimmte Muster und Verhaltensweisen von einer Plattform. Wir sind uns auch vollkommen bewusst darüber, dass sich unterschiedliche Plattformen unterschiedlich verhalten. Wir sind uns bewusst darüber (und haben gelernt zu erwarten), dass sich die Benutzeroberfläche von Windows anders verhält als die Benutzeroberfläche von macOS und dass sich eine Desktopoberfläche anders verhält als die Oberfläche eines Handys.
Sehen wir uns das an einem Beispiel an, dem Startscreen der Delta-App auf iOS und Android:
Die Inhalte, die angezeigt werden, sind im großen und ganzen identisch, dennoch gibt es deutliche Unterschiede, die sich auf die Vorgaben und Konzepte der Plattform zurückführen lassen. Während in iOS die Hauptnavigation am unteren Bildschirmrand verordnet ist, findet sie sich auf Android am linken oberen Bildschirmrand hinter einem weiteren Button.
Einem iOS Nutzer die Navigation an der identischen Stelle zu präsentieren wie einem Android Nutzer, würde hier nur zur Verwirrung führen: Er erwartet die Navigation am unteren Bildschirmrand, das er dies von anderen iOS Apps kennt und darauf konditioniert ist, andere Bereiche über eben diese Navigation zu erreichen.
Es ist daher deutlich wichtiger sicherzustellen, dass das Benutzererlebnis einer App kompatibel zur Plattform ist, auf der sie läuft, als sicherzustellen, dass die App der Corporate Identity des Unternehmens gehorcht, komme was wolle.
Gute Nachbarn
Das mobile Erlebnis für den Nutzer lebt von einer Vielzahl an Apps, die eine Vielzahl an Funktionalitäten anbietet und eine Vielzahl an Bedürfnissen abdeckt. Unsere App wird daher nur ein Puzzlestück unter vielen darstellen. Dies gilt es zu beachten und von vorneherein mit einzuplanen.
Ist es wahrscheinlich, dass der Nutzer Inhalte aus unserer App in einer anderen App weiterverwenden möchte? Dann sollten wir es ihm so einfach wie möglich machen, die Daten zu exportieren, um seinen gesamten Fluss besser zu unterstützen.
Wir sollten jedoch niemals erwarten (oder gar voraussetzen), dass andere Apps ebenso gut Nachbarn sind wie wir. Möglicherweise sind Daten und Informationen, die unsere App von einer anderen App erhält, nicht in dem Format oder in der Qualität, die wir erwarten. Es liegt daher an uns zu versuchen, sie dem Nutzer entsprechend aufzubereiten.
Ein Nutzer trennt nicht scharf zwischen einzelnen Apps bzw. einzelnen Funktionalitäten. Es ist ihm egal, ob App A die Daten falsch exportiert oder App B die Daten falsch importiert hat. Für ihn ist die Schlussfolgerung denkbar simpel: “Ich wollte X erreichen. Das hat nicht funktioniert. App A ist daher nicht zu gebrauchen”. Wir müssen also auf Fehlbedienung und fehlerhafte Eingaben (sowohl vom Benutzer, aber auch von anderen Apps) vorbereitet sein und entsprechend reagieren.
Auch wer denkt “Meine Interaktion mit anderen Apps ist minimal” wird sich wundern, welche Seiteneffekte plötzlich auftreten können. Eine wahre Geschichte ist mir vor einigen Jahren passiert. Als technisch Verantwortlicher für die Lufthansa App erreichte mich ein Fehlerbericht, in dem verschiedene Nutzer berichteten, dass sie aus der Lufthansa App plötzlich und ohne irgendwelche bewussten Eingaben in die App eines Lieferdienstes gesprungen sind.
Die Verwirrung in unserem Team war groß: Hatten wir doch keinerlei Integration mit dem beschriebenen Lieferdienst implementiert. Nach langem Suchen standen wir dann aber endlich vor des Rätsels Lösung.
Analog zu URLs, die wir alle kennen, um eine Webseite im Browser über das HTTP Protokoll aufzurufen, also beispielsweise http://www.nasa.gov, existieren für eine mobile App interne Service Links, die es erlauben, einzelne Funktionalitäten einer App aufzurufen. So könnte die Lufthansa App beispielsweise über den Link lh://boardingpass für eine andere App die Möglichkeit bieten, direkt in die Liste der vorhandenen Boardingpässe zu springen.
Das Schema “lh://” kann jede App selbst definieren und damit der mobilen Plattform bekannt geben, dass sie alle Links dieses Schemas behandeln kann. Was nun passiert war, dass nicht nur die Lufthansa App das Schema “lh” belegen wollte, sondern ebenfalls die Lieferheld App. Somit hatten zwei Apps das identische Schema reserviert und in diesem Fall hatte die Lieferheld App “gewonnen”.
Die Lösung hier war relativ einfach, in dem wir das Schema von “lh://” zu “com.lufthansa://” angepasst haben und damit die Chances einer Kollision mit einem anderen Schema deutlich reduziert wurde. Es lohnt sich also auch bei scheinbar einfachen Funktionalitäten zu überlegen, welche Auswirkungen andere Teile der Plattform auf unsere App haben können.
Zukünftige Änderungen mit einplanen
Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen. Das wusste bereits Mark Twain. Alle möglichen Änderungen einer App vorherzusehen ist schlicht und ergreifend unmöglich.
Im Gegensatz zu einer Webanwendung können wir nicht davon ausgehen, dass Änderungen automatisch beim Nutzer ankommen. Selbst wenn eine neue App-Version im Store verfügbar ist, so bedeutet dies noch lange nicht, dass der Nutzer sie automatisch auf seinem Gerät installiert. Verschiedene Gründe können dazu führen, dass noch eine ganze Weile ältere (und möglicherweise nicht mehr unterstützte) App-Versionen auf das Backend zugreifen wollen.
Es ist daher sinnvoll, sich bereits zu Beginn eine Versionierungsstrategie zu überlegen, die definiert, wie zukünftige Änderungen umgesetzt werden können und dennoch die Kompatibilität zu älteren Apps erhalten bleibt.
Quelle: https://de.wikipedia.org/wiki/Datei:Sign_-_Key_-_Glass_(4891398099).jpg
Als eine Art “letzte Verteidigungslinie” sollte es mindestens eine Möglichkeit geben, eine – zu einem späteren Zeitpunkt zu definierende – Meldung an den Benutzer zu senden. Diese “Notfallkommunikation” sollte auf jeden Fall weiter funktionieren, so dass im Fall von Änderungen, die (aus welchen Gründen auch immer) nicht mehr kompatibel zu alten Apps sind, wir dem Nutzer wenigstens eine Nachricht senden können, die beim Öffnen der App erscheint und ihn darüber informiert, dass er mit seiner alten App-Version die Services nicht weiter nutzen kann. Damit wird ihm ein Ausweg geboten (“Bitte die App aktualisieren”), anstatt ihm das schlimmstmögliche Nutzererlebnis zu präsentieren: Eine App, die nicht mehr funktioniert.
Fazit
Bei näherem Hinsehen erkennen wir schnell, dass die User Interface Komponenten und das Frontend der App nur die Spitze des Eisberges ist. Es bedarf einer ganzen Batterie aus unterstützender Technik, sei es das Backend, das die Daten bereitstellt, oder eine Architektur, die es uns erlaubt, Änderungen schnell und unkompliziert umzusetzen. Alle diese Bereiche sollten mit der entsprechenden Sorgfalt analysiert und behandelt werden.
Im letzten Teil werden wir uns mit den Menschen beschäftigen, die dafür sorgen, dass die App auch tatsächlich beim Nutzer landet: Dem Entwicklungsteam und was es bedeutet, ein herausragendes Team für eine herausragende App zu bilden.
Ob beim Schreiben von Code, der Analyse von Anforderungen oder der Ideenfindung mit seinem Team – für ihn geht es nicht nur darum, die "richtige" Lösung zu finden, sondern auch dafür zu sorgen, dass alle Beteiligten den Spaß an ihrer Arbeit behalten.
Ursprünglich von der Technik in der Softwareentwicklung fasziniert, widmet Christian heute einen großen Teil seiner Zeit der Interaktion mit Menschen und setzt sich leidenschaftlich für ein besseres Verständnis zwischen Entwicklungsteams und Business-Stakeholdern ein.
Bei schönem Wetter trifft man Christian häufig auf dem Fahrrad oder beim Joggen im Park. Bei schlechtem Wetter findet man ihn eher auf der Couch, wo er vergeblich versucht, seinen Netflix-Konsum unter Kontrolle zu halten.
