UX United

Android-4-UI-Design für alle

Lars Röwekamp und Arne Limburg

Android hat sich in den letzten Jahren innerhalb der Mobile-Developer-Community einen ausgezeichneten Ruf erarbeitet. Leider kann man diese Aussage aber nicht ohne Weiteres auch auf den einfachen Endanwender übertragen. Nach wie vor hat Apples iOS mit seinen Apps die Nase vorn, wenn es um Usability und User Experience geht. Abhilfe sollen hier die mit Android 3 bzw. 4 eingeführten Design-Guidelines schaffen – aber was bringt das den restlichen 85 Prozent der Nutzer?

Wieso scheinen iOS-Anwendungen – rein objektiv betrachtet – besser auszusehen und ergonomischer bedienbar zu sein als ihre Android-Pendants? Ein Grund hierfür ist sicherlich die Tatsache, dass die meisten iOS-Anwendungen den Usability-Erwartungen des Anwenders entsprechen. Das bedeutet nicht automatisch, dass sie besser sind als Android-Anwendungen. Es bedeutet lediglich, dass der iOS-Anwender bei der Nutzung einer App von einer gewissen User Experience ausgehen kann und diese in der Regel auch erfüllt wird. Wieso ist dem so? Apple hat bereits beim initialen Aufbau der iOS-Developer-Community darauf geachtet, dass die Entwickler – sowohl via SDK als auch durch zusätzliche Guidelines unterstützt – Anwendungen entwickeln, die zu 100 Prozent den iOS-UX-Paradigmen genügen. Android dagegen lässt den Entwicklern – ebenfalls durch das SDK unterstützt – seit jeher sehr viele Freiheiten, was unter anderem dazu führt, dass in der Vergangenheit viele Räder mehr als nur einmal neu erfunden wurden. Dass sich ein hoher Grad an Freiheit nicht immer nur positiv auswirkt, hat mittlerweile auch das Android-Team erkannt und wartet seit der Version 4.0 mit einem umfangreichen Design-Guide auf [1]. Dieser zeigt unter anderem, wie ein ergonomisches UI unter Android aufgebaut sein sollte, welche Arten von Navigation innerhalb einer Anwendung zu berücksichtigen sind oder aber wie mittels UI Fragments Multi-Pane-UIs konzipiert werden können. So weit, so gut. Einen entscheidenden Nachteil bringen die Design-Guidelines allerdings mit sich: Sie basieren zum größten Teil auf UI-Elementen, die erst in Android 3 bzw. 4 Einzug in das SDK erhalten haben. Was macht man also, wenn man nicht nur die ca. 15 Prozent der Devices, die Android 3 und 4 unterstützen, sondern auch den restlichen Teil der Android-Community erreichen möchte?

Support Library

Die erstmals im März 2011 erschienene und mittlerweile in der Revision 9 vorliegende Android Support Library bietet für Android-Anwendungen ab der Version 1.6 eine Mischung aus „neuen“ API-Features und -Utilities. Mithilfe der in Android 4 gleichnamigen Klassen

  • Fragment
  • FragmentManager
  • FragmentTransaction
  • ListFragment
  • DialogFragment

lassen sich zum Beispiel die in Android 4 eingeführten Multi-Pane-Layouts für ältere Umgebungen erstellen. Und auch das Android-4-Feature des asynchronen Datenladens kann dank der Support Library bzw. der darin enthaltenen Klassen

  • Loader
  • LoaderManager
  • AsyncTaskLoader
  • CursorLoader

unter älteren Android-Versionen verwendet werden. Die Unterschiede in der Verwendung der einzelnen Klassen im Vergleich zu ihrem Android-4-Original sind dabei minimal und in der Regel anhand von Beispielen [2] und JavaDoc [3], [4] gut dokumentiert. Während einige der APIs die gleichnamigen Features von Android 4 eins zu eins nachbilden, gibt es auch andere, die diese Features lediglich dann unterstützen, wenn sie von der darunterliegenden OS-Version zur Verfügung gestellt werden. Ein Beispiel hierfür ist die in Android 4 eingeführte ActionBar. Sie wird nicht durch die Library zur Verfügung gestellt. Mittels MenuCompat.setShowAsAction(…) kann aber immerhin angegeben werden, welche Menüeinträge in der ActionBar erscheinen sollen, wenn sie denn vorhanden ist. Durch diesen Ansatz ist es möglich, ein und denselben Sourcecode für Pre- und Post-Android-4-Anwendungen zu verwenden (Listing 1).

Listing 1
public boolean onCreateOptionsMenu(Menu menu) {
    MenuInflater inflater = getMenuInflater();
    inflater.inflate(R.menu.options, menu);
    MenuCompat.setShowAsAction(menu.findItem(R.id.action_search), 1);
    return true;
}
Geschrieben von
Lars Röwekamp und Arne Limburg
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.