Wie kommt es eigentlich, dass iOS-Anwendungen – einige wenige Ausreißer ausgenommen – gut aussehen und auch noch intuitiv zu bedienen sind, während Android-Apps häufig einen eher technischen Fokus besitzen und ein gutes User-Interface (UI) für sie ein Fremdwort zu sein scheint? Warum muss man sich bei Android-Anwendungen immer wieder mit neuen, angeblich innovativen Bedienkonzepten auseinander setzen, anstatt auf gewohnte UX-Patterns zurückgreifen zu können?

Zugegeben: In der jüngsten Vergangenheit hat sich das ewige Dilemma um schlechte und inkonsistente Android-UIs ein wenig relativiert (siehe spätere Ausführungen). Trotzdem scheint Android auch bei stark wachsendem Marktanteil in diesem Punkt iOS weiterhin klar unterlegen zu sein. Fragt man den klassischen Android-Entwickler – der übrigens in der Regel aus dem Lager der Java-Web- oder Java-Enterprise-Developer stammt und nicht aus dem der Mobile Developer oder Designer – so wird schnell klar, wo das Problem zu suchen ist: Android ist seit jeher eine relativ offene Plattform. Sie unterstützt den Entwickler zwar bei seiner täglichen Arbeit gut, aber eben nicht ausreichend.

Die Freiheit, App- und UI-Designs so zu gestalten, wie es dem Entwickler beliebt, führt nicht selten zu schlicht unbrauchbaren Anwendungen. Dass das so nicht sein muss und Android-Anbieter Google etliche Hilfsmittel zum Erstellen wirklich guter Apps zur Verfügung stellt, zeigt dieser Artikel. Zunächst aber noch einmal einen Schritt zurück zu den technischen Grundlagen des Android-User-Interface.

Ein typisches Android-UI wird in einer XML-Datei angegeben. Es kann mehrere, ineinander verschachtelte Layouts enthalten – und innerhalb dieser Layouts mehrere Views wie Textfelder, Buttons und vieles mehr. Layouts und Views lassen sich dabei über zusätzliche Attribute stylen. Größe, Farben, Abstände und anderes kann man in der Regel relativ oder absolut einstellen. Es gibt auch entsprechende Editoren, die die Entwickler bei der Gestaltung des UI unterstützen (siehe Abbildung).

Möchte man ein UI-Element zur Laufzeit anpassen, so lässt es sich über eine selbst vergebene ID programmativ in Java referenzieren und mit den gewünschten Attributwerten belegen. Dies geschieht in der Regel in einer Activity – also einer Klasse, die den Life-Cycle eines UI-Screens verwaltet. Soweit die Theorie.

Wie in vielen anderen Bereichen auch sollte man die Style-Informationen auch bei der Android-Entwicklung nicht direkt im Layout, sondern in eigenen Style-Ressourcen angeben. Styles lassen sich dabei sowohl vererben als auch zu Themes gruppieren. Android gibt bereits eine ganze Anzahl von Themes vor, die viele vorinstallierte Google Apps auch verwenden. Nicht selten hängt es jedoch von der Android-Version eines User-Geräts ab, ob ein Standard-Theme vorhanden ist.

Neben den bereits erwähnten Styles kann man auch Texte, Bilder, Animationen, Menüs, Farbdefinitionen, Layouts, XML- oder (X)HTML-Dateien innerhalb so genannter Ressourcen auslagern. Den Ressourcen kommt in Android allerdings noch eine weit wichtigere Aufgabe zu, als lediglich die UI-Informationen zu verwalten. Mit ihrer Hilfe kann man gezielt auf die zur Laufzeit identifizierte Android-Version und vorliegenden Geräteeigenschaften reagieren. Wie das?

Android-Ressourcen liegen in vorgegebenen Ordnerstrukturen. Jeder Ordner kann dabei mehrfach vorkommen und über einen Qualifier genauer spezifiziert werden. Nehmen wir als Beispiel den Ordner „drawable“, in dem – gemäß der Android-Namenskonvention – die Bilder der Anwendung liegen. Soll je nach Auflösung unterschiedliches Bildmaterial zum Einsatz kommen, lässt es sich in entsprechenden Ordnern ablegen:

• drawable-xhdpi (ca. 320dpi)
• drawable-hdpi (ca. 240 dpi)
• drawable-mdpi (ca. 160 dpi / Baseline)
• drawable-ldpi (ca. 120 dpi)
• drawable-nodpi (keine Skalierung gewünscht)
• drawable-tvdpi (ca. 213 dpi / zwischen mdpi und hdpi)

Dank dieses Android-Ressourcen-Konzepts kann man darüber hinaus auch auf Plattformversionen, Bildschirmgrößen, -ausrichtungen und -formate, Sprach- oder Ländercodes und vieles mehr reagieren. Es lassen sich auch Qualifiers kombinieren, sodass UI-Designer zum Beispiel Bilder für den englischen Sprachraum der USA in hdpi – drawable-hdpi-en-rUS – ablegen können.

Trotz großer Flexibilität bringt dieser Ansatz einen kleinen, aber entscheidenden Nachteil mit sich: Der Entwickler ist stets auf die Qualifier-Vorgaben von Android angewiesen. Er hat es somit schwer, für ein ganz bestimmtes Device ein optimales UI zu erstellen. Dies hat auch Google erkannt und mit Android 4 das ganze System noch einmal deutlich flexibler gestaltet. Anstatt weiterhin für die Screen-Größen feste Wertebereiche vorzugeben, kann der Entwickler die verfügbare Höhe (h<N>dp (device pixel)), Breite (w<N>dp) sowie die kleinste erwartete Breite (sw<N>dp) angeben. In dem Ordner „drawable-sw600dp“ würde man also Bilder für ein Device mit einer Mindestbreite von 600 dp ablegen, was einem Sieben-Zoll-Tablet entspricht.

Man sollte meinen, dass sich mit diesen umfangreichen Bordmitteln von Android durchaus ansprechende UIs gestalten lassen. Doch weit gefehlt. Die Praxis zeigt leider immer wieder, dass viele Entwickler mit den ihnen gegebenen Freiheiten nicht sinnvoll umgehen können oder wollen. Dazu kommt ein weiteres Android-Kernkonzept, das die Transparenz und Usability von Anwendungen eigentlich verbessern sollte – häufig aber in das Gegenteil umschlägt: Intents.

Mit Hilfe der Android Intents lässt sich eine Komponente einer eigenen oder fremden App aufrufen – solange das Rechtesystem dies erlaubt. Möchte man zum Beispiel aus einer Anwendung heraus eine E-Mail versenden, kann man dazu die auf dem Device installierte E-Mail-App verwenden. Die eigene App muss dabei nur ein Intent mit den Informationen der zu versendenden E-Mail erzeugen – den Rest übernimmt das Android-System.

Dieses eigentlich sehr positive Konzept führt leider häufig zu Problemen: Zum einen können sich die UIs der Apps visuell stark unterscheiden. Zum anderen verliert sich der Anwender möglicherweise bei der Navigation durch die Anwendung(en) und weiß am Ende nicht mehr, wo er eigentlich ist. Ein Blick auf iOS zeigt, wie man es besser machen kann: Ein einheitliches UI- und Navigationskonzept sowie Best Practices für die Anwendung von System-Komponenten, Multi-Device- und Multi-Pane-Layouts sorgen für ein konsistentes Nutzererlebnis. Zum Glück hat auch Google diesen Blick riskiert und mit Android 4 (eigentlich schon vorher, aber damals mit wenig Erfolg) entsprechende Design-Guidelines veröffentlicht.

Der Android Design Guide bietet (abgesehen von einigen eher Marketing-tauglichen als praxisrelevanten Slogans wie „simplify my life“) einen wirklich guten und praxisnahen Pool an Design-Prinzipien und -Patterns. Er sollte daher zur Pflichtlektüre jedes Android-UI-Entwicklers gehören.

Angefangen bei der Erläuterung der Ressourcen und derer optimalen Nutzung bis hin zur Beschreibung etablierter Android-UI-Patterns können Entwickler jede Menge Dos und Don’ts aus dem Design Guide ableiten. Ein gutes Beispiel dafür ist der Abschnitt zum korrekten Einsatz der Android ActionBar. Das mit Android 3 und 4 eingeführte Konstrukt lässt sich sowohl auf Smartphones als auch auf Tablets verwenden.

Richtig angewendet, liefert die ActionBar für jede App einen echten Mehrwert. Falsch eingesetzt, irritiert sie den Nutzer mehr als sie hilft, da ihr gleich mehre Funktionen zukommen: Das App-Icon ermöglicht die Navigation zur nächsthöheren Ebene – bis hin zum Home-Screen. Über die „View Control“ kann man die gewünschte View (Tab- oder Drop-Down-Menü) auswählen. Dazu können eine Reihe von Action Buttons kommen, hinter denen sich App-Funktionen verbergen. Mittels XML-Konfiguration (auch eine Ressource) kann man angegeben, ob dieser Button permanent sichtbar ist oder bei Bedarf im Action Overflow untergebracht ist.

Auch für das Thema App-Navigation liefert der Design Guide gute Design-Patterns. Die Navigation ist im Android-Umfeld seit jeher ein Unique Pain Point (UPP). Einmal dargestellte Screens liegen auf einem Stack. Beim Betätigen der Back-Taste arbeitet die App – ähnlich einem Browser – die Screens rückwärts ab. Für einen Nutzer von Web-Anwendungen mag dies durchaus intuitiv sein. Für einen App-Anwender ist es das mit Sicherheit nicht. Das hat auch Google erkannt und versucht mit entsprechenden Guides Abhilfe zu schaffen. Die wenigsten wissen, dass sich die Navigation mit Hilfe des Up-Navigation-Patterns und gezielter Manipulation des Navigation-Stacks relativ einfach an die Usability einer Anwendung anpassen lässt.

Im Google Play Store findet sich übrigens mit „Android UI Patterns“ von Groidofy eine App, die es sich zum Ziel gesetzt hat, die wichtigsten UI-Design-Patterns zu veranschaulichen (inzwischen leider aus dem PlayStore entfernt). Neben dem Android Design Guide ein weiterer guter Einstiegspunkt für Android Entwickler.

Wie eben gezeigt, lässt sich mit einigen wenigen Design-Patterns bereits eine Menge erreichen. Was aber ist, wenn eine Anwendung für unterschiedliche Zielgeräte gedacht ist – zum Beispiel für ein Smartphone und ein Tablet? Gelten dann die eben gezeigten Regeln? Oder muss man hier die Anwendung doppelt implementieren?

Nein, denn Google bietet hierfür das Konzept der Multi-Pane-Layouts. Und um es gleich vorweg zu nehmen: Für sie gelten die gleichen Regeln. Ressourcen, wie Layouts und Bilder, liegen je Device-Eigenschaft in getrennten Ordnern und werden zur Laufzeit herangezogen. Allerdings kommt zu den bisher bekannten UI-Elementen – Layout inklusive Views sowie Activity-Klasse für das Lifecycle-Management des UI – noch eine weitere Abstraktionsebene hinzu: die Fragments.

Unter Fragments versteht man UI-Ausschnitte (oder eben Fragmente) mit zugehöriger Logik. Sie lassen sich beliebig zu komplexen UIs kombinieren. Sie sind also mehr als nur Views und weniger als Activities mit deren Layouts. Ein Beispiel mit dem bekannten UI-Szenario „E-Mail“. Zum einen existiert in der E-Mail-App eine Liste von E-Mails. Zum anderen kann der Nutzer sich nach der Auswahl einer E-Mail aus der Liste deren Details anzeigen lassen. Auf einem Smartphone würde man dieses Szenario auf zwei Screens verteilen, auf einem Tablet dagegen würde beides auf einem Screen Platz finden. Natürlich möchte man nicht unbedingt zwei Anwendungen entwickeln, um beide Device-Gruppen abzudecken.

Stattdessen ist es möglich, zunächst einmal zwei UI Fragments zu bauen – eines für die Liste und eines für die Detail-Ansicht. Diese Fragments sind so aufgebaut, dass sie sich auf dem Smartphone und auf dem Tablet nutzten lassen. Anschließend erstellt man die grundlegenden Layouts für die beiden Device-Gruppen. Für das Smartphone wären dies zwei Layouts (EMail und EMailDetail), die jeweils das entsprechende Fragment einbinden. Für das Tablet dagegen wäre es nur ein Layout (EMail), das beide Fragmente referenziert.

Der eigentliche Clou: Zur Laufzeit wird die EMail-Activity gestartet, die bei ihrer Initialisierung das EMail-Layout einbindet. Je nach Device wird mit Hilfe des Android-Resource-Managements dazu entweder das EMail-Layout aus dem Smartphone-Ordner oder dem Tablet-Ordner dargestellt. Im einen Fall sieht man also nur die Übersicht der E-Mails. In anderen dagegen die Übersicht und die Detail-Ansicht der aktuell angewählten E-Mail. Wichtig dabei ist, dass die zugehörige Activity-Klasse – in diesem Fall die EMail-Activity – nur einmal existiert.

Wählt der Nutzer nun eine E-Mail aus der Liste aus – egal auf welchem Device – prüft die Activity eigenständig ihre Umgebung. Auf dem Tablet tauscht die Activity lediglich die Inhalte des Fragments mit der Detailansicht aus. Auf dem Smartphone dagegen startet mittels Intent eine neue Activity und lädt dort – innerhalb der Initialisierung – das EMailDetail-Layout. Wenn man das Prinzip einmal verstanden hat, ist es eigentlich ganz einfach. Zumindest so lange, bis man beispielsweise anfängt, sich mit verschachtelten Fragments auseinander zu setzen.

Auch Android-Anwendungen können gut aussehen und gleichzeitig ergonomisch sein. Um dies zu erreichen, bedarf es nur weniger Best Practices und einer ganzen Menge Disziplin. So viel Spaß es auch bringen mag, dass Rad neu oder zumindest runder als bisher zu erfinden – dem Anwender nutzt es in der Regel eher wenig. Er erwartet auf seinem Device eine Android-UX und nicht – wie gerne von den Entwicklern geglaubt – eine App-spezifische UX, die sich auf allen mobilen Betriebssystemen gleich verhält.

Auf die tatsächlich vorhandene starke Fragmentierung des Android-Marktes kann man reagieren: Device-Eigenschaften – wie Bildschirmgröße, Auflösung und so weiter – lassen sich zur Laufzeit abfragen und nicht vorhandene Features älterer OS-Versionen durch 3rd Party Support Libraries ergänzen. Einem gelungenen UI und einer gelungenen UX steht also nichts im Wege.