Eine mobile App, wie sie sein sollte (Fortsetzung)

Mar 17
2017

Ganz offensichtlich waren auch andere Leute der gleichen Ansicht, was die Viadi-App betrifft :-).

https://www.ubique.ch/blog/SBB/

Sie ist nun Teil der offiziellen SBB App geworden und hat damit ein breites Publikum erreicht.

Wenn es wirklich auf Geschwindigkeit ankommt, bleibe ich zwar immer noch lieber bei der ursprünglichen Viadi App. Weshalb? Ganz einfach: Es braucht einen Tap weniger, den ich in der SBB App verschwenden muss, um zum Viadi-Mechanismus zu kommen.

Und ein Tap zählt im mobilen Kontext!

Eine Mobile App genau so, wie sie sein soll: Viadi

Mar 11
2015

Ob eine Lösung für Mobilgeräte gut ist, hängt von einigen wenigen Faktoren ab:

  •  Fokussierung: Der Anwendungsfall, für welchen die Applikation gemacht ist, muss messerscharf umrissen sein.
  • Beschränkung: Die wichtigsten Abläufe sollen optimal unterstützt werden. Die 80-20 Regel ist hier das Mass aller Dinge (oft reicht sogar auch 70-30). All die komplizierten Spezialfälle, die nur selten gebraucht werden, werden nicht unterstützt.
  • Nutzung der Gerätespezifika: Mobilgeräte haben Stärken, die eine App unbedingt nutzen muss. In erster Linie sind das die offensichtlichen Möglichkeiten der Nutzung von Geolocation, Kamera oder Mikrofon, sowie die Verknüpfung mit Kalender und Kontakten. Daneben ist es aber auch entscheidend, die Bedienung auf die Interaktion via Touchscreen auszurichten. Damit wird eine Applikation viel direkter, unmittelbarer und intuitiver spür- und benutzbar.
  • Perfektionierung: Innerhalb diesea klar definierten Scopes muss die App dann perfektioniert werden. Das beginnt bei der Benutzerinteraktion, indem jeder überflüssige “Tap” eliminiert wird und geht bis zur grafischen Gestaltung, die für den Gesamteindruck entscheidend ist.

Soweit die Theorie. Nun möchte ich das am praktischen Beispiel aufzeigen.

Die Aufgabe heisst: Gestalte eine Fahrplan-Applikation für den öV auf dem Mobilgerät.

 


 

Lösung 1: Die mobile Website der SBB

 

Ich bin zwar in der Lage, für meinen Heimweg aus dem Geschäft bis zur gewünschten Haltestelle vor der Kita eine entsprechende Verbindung herauszufinden, aber es ist harzig. Ich muss auf der Tastatur tippen, bis ich den vollen Namen der entsprechenden Haltestelle eingetippt habe. Keine Vorschläge, keine Nutzung des eigenen Standorts. Das Resultat ist zwar ok, aber der Weg dahin ist unerfreulich.

Foto 10.03.15 21 16 35  Foto 10.03.15 21 16 43


 

Lösung 2: Die SBB-Mobilapplikation

 

Hier ist schon einmal ein Quantensprung spürbar gegenüber der mobilen Website. Es fühlt sich viel direkter und responsiver an und es gibt auch schon erste Schritte in die richtige Richtung: Ich kann den Standort direkt einbeziehen und der “Take Me Home”-Button ist nett. Aber auch hier tippe ich wieder, und wehe ich vergesse das Komma zwischen Ortschaft und Haltestelle. Dann wird die Zieldestination nicht gefunden. Ich habe zwar die Möglichkeit, im Verlauf alte Suchabfragen aufzuspüren oder sie in den Favoriten zu organisieren, aber übersichtlich ist beides nicht.

Foto 10.03.15 21 17 27   Foto 10.03.15 21 18 28

 


 

Kommen wir also nun zur

Lösung 3: Die Applikation Viadi

 

Und hier ist nun wirklich alles comme il faut. Die Applikation ist klar fokussiert: Es geht darum, eine begrenzte Anzahl von Abfragen, die ich immer wieder machen muss, so effizient wie möglich umzusetzen. Die Abfragen sind auf elegante Weise grafisch umgesetzt. Die Benutzung ist extrem  intuitiv. Die Möglichkeiten von Location und Touchscreen werden konsequent genutzt. Und es ist offensichtlich, dass hier wirklich getüftelt wurde, um die Applikation und im Besonderen die Benutzung zu perfektionieren.

Ich benötige etwas Konfiguration, bevor ich die Applikation nutzen kann, aber die zu machen bin ich nur zu gerne bereit. Ich hinterlege meine Ziele in Form von Kacheln, die ich so gestalten kann, wie ich will: Grösse, Platzierung, Text, Bild – alles nach meinem Gusto. So werden also Arbeitsort, Wohnort, die relevantesten Ortschaften, Kita, Grosseltern etc. alles hinterlegt.

Nach dieser initialen Konfiguration bin ich bereit, um nun die Verbindungen abzufragen, indem ich einfach mit dem Finger einen Strich von der Start- zur Zielkachel ziehe. Und schon bekomme ich die Verbindungsvorschläge. Zeitaufwand: Sekundenbruchteile. Toll!

Foto 10.03.15 21 15 18   Foto 10.03.15 21 15 23

Und als Option habe ich sogar auch noch die Möglichkeit, beliebige Suchabfragen, welche über meine gespeicherten Kacheln hinausgehen, mit den gleichen Mitteln zu stellen, wie bei Lösung 2. Apropos Beschränkung: Mit den 4×4 Kacheln habe ich die Möglichkeit, maximal 16 x 15 = 240 verschiedene Verbindungen mit Fingerstrich abzufragen. Das ist eigentlich auch schon eine ganze Menge…

Der Punkt, in welchem ich noch Verbesserungspotential sehe, ist die Konfiguration der Kacheln. Hier wäre es schön, noch eine bessere Unterstützung für das Hinterlegen der Kacheln zu haben, z.B. mit indem direkt nach der Auswahl der Haltestelle Bilder aus der Umgebung via Google Places oder Beschriftungen von Restaurants, Institutionen, Firmen, etc. im nahen Umkreis vorgeschlagen zu bekommen. Das würde den Spass beim Hinzufügen von weiteren Start- und Zielpunkten noch erhöhen. Auch die Auswahl eines Kontaktes anstelle einer Haltestelle, wobei die App dann direkt die nächste Haltestelle ermittelt und das Foto des Kontaktes als Visualisierung verwendet, wäre elegant.

Über alles gesehen ist Viadi für mich wirklich das Werkzeug der Wahl, wenn es darum geht, die öV Verbindungen abzufragen, die ch ich in meinem Alltag brauche, und darüber hinaus ein exzellentes Beispiel, wie eine mobile Applikation realisiert werden sollte. Gratulation an die Hersteller. Und vielen Dank, Kai @warszas, für den tollen Tipp!

iOS8 Probleme mit der Orientation – Querformat und Hochformat gemischt

Feb 16
2015

Bei unseren mobilen Lösungen haben wir an verschiedenen Stellen Probleme mit der neusten iOS Version festgestellt, wenn es darum geht, eine App in Hoch- und Querformat richtig darzustellen.

Dass dies nicht nur bei eigenen Lösungen so ist, sondern dass auch Apple selber mit den gleichen Schwierigkeiten kämpft, hat mich etwas amüsiert…

So kommt auf meinem iPad Air2 mit iOS 8.1.2 bei der Suche im Querformat die Tastatur im Hochformat reingeschlittert:

Und noch eine Randbemerkung: Meist ist bei den Issues die Schwierigkeit, sie zu reproduzieren. Nicht so in diesem Fall: Hier schaffe ich es nicht, das Problem wieder zum Verschwinden zu bringen 🙂

 

Testing-Rätsel im Migros HB ZH: Die bzw. eine Lösung

Jan 22
2015

Andreas hat es in seinem Kommentar genau so beschrieben, wie ich es auch gemacht habe: Der leere Knopf auf dem Screen, bevor die Karte im Terminal eingeschoben wird, ist das Problem. Herzliche Gratulation! Du hast das Rätsel gelöst!

Ich bin davon ausgegangen, dass es nur funktioniert, wenn das Benutzerinterface möglichst schnell immer auf diesem Knopf rechts unten traktiert wird. Das würde dann etwa der Obsessive-Compulsive Tour entsprechen, wie sie James Whittaker in seinem Buch “Exploratory Software Testing” beschreibt.

Aber heute habe ich es jetzt noch in Slowmotion probiert, und es funktioniert auch so: Der Knopf rechts unten ist zwar leer, aber er reagiert trotzdem noch auf Klicks – und siehe da, schon kommt die Fehlerseite.

Interessant an diesem Fehler ist, dass der Fehler nicht darin besteht, dass etwas nicht funktioniert, was vom Kunden so verlangt wurde, sondern, dass etwas Zusätzliches in der Software enthalten ist. Das ist ein Pattern, das häufiger vorkommt, dass Software Funktionalität aufweist, die über die Spezifikation hinausgeht. Verhältnismässig häufig sind Sicherheitslöcher in diesen Teilen zu finden, die eben zusätzlich zur Spezifikation in der Software vorhanden sind. Und die sind im Testing unglaublich schwierig zu finden.

Zusammenfassend: Sicher kein schlimmer Fehler, ich sehe auch keine unmittelbaren Auswirkungen. Nichtsdestotrotz wäre eine explorative Testsession auf dieser Software sicher keine verlorene Zeit. Und einmal mehr überraschend, dass auch eine vom Workflow her nicht unendlich komplexe Applikation eben doch nicht ganz wasserdicht getestet wurde.

Nun noch eine kleine Anmerkung:

Unmittelbar nachdem ich dieses Rätsel publiziert habe, kam auch schon die Meldung von @Migros via Twitter.


Chapeau, wirklich beeindruckend, nicht nur die Data-Mining-Algorithmen funktionieren, sondern die Analyse der Treffer ist auch beeindruckend schnell!

Testing-Rätsel im Migros HB ZH

Jan 15
2015

Hier ein kleines Testing-Rätsel für alle, die gerne Software überlisten:

Die Subito-Terminals – die Self-Service-Kassen im HB ZH – haben unterdessen eine ziemlich ausgereifte Software, die einen effizienten Ablauf ermöglicht. Ich habe aber doch noch eine Möglichkeit gefunden, mit der deterministisch ein Fehler herbeigeführt werden kann:

MigrosHB_ZH_Testing_Raetsel

 

Wer kann diesen Fehler reproduzieren?

Die Antwort darauf kommt in einer Woche hier im Blog. Viel Spass beim Experimentieren 🙂

 

Why do some people like programming?

Jul 25
2013

Marcus Geduld hat diese Frage auf Quora für sich beantwortet – und mit jedem Abschnitt, den ich weiter gelesen habe, wuchs meine Überraschung, wie genau seine Antworten sich mit denen decken, die ich auf diese Frage jeweils gebe. Nur dass seine Antwort um Längen genauer und schöner formuliert ist als meine Versuche.

Insofern einfach unkommentiert seine Aussage. Enjoy it!

  • I like creating something out of nothing. That’s not literally what you do when you’re programming, because there’s existing hardware and software that serves as a foundation for your work, but it sure feels that way. Someone has an idea and you build it from the ground up. When you begin, there’s just an empty text editor. When you’re done, there’s a (hopefully) working program.
  • I like building things people use. It’s amazing to type up some code, press a button, and suddenly thousands of people on the Internet are playing with it.
  • I like playing God. Programming allows you to build little worlds and then play with them, making adjustments and watching the effects. It’s like owning a toy planet and saying, “I’m going to make it rain, today. Oh, look! All the little people have opened umbrellas!” This playing-God aspect of programming makes it similar to writing novels, painting paintings, or directing plays.
  • I like working within systems that demand precision. This is exactly what some people hate about programming, but it thrills me. A misplaced semicolon or the smallest typo can be disastrous. This keeps me on my toes. It’s like being the butler on “Downton Abbey” or “Upstairs, Downstairs.” Everything must be just so. Some people like precision; others like being about to say, “I can’t describe it, but you know what I mean…” I’m the former type.
  • I like research. Programming tends to involve much googling and reading through documentation.
  • I like experimenting. There’s a large component of trial-and-error.
  • I like writing poetry, which is very similar to programming. Both the poet and the programmer are obsessed with words, obsessed with formal rules, obsessed with seeing how far they can push those rules, and obsessed with expressiveness. Programmers often talk about how expressive a particular programming language is. They mean something very similar to what a poet means when he tries to come up with expressive wording.Both poetry and code can be exquisitely beautiful — and in very similar ways. People are often surprised that I’m a programmer who also directs Shakespeare plays, but I’ve met lots of programmers who are into Shakespeare, crossword puzzles, scrabble, and so on. Joshua Engel is another Quora user who writes code and directs Shakespeare plays.
  • I like communicating. Most good programmers will tell you that code is first-and-foremost meant to be read by people — even to the extent that we’ll sometimes write it in a way that is inefficient but easy-to-read.
  •  “There are only two hard things in Computer Science: cache invalidation and naming things.” — Phil Karlton. I love the hard work of “naming things.” Programmers generally have to come up with short words or phrases that label parts of the systems they’re writing. It’s crucial that these names be clear and apt.Why? Because if you name something cButton, the next guy who has to work on your code may be befuddled. If you’d called it closeButton, he would have instantly known what you were referring to. Sometimes “he” is me a few weeks (or a year) later, when I’m reading my own code. It’s embarrassing to come across cButton and think, “What did I mean by that?”Last week, I was modifying someone else’s code. It was for as web page with sections. Each section had a logo at the top. The original programmer had referred to those logos internally as “headers,” e.g. “header1” and “header2.” I didn’t notice that, and so I named something within one of the sections “header.” When I later looked over the code, I got totally confused between his headers and mine.Then I thought it over and realized that his “headers” were always graphical logos and mine were text. So I renamed his “logo1” and “logo2” and mine “title.”This is just one small example of the sort of naming issues that constantly crop up. You either enjoy this sort of thing or you don’t. I do.
  • I like learning. Like sharks, programmers die if they stop moving. Because technology changes so fast, being a programmer means that “school” never stops. Even though I’ve been coding for years, I must constantly read programming books, follow blogs, and so on. There’s no coasting!I got into the game as a Flash programmer, which was lucrative for about ten years. Now Flash seems to be on its way out, so it’s back to the books! But even while I was mostly coding Actionscript (Flash’s language), I needed constant training, because that language went through many versions, some as different from each other as Spanish is from Portuguese.There are many good programming books and courses, but you can’t really learn to code by instruction. That will get you started, but they only real way to learn is to write code, fail, analyse the failure, and learn from it. So you must enjoy being an autodidact. I do.
  • I like being a detective. Maybe 60% of programming is debugging — figuring out how something works. That often means a ton of sleuth work. Sometimes you have to pick and entire program apart and put it back together again.
  • I like solitary work. Programming allows me to do lots of that.
  • I like collaborating. Nowadays, Few programmers work completely alone. Most are part of a team, and they spend part of the week doing close work with others and part in isolation. I feel a strong need for both sorts of work, and I like alternating between the two.

BYOD ohne Kopfschmerzen für die Verantwortlichen

May 15
2013

​Die Problematik ist allgegenwärtig und wohlbekannt: Die Mitarbeitenden einer Organisation bringen ihre privaten mobilen Geräte mit in die Firma und wollen sie auch für geschäftliche Arbeiten nutzen.

Im Prinzip ist BYOD eine Win-Win-Situation: Die Organisation kann von der Infrastruktur und dem Knowhow des Mitarbeitenden direkt profitieren und der Mitarbeitende hat seine Umgebung, die er kennt und mag, auch in der Firma zur Verfügung, um die Arbeiten mit den Werkzeugen auszuführen, mit denen er am effizientesten ist. Soweit wäre also alles gut. Wäre da bloss nicht die Fragen der Vertraulichkeit und Datensicherheit…

Was geschieht mit einem verlorenen Smartphone? Oder ist es ein Problem, wenn der kleine Sohn beim Spielen mit dem iPad versehentlich in die geschäftlichen Mails hineingerät? Und wenn er dummerweise auf den “Weiterleiten”-Knopf kommt und ein vertrauliches Mail ans ganze Adressbuch schickt? Natürlich lassen sich beliebige weitere solcher mehr oder weniger wahrscheinlichen Szenarien konstruieren. Und irgendwann wird auch eines eintreffen und die Folgen können gravierend sein.

Eine Einbindung ins geschäftliche Netz mit den entsprechenden Sicherheitsnormen – komplizierter Gerätesperrecode, Option der Fernlöschung durch die Firma, usw. – sind hohe Hürden, mit denen ich als Mitarbeitender mich nicht oder nur zähneknirschend bereit erkläre. Schliesslich ist es mein privates Gerät und ich gebe damit die Oberherrschaft aus der Hand.

Es muss doch eine andere Lösung geben als nur das “Ganz-oder-gar-nicht”!
Blackberry hat in seinem neuen Betriebssystem die Funktion Balance integriert, die eine saubere Trennung zwischen geschäftlichen und privaten Apps und Daten erlaubt. Samsung ist beim neuen Galaxy S4 mit der Technologie Knox den gleichen Weg gegangen und hat Android – das Betriebssystem, welches für Geschäfte häufig als besonders problematisch wahrgenommen wurde – um eine solche Trennung erweitert. Nun bleiben noch die anderen grossen Player Apple mit iOS und Microsoft mit Win8, die wohl auch nicht mehr lange ohne eine solche Lösung auskommen werden.

Es zeichnet sich jedenfalls jetzt bereits ab, dass das ein vielversprechender Weg ist, um die Lawine der privaten Geräte, die sich in den geschäftlichen Kontext ergiesst und nicht zu stoppen sein wird, zu kontrollieren. So kann das BYOD-Setting, das ja wie gesagt als vielversprechende Möglichkeit begonnen hat, nun mit ruhigem Gewissen und ohne Kopfschmerzen für die Verantwortlichen sein Potential entfalten, ohne zum Sicherheitsrisiko zu avancieren.

Mobile UI Design – Wie kann ich ein heisses UI erstellen?

May 09
2013

Das Benutzerinterface (User Interface, kurz UI)  ist bei mobilen Applikationen definitiv einer der entscheidenden Erfolgsfaktoren. Die Benutzer sind sich einen hohen Standard gewohnt und fordern diesen – im Gegensatz zum Umgang mit Geschäftsapplikationen auf dem Desktop – auch ein.

Wie kann nun ein UI ​erstellt werden, welches die Benutzer anspricht und optimal zu einer Lösung passt. Wie bei der Frage, ob ein Musikstück letztendlich zu einem Hit wird oder nicht, gibt es keine Garantie, indem man “alles richtig” macht, auch einen Volltreffer zu landen. Trotzdem gibt es etliche harte Fakten, die berücksichtigt werden müssen, damit ein UI überhaupt das Potential zu einem solchen Volltreffer haben kann. Diese Fakten habe ich in folgende grafische Darstellung verpackt.

UI-Design
Viele mobilen Applikationen sind weit unter dem Gefrierpunkt – also schlichtweg unbrauchbar. Das liegt dann aber nicht in erster Linie am UI, deshalb heisst die Aufforderung hier: Focus! Nur wenn der Umfang und die Ziele der Applikation vollkommen klar sind und sich die Lösung wirklich darauf beschränkt, ist es möglich, ein gutes UI für eine Applikation zu erstellen.

Damit kann dann ein UI entstehen, mit dem man zwar das Richtige tun könnte, aber eben, es ist immer noch unbenutzbar. Hier heisst der nächste Schritt: Design for Mobile! Unter Beachtung der Ergonomie und er wichtigsten Layoutregeln kann damit ein UI entworfen werden, das wirklich zum mobilen Gerät passt.

Nun gibt es viele Benutzeroberflächen, mit denen man zwar arbeiten kann, die aber uneinheitlich, unprofessionell und zusammengebastelt wirken. Hier hilft Keep to the Code! (nicht nur für Piraten ;-)). Das bedeutet die konsequente Benutzung von Standard Elementen gemäss den Richtlinien, wie sie z.B. in den jeweiligen Human Interface Guidelines (z.B von Apple oder Windows) festgehalten sind.

Die Darstellung gemäss den Vorgaben reicht aber noch nicht aus. Auch das Verhalten muss für den Benutzer so sein, wie er sich das eben gewohnt ist, sonst ist die Bedienung unintuitiv und ungewohnt. Dagegen hilft Be Predictable! Das bedeutet, dass auch das Verhalten analog den Standards ist und der Benutzer zu allen seinen Aktionen auch ein entsprechendes visuelles Feedback bekommt, um festzustellen, was nun im Hintergrund passieren wird.

Damit überschreiten wir immerhin schon einmal den Gefrierpunkt, sind aber noch weit davon entfernt, ein heisses UI erstellen zu können. Die Gefahr besteht natürlich, wenn alles gemäss den Standards und Richtlinien realisiert wird, dass die Applikation dann langweilig und hässlich daher kommt. Deshalb nun die Aufforderung Stand Out! Zeig, was das Besondere bei dir ist. Hier kommt die graphische Gestaltung zum Zug, die mit dem entsprechenden Können und der Sorgfalt umgesetzt werden muss.

Schönheit ist aber nicht alles – ebenso wichtig sind Umgangsformen, sonst werden die Benutzer nicht gern damit arbeiten. Dazu gehören sorgfältige Überlegungen, wie für einen Erstbenutzer der Start aussehen soll, ohne unnötige Vorbereitungsschritte, aber mit der benötigten Unterstützung. Daneben braucht es ein besonderes Augenmerk darauf, den Benutzer in seinem Fluss nicht mit unnötigen Popups und Dialogen zu bremsen und hinauszureissen, sondern die Arbeit dezent zu unterstützen. Eben Be Polite!

Damit sind wir schon nahe an einem wirklich guten UI dran. Nun braucht es noch den Schliff für den Poweruser, da die App sonst eben nicht effizient bedienbar ist. Hier soll die Entwicklung des UI aus dem Vollen schöpfen, um z.B. mit Hilfe von Gesten effiziente Arbeitsweisen für geübte Nutzer anzubieten. Use the Force! Die Gesten müssen natürlich sehr sorgfältig gewählt werden, passend zu den Metaphern und basierend auf dem Verhalten, das sich der Benutzer von anderen Applikationen gewohnt ist.

Tja, und damit wäre nun also vieles richtig gemacht. Die Chancen, für ein wirklich gelungenes UI sind damit sicher schon sehr gut. Und wenn es dann noch gelingt, den Benutzer zu überraschen, dann ist die Ausgangslage für einen grossen Wurf sicher optimal.

Ps: Natürlich sind diese Punkte zu einem schönen Teil auch übertragbar auf andere UIs als nur für mobile Geräte!

Testing goes Mobile

May 07
2013

Nun war wieder längere Zeit Funkstille in diesem Blog… Natürlich hängt das damit zusammen, dass in intensiven Zeiten der Blog als einer der ersten unter die Räder kommt. Es hat aber auch viel damit zu tun, dass ich mich beruflich nun seit 2012 neu schwergewichtig mit der Entwicklung von mobilen Lösungen auseinandersetze.

Ebenfalls ein unglaublich spannendes und dynamisches Thema! Natürlich ist das Testing gerade auch für mobile Lösungen ein grosses Feld, das immer noch ein Mauerblümchendasein fristet und auf intensive Beackerung wartet. Darüber werde ich versuchen, in Zukunft vermehrt zu berichten. Ab und zu werde ich mir aber auch erlauben, interessante Themen aus dem Feld Mobile Computing einzustreuen, die wenig oder keinen direkten Bezug zum Testing haben. Insofern willkommen bei der Symbiose aus Testing und Mobile oder eben: Testing goes Mobile

Mobile und Cloud – eine Kombination, die sich aufdrängt

Mar 19
2013

​An der Mobile Tech Conference 2013​ in München, die ich letzte Woche besuchen konnte, gab es eine Session zu Mobile & Cloud. Dass diese beiden Teile gut zusammenpassen, war mich auch vorher schon klar. Wie gut diese Kombination aber eben spielt und wie zwingend sie ist, wurde mir aufs Neue klar.

Die beiden Teile ergänzen sich dabei bezüglich ihrer Rolle einfach ideal: Cloud ist der Katalysator, der Enabler, der das ganze Schauspiel erst möglich macht. Cloud ist aber noch kein Nutzen, kein Anwendungsfall. Leute kaufen keine Clouds, Leute kaufen Lösungen. Und da setzt der Teil Mobile ein. Mobile ist der Driver, das sichtbare Werkzeug, welches das Potential der dahinterliegenden Cloud nutzbar macht.

Die Kombination Cloud & Mobile ist dabei nicht einfach eine weitere Variation der altbekannten Client-Server-Architektur. Der Client muss auch autonom sinnvoll arbeiten können. Statt dem Request-Response Pattern kommen andere Mechanismen zum Zug. Der Client muss sich zumindest einen sinnvollen Ausschnitt der Daten selber halten und damit kommen andere Kernfragen in den Vordergrund. Wie findet eine Synchronisation statt? Wie gehe ich mit Merge-Konflikten um? Wie erkenne ich veraltete Daten?

Cloud & Mobile ist eine fantastische Kombination, aber beileibe keine einfache Lösung. Die Knacknüsse gehen von Verbindungsproblematiken über die Sicherheitsbereiche bis hin zur Skalierbarkeit auf Backendseite.

Als letztes möchte ich noch auf einen Punkt beim UI eingehen: Auch hier ergeben sich durch das erwähnte Zusammenspiel zwischen Cloud & Mobile neue interessante Fragestellungen. Die Asynchronizität, die in dieser Architektur fix drin steckt, z.B. bei der Synchronisation, stellt auch neue Anforderungen an das Benutzerinterface. Die herkömmlichen Designansätze mit Wireframes etc. basieren stark auf der Annahme, dass am Anfang einer Änderung am UI eine Aktion des Benutzers steht. Das stimmt nun nicht mehr. Wie soll der Benutzer zB über einen Konflikt informiert werden, der während der Synchronisation im Hintergrund auftritt? Wenn ich ihm einen Dialog aufpoppen lasse, wie das sonst bei Schwierigkeiten, die ich dem Benutzer mitteilen will, üblich ist, so reisse ich ihn mitten aus irgendeinem anderen Ablauf heraus. Ich muss also Wege finden, seine Arbeit nicht zu stören, ohne ihm Informationen vorzuenthalten.

Mobile & Cloud: Eine Kombination mit ganz viel Potential, aber definitiv kein Quick Win, der eben mal schnell realisiert werden kann. Ich freue mich darauf, über solche Lösungen bezogen auf die Abraxas nachzudenken!

Categories