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!

Professionelle SW-Entwicklung für iOS – ein Widerspruch?

Mar 30
2012

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?

Überleben als embedded Tester im Scrum Team

Mar 15
2012

Am Swiss Testing Day vom 14.3.12 habe ich diesen Talk zum Thema “Überleben als embedded Tester im Scrum Team” gehalten.

Das Interaktionsgeflecht habe ich mit den Seilen im Laufe des Talks erarbeitet. Die Reaktionen waren sehr gut. Ich hatte einige spannende Gespräche zu verschiedensten Punkten aus Methodik, Tooling, Staffing etc. Hier ist das Handout des Vortrags: Ueberleben_als_embedded_Tester_im_Scrum_Team_120305_Handout.pptx

Embedded Testing in Scrum

Jan 14
2012

Als Teammitglied mit dem Fokus Testing im Scrum Team drin. So macht es meiner Meinung nach Sinn. So sind die Wege wirklich kurz, Bugs werden gefunden und gefixt mit minimalem Overhead und ich bin als Tester wirklich embedded – mitten im Team drin. Soweit die guten Neuigkeiten.

Die Schwierigkeiten, die wir zuvor mit konventionellen Testphasen nach der Implementierungsphase hatten, sind aber natürlich nicht verschwunden. Wie erfahre ich, was wirklich implementiert wurde und was Req Engineering und Entwicklung noch bilateral abgesprochen haben? Wie vermeide ich Doppelspurigkeiten zwischen Test auf verschiedenen Stufen – üblicherweise Integrationstest, die der Entwickler in JUnit schreibt und meinen automatisierten Systemtest?

Basierend auf einem Workshop bei Janet Gregory  haben wir zwei Synchronisierungspunkte in unserem Prozess eigeführt zwischen dem Entwickler und dem Tester eines bestimmten Features:

Das Meeting “Share-Test-Ideas” zur Absprache, wer welche Tests macht. Diese Synchronisierung findet bevor oder zu Beginn der Umsetung eines Features statt.

Und dann noch die “Show-Me-Session” sobald das Feature testbar und im Nightly Build drin ist, um zu besprechen, was nun wirklich realisiert wurde.

Diese Klammer um die Umsetzung bewirkt zwar keine Wunder, bringt aber enorm viel für die Zusammenarbeit und die Effizienz.

Im März 2012 werde ich am Swiss Testing Day einen kurzen Vortrag zu diesem Thema halten: Überleben als Embedded Tester im Scrum Team -Heisse Drähte, enge Verknüpfungen und gordische Knoten

 

Code Coverage – Wieviel ist genug?

Aug 04
2010

Im Google Testing Blog habe ich heute einen fantastische Parabel zur Frage gelesen, wieviel code coverage ausreicht. Viel Spass beim Lesen!

“Testivus on Code Coverage”

Notfalleinsatz im Software Testing

May 01
2010

Im Blog von James Bach (dem Autor des Artikels “Test Automation Snake Oil“, in dem ich immer wieder neuen Input zum darüber Nachdenken entdecke) habe ich ein Video gefunden, das mich einfach begeistert hat.

  • Steve McQueen:  Unit Tests?
  • Other man: They’re not working on 81.

Hier ist es:

Einfach cool, ist es nicht?

Funktioniert die Clean-Code-Developer Methode?

May 07
2009

Beim Stöbern im Netz bin ich über die Website http://www.clean-code-developer.de/ gestolpert.

Da hat es sehr viele interessante Ideen und jede Menge Best Practices, die ich sofort unterschreiben würde (Source Code Conventions, Unit Testing, Code Coverage Analyse, Continuous Integration). Es ist eine Mischung von Software Entwicklungs- und Software Testing-Vorgehensweisen.

Das Ganze ist verpackt in eine Methodik mit Kampfsport-Anlehnung mit verschiedenen Gürteln (von schwarz über gelb bis weiss). Die verschiedenen Grade können in einer fixen Reihenfolge nach jeweils einem Minumum an Trainingstagen erworben werden. Als Kennzeichen für einen bestimmten Grad gibt es dann ein Armband.

Banner Clean Code Developer

Mich würde jetzt vor allem interessieren, ob die Methode mit dem ganzen Drumherum funktioniert. Kennt jemand jemanden, der jemanden kennt, der das so umsetzt?

Categories