Nach oben

Das iPhone und der Back Button

Wir haben kürzlich wieder mal einen Usability-Test auf einem iPhone durchgeführt. Getestet wurde der Prototyp für eine iPhone App. Wieder mal war ich – geschieht auch nach vielen vielen Tests immer wieder – erstaunt, was sich da abspielte.

Die versteckten Features

Erstens gibt es so einige iPhone-Standard-Funktionalitäten, die anscheinend auf vielen Geräten brach liegen. Nicht weil es schlechte Funktionalitäten wären oder Features, die niemand braucht. Sondern weil viele Benutzer sie einfach nicht finden (es sind eben doch nicht alle Menschen «Ausprobierer»). So konnte ich Nutzer – die schon über ein Jahr ein iPhone besitzen – beglücken, indem ich ihnen gezeigt habe, dass man auf dem iPhone doch ein «ü» schreiben kann (Taste «u» lange gedrückt halten). Um das rauszufinden habe ich übrigens auch mehr als 2 Monate gebraucht. Oder dass man aus der Mailbox ein einzelnes Mail ganz einfach löschen kann mit der Swipe-Funktion (Mail nach links aus dem Bildschirm schieben). Oder dass man in den SMS suchen kann, wenn man die Nachrichten-Liste nach unten scrollt. Dies nur um einige Beispiele zu nennen.

Der fehlende Back Button

Zweitens konnten wir kürzlich in einem Usability Test mit 8 Testpersonen bei 3 Testpersonen beobachten, dass sie wiederholt die iApp verliessen, weil sie auf den Home Button drückten.

Sie taten dies nicht, weil sie wirklich aus der Applikation raus wollten. Was sie eigentlich vor hatten, war einen Schritt zurück zu navigieren. Da diese Funktionalität (Back Button) aber nicht vorhanden ist und sie nirgends einen Zurück-Button fanden, klickten sie wiederholt auf Home und starteten die Applikation wieder neu.

Auf Websites und in Webapplikationen ist der Back Button heilig und wird so häufig geklickt wie kaum ein anderes Interaktionselement. Mittlerweilen halten sich – zum Glück – die meisten Websites an die Regel «Never break the back button». Wie sieht es aber bei Apps aus? Das iPhone und die «Mobile Human Interface Guidelines» von Apple kennen keinen wirklichen Back Button.

Gemäss den Apple Guidelines wird ein Zurück-Button (links oben) nur eingesetzt, um bei hierarchisch aufgebauten Applikationen wieder eine Ebene nach oben zu navigieren. Navigiere ich also aus einer Liste zu einer Detailseite ist ein Back Button vorhanden. Es gibt aber auch Fälle, in denen dies nicht der Fall ist.

Zur Illustration zwei Beispiele:

1. Der Benutzer befindet sich auf einer Detailseite.
Er klickt dann aus Versehen auf einen Hauptnavigationspunkt in der Tab Bar (z.B. weil der Busfahrer gerade abrupt gebremst hat). Nach Apple Guidelines gibt es keinen direkten Weg zurück zur Detailseite.

2. Der Benutzer befindet sich auf einer Detailseite.
Er klickt dann aus Versehen auf einen Hauptnavigationspunkt in der Tab Bar (z.B. weil der Busfahrer gerade abrupt gebremst hat). Nach Apple Guidelines gibt es keinen direkten Weg zurück zur Detailseite.

Guideline oder nicht Guideline?

Nach unseren Beobachtungen differenzieren nicht alle iPhone User, ob sie sich jetzt auf einer Website (in einem Browser) befinden oder in einer iApp und ob dementsprechend ein Back Button angeboten wird oder nicht. Vielmehr haben sie sich einfach daran gewöhnt, dass man auf Computern und Geräten usw. immer zur zuletzt aufgerufenen Seite zurück kann.

Wir sehen immer wieder, dass sich Entwickler beim Mobile Design ganz auf die Apple-Vorgaben verlassen. Wie auch Web-Usability-Regeln nur die Spitze des Eisbergs zu einer guten User Experience treffen, scheinen diese Vorgaben aber nicht auszureichen –

Wie seht ihr das, liebe Leser: Soll man sich jetzt an die Apple Guidelines halten oder…

Kommentare

3
Kommentar schreiben

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Peter Berger

24.06.2015 - 15:15

Das ist wirklich der größte Blödsinn den ich je gelesen habe Lukas. Wenn man schon keine eigene Logik besitzt und dann eine schwachsinnige Begründung von Apple zitiert sollte man sich nicht mehr anmaßen als Außenstehender über das Thema Intelligenz mitreden zu wollen. Ein fehlender Back-Button ist für mich DAS no-go-Kriterium für Apple und zeigt mal wieder eindrucksvoll, wie mit lächerlichen Argumenten Apple verteidigt wird. Wenn man diese Back-Funktion nicht braucht, ok. Aber sie für unlogisch zu erklären ist schon ein Widerspruch in sich selbst.

Lukas Zeller

25.11.2010 - 23:01

Ich glaube, man muss vor allem die Schwelle zwischen den zwei total verschiedenen Welten, der linearen Vor-Zurück-Welt wie im Web (oder in der iPhone Fotoapp) und der hierarchischen drill-down-Welt (Ur-iPod, gopher für die Veteranen 🙂 den BenutzerInnen klar erkennbar machen. Ich glaube nicht, dass ein universeller Back-Button wirklich die Bedienung klarer macht.

Sobald es neben der Auswahl auf der gleichen Ebene (Fotos, Buchseiten) auch einen Fokus (Zoom in) gibt, ist es m.E. sehr schlecht wenn „zurück“ mal Fokusverlust bedeutet, mal nicht (z.B. auf Android oder WinMobile selig). Ein immer funktionierender Back-Button mag zwar im ersten Moment „logisch“ wirken, ist es aber meist nicht. Er suggeriert ein Nebeneinander, das überhaupt nicht existiert, und erschwert den BenutzerInnen das Verständnis für den Fokus, der für souveräne Bedienung nicht vollständig trivialer Apps wichtig ist.

In den Beispielen würde ich sagen, dass die Lösung nicht eine erweiterte Back-Button-Funktionalität sein darf, sondern:

a) sollte der Tab-Bar in der Detailansicht ausgeblendet werden, so dass der Fokus nicht versehentlich verloren gehen kann (1. Beispiel)

b) darf der Button eben nicht unspezifisch „back“ heissen, sondern muss klar die Hierarchiestufe oberhalb anzeigen, also „Liste“ in den Beispielen.

c) dürfen die Paging-Buttons visuell nie so aussehen wie der Hierarchie-„Back“-Button. Apple verwendet dafür scharfkantige Dreiecke wie in Browsern üblich (recht konsequent, s. Foto-App, Mail, Kalender…)

Langer Rede kurzer Sinn: Ich sehe hier keinen Grund, sich nicht an die Guidelines zu halten 🙂