Bits 'n Pieces about Software Development, Mobile Applications and Testing
Ganz offensichtlich waren auch andere Leute der gleichen Ansicht, was die Viadi-App betrifft :-).
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!
Ob eine Lösung für Mobilgeräte gut ist, hängt von einigen wenigen Faktoren ab:
Soweit die Theorie. Nun möchte ich das am praktischen Beispiel aufzeigen.
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.
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.
Kommen wir also nun zur
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!
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!
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:
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.
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.
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!
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
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!
Um im Java- Kontext professionell SW zu entwickeln, gibt es verschiedene Bestandteile, die einfach dazugehören: Unit Testing, Continuous Integration, automatisierte Erstellung von Releaspaketen, Systemtestautomatisierung etc. Das ist – zumindest in dem Umfeld, in welchem ich mich bewege – allgemein akzeptiert und weitgehend selbstverständlich.
Mit dem Schritt in die Welt der SW Entwicklung mit iOS sind nun aber alle diese Errungenschaften in Frage gestellt. Das beginnt damit, dass bereits die Konzepte für die Unit Tests mit der Unterscheidung Logic und Application Unit Tests schlecht verständlich sind und entsprechend nur bruchstückhaft umgesetzt werden. Wer dann den Schritt macht und die verschiedenen Schritte ab command line anstossen will, braucht viel Geduld, Durchhaltewillen und Frustrationstoleranz. Offizielle Tutorials von Apple habe zumindest ich dazu keine gefunden. Da bleibt viel Spielraum für Trial and Error.
Definitiv aufs Glatteis begibt sich, wer dann noch die automatisierten Regressionstests gegen das UI in die continous Integration reinnehmen will. Zwar kann man neuerdings das von Apple zur Verfügung gestellte Tool UIAutomation von der commandline anstossen. Um aber die verschiedenen Funktionsweisen und Parameter zu verstehen, ist man dann schon auf sich selber gestellt. Auf den Befehl man instruments erhält man die wenig befriedigende Antwort No manual entry for instruments.
Der Eindruck, der unweigerlich dabei entsteht, ist, dass die SW-Entwicklung für iOS einfach alles beiseite lässt, was sich an Best Practices in anderen Gebieten etabliert hat. Liegt das daran, dass die Programmiung von iPhone Apps primär die Nacht-und-Nebel-Aktion von 1-Personen-Teams ist, die ihre App mal schnell zusammenstricken? Oder sind einfach die Tools noch nicht soweit, weil Apple den Fokus auf andere Bereiche legt?
Gedankensplitter, Links, Ideen zu Software Entwicklung, Mobiile Applications und Software Testing.
Dieser Blog stammt von Thomas Briner-Lienhard , Software Engineer bei Ergon Informatik in Zürich.
9th sphere web design
Comment