dieappentwickler

Gastbeitrag von Frank Hösler, Grafikdesigner aus Leipzig.

Essentiell für gutes Interfacedesign ist, wie so oft, das strukturelle Basiskonzept, welches z.B. über Wireframes entwickelt werden kann. In diesem Stadium werden Entscheidungen gefällt, welche Informationen wie präsentiert werden sollen und über welche Möglichkeiten der Nutzer in der Software interagieren kann. Entscheidend ist es dabei, neben den relevanten Inhalten auch die Eigenheiten des Mediums zu beachten, für welches das Interface gestaltet wird.

In den letzten Jahren mit Smartphones und Tablets Gerätetypen in die Medienwelt Einzug gehalten, die zwar prinzipiell verwandt mit Computern sind, sich aber doch in Ihrer Nutzung in signifikanten Punkten unterscheiden. Dies sollte also auch bei der Gestaltung von Software für diese Geräte berücksichtigt werden. Ich möchte hier ein paar Eckpunkte anführen, die ich für mich bei der Arbeit an verschiedenen App-Projekten herausgestellt habe.

Nutzungskontext

Ein erster wichtiger Unterschied bei der Softwarenutzung zwischen Computer und mobilen Geräten besteht darin, wann, wo, wie lange/wie häufig und wie fokussiert das Gerät genutzt wird. Ist es beispielsweise beim Computer so, dass man sich in der Regel explizit davor setzt und Zeit dafür nimmt, so stellt sich das Bild insbesondere bei Smartphones ganz anders dar. Meiner Erfahrung nach verwendet man den Computer eher „am Stück“ und sehr konzentriert, während über das Tablet hin zum Smartphone hin die Benutzung immer beiläufiger, kürzer, aber auch häufiger wird. Der Grund ist recht einfach: Das Smartphone ist klein, man hat es jederzeit dabei und es ist in Sekunden arbeitsbereit. Daher kann man es wunderbar nebenher beim Fernsehen, Joggen, Essen oder was auch immer, verwenden. Der große Bildschirm des Computers macht ein gleichzeitiges Konzentrieren auf andere Tätigkeiten ungleich schwerer. (Sehen wir mal davon ab, dass man z. B. Netbooks natürlich auch auf dem Sofa nutzen kann.)

Diese Erkenntnis sollte man daher bei der Komplexität eines zu entwerfenden Interfaces berücksichtigen. Meiner Meinung nach, sollte man ein Interface für ein Smartphone nicht nur ob des kleinen Screens (und damit wenig Fläche für Buttons, Menüs, etc.) funktionell reduzieren, sondern insbesondere auch deshalb, um eine beiläufige Nutzung des Interfaces zu gewährleisten. Wer möchte sich schon beim Fernsehen noch durch hunderte Menüeinträge suchen? Dem Nutzer eines Computerinterfaces kann man da schon etwas mehr zumuten, da er sich in der Regel auch besser konzentrieren kann.

Technische Ein- und Ausgabemöglichkeiten

Wesentliche Unterschiede in der Softwarenutzung sind vor allem technisch bedingt. Wie ein Nutzer ein Interface bedienen kann, hängt in erster Linie davon ab, welche Ein- und Ausgabemöglichkeiten ihm zur Verfügung stehen. Ich möchte daher im Folgenden betrachten, welche Interaktionselemente beim Übergang vom System „Bildschirm/Maus/Tastatur“ hin zum Multi-Touchscreen mobiler Geräte an Bedeutung verlieren, welche sich in der Art ihrer Verwendung verändern und welche neuen Interaktionsformen sich bieten.

Weniger geeignete Interaktionsformen

1. TEXTLINKS
   Verlinkungen innerhalb eines Textes sind auf Touch-Geräten oftmals nur schlecht zu bedienen. Vor allem, wenn mehrere in räumlicher Nähe zueinander auftreten (z.B. Linklisten). Daher rate ich, auf verlinkte Wortgruppen zu verzichten und stattdessen auf klar erkenn- und bei entsprechender Größe auch besser bedienbare Buttons zu setzen. Als Faustregel für die minimale Buttonhöhe kann z.B. bei iOS-Geräten z.B. 30px (Standard) bzw. 60px (Retina) gelten.
2. BREADCRUMP-NAVIGATION
   Die Breadcrump-Navigation teilt natürlich, wenn nicht in Button-Form angelegt, die Nachteile von Textlinks im Allgemeinen. Darüber hinaus kann es speziell auf Smartphones schnell zu Platzproblemen kommen. Generell bietet sich eine Breadcrump-Navigation eher bei sehr umfangreichen digitalen Dokumenten an (große Websites etwa). Auf mobilen Geräten konkurriert sie jedoch mit dem Gebot geringer Interface-Komplexität. Meiner Ansicht nach geht zudem auch der „App-Charakter“ der Software etwas verloren.
3. PAGINATIONSLINKS
   Mehrseitige Inhalte könnten auch auf mobilen Geräten zwar prinzipiell über Paginations-Links/-Buttons navigiert werden. Allerdings kann eine Seitenweise Navigation bei Touch-Geräten sehr viel Eleganter über eine horizontale Blätter-Geste mit dem Finger gelöst werden. Dies entspricht eher den Möglichkeiten dieser Geräte und ist vom Nutzer inzwischen gelernt. Bei der Interfacegestaltung sollte jedoch darauf geachtet werden, dass der Nutzer auch erkennt, wann er blättern kann. Dies kann z.B. über Pfeile, subtile Schatten am Seitenrand oder z.B. angeschnittene Inhalte angedeutet werden. Letzteres ist beispielsweise ein vorherrschendes Design-Merkmal des Windows Metrodesigns.
4. HOVER-STATUS
   Von Computer-Interfaces sind wir es gewohnt, dass sich Interaktionsflächen optisch hervorheben, wenn wir sie mit der Maus überfahren oder in ihre Nähe gelangen. Bei Touchscreens gibt es aktuell noch keine Entsprechung für ein solches Verhalten (angeblich soll es beim Samsung Galaxy S4 ja ähnliches geben). Explorative Oberflächen sind also auf Touch-Geräten ungleich schwerer bedienbar und deren Einsatz sollte hinterfragt werden. (Es sei denn, das „Suchen“ ist explizit gewünscht – z.B. bei Spielen)

Veränderte Bedeutung bekannter Interaktionselemente

1. BUTTONS
   Buttons gibt es meines Erachtens schon seit den ersten grafischen Benutzeroberflächen. Die Idee vom Hypertext hat im Zuge der rasanten Entwicklung des Internets die Verwendung von Buttons zugunsten von Textlinks etwas zurückgedrängt. Buttons waren oft eigentlich nur noch in Formularen zu finden. Wie oben schon angedeutet, sind Textlinks aber für Touch-Screens nicht ideal. Im App-Design spielen daher Buttons inzwischen wieder eine viel zentralere Rolle. Nicht nur in Formularen, sondern in allen Bereichen, in denen ein einfaches Antippen als Aktion von Nutzern erwartet wird, finden sich Buttons, da ihre Funktionsweise für jeden sofort verständlich ist. Interessanterweise kann ich in den letzten Jahren einen Trend feststellen, der abgeleitet vom Appdesign auch wieder mehr Buttons ins Webdesign bringt.
2. SYMBOLE / ICONS
   Vor allem aufgrund der kleinen Displays der Smartphones spielen Symbole viel größere Rolle als bei Software für den Computer. So sind Symbole das Mittel der Wahl z.B. für Menüleisten, die permanent sichtbar sein sollten. Allerdings besteht die Kunst darin, selbsterklärende, einfache Symbole zu finden, um eine reibungslose Bedienung zu ermöglichen. Im Notfall kann man die Symbole freilich mit einer kleinen Unterschrift versehen (wie z.B. bei der schwarzen Tab-Bar von iPhone-Apps), aber das vermindert natürlich den platzsparenden Effekt wieder etwas.
3. SCROLLBAR
   Die Scrollbar ist eines der Elemente, die im „klassischen“ Interfacedesign gerne vermieden werden, da sie verhältnismäßg umständlich zu bedienen sind. Hier hat das Mausrad zwar etwas Abhilfe geschaffen – viel natürlicher „fühlt“ sich jedoch das Scrollen über Fingergesten auf Touchscreens an. Eine tatsächliche Scrollbar zur Bedienung wird dazu vom Nutzer eigentlich nicht mehr gebraucht und sollte daher keinen permanenten Platz im Screendesign erhalten. Eine Einblendung kann trotzdem bei langen Inhalten sinnvoll sein, wenn sie z.B. als Anzeige dafür dient, an welcher Position man sich im Moment befindet. Darüber hinaus hat es sich z.B. bei Androidgeräten etabliert, bei langen alphabetischen Listen am rechten Rand ein zielgenaues Anspringen nach Anfangsbuchstaben über eine entsprechende spezielle Scrollbar zu ermöglichen.
4. DROPDOWN
   Dropdowns, wie man sie von Webseiten und Desktop-Software kennt, die sich ausklappen, haben im Appdesign nichts zu suchen. Dies mag logisch erscheinen und nicht extra erwähnenswert, aber ich habe schon so manches in App-Konzepten gesehen, daher erwähne ich es dennoch. Je nach Betriebssystem gibt es entsprechende Alternative Beidnelemente, wie das „Picker“-Rad bei iOS oder scrollbare Listen, die sich über das Interface legen, wenn man den Auswahlbutton antippt. Diese sollten auch verwendet werden.
5. DRAG & DROP
   Ich erinnere mich, dass „Drag & Drop“ mal ein ständig auftauchendes Buzzword war, welches immer herhalten musste, um auf die Einfachheit eines Interfaces hinzuweisen. Das Prinzip dahinter ist ja auch ein sehr intuitives, da wir alle gelernt haben, Dinge mit der Hand aufzunehmen und an einem anderen Ort wieder abzulegen. Es bietet sich z.B. immer dann an, wenn vom Nutzer etwas sortiert oder zugeordnet werden soll. Bei Touchscreens besteht jedoch das grundlegende Problem, dass das „Mit dem Finger über den Bildschirm wischen“ schon vom Swipen/Blättern/Scrollen belegt ist. Daher funktioniert „Drag & Drop“ per se erst mal nicht bzw. muss zunächst aktiviert werden. Man kennt das z.B. vom Homescreen von iOS-Geräten, bei dem man nach langen Tippen auf ein Symbol in den „Drag & Drop“-Modus gelangt. Möchte man „Drag & Drop“ verwenden, so ist zu beachten, dass man den Nutzer auch darauf hinweist, dass diese Funktionalität überhaupt verfügbar ist, da dies nicht sofort ersichtlich ist.

Neue Interaktionsformen

1. SWIPE-GESTE
   Das vermutlich hervorstechendste Merkmal neuerer Touch-Interfaces ist, dass man per Wischen mit dem Finger den dargestellten Inhalt relativ zum Bildschirm bewegen kann. Damit lässt sich also das schon erwähnte Scrollen von Information, die über den Bildschirmrand hinausgeht oder auch ein horizontales Blättern von Seite zu Seite darstellen. Diese Interaktionsformen sind so elementar, dass sie meiner Meinung nach mittlerweile schon als gelernt gelten können. Sie sind auch das „Hauptwerkzeug“, um einem kleinen Screen beizukommen und trotz allem reichlich Information präsentieren zu können. Wie bei der Pagination schon erwähnt, ist es allerdings die Aufgabe des Designs, dem Nutzer auch klar ersichtlich zu machen, dass sich jenseits der Bildschirmgrenzen weiterer Inhalt verbirgt.
   Ein Sonderfall stellt der Swipe mit mehreren Fingern dar. Damit könnte man sich aushelfen, wenn mehre verschiedene Funktionen das Verschieben mit dem Finger bedürfen. (Evtl. ja auch doch für Drag & Drop verwendbar?) Nachteile sind aber eine niedrigere Präzision als der Swipe mit einem Finger, sowie generell die Notwendigkeit einer Erklärung dieser Funktionalität.
2. PINCH-TO-ZOOM
   Auch diese Geste hat sich über Apples Marketing schnell verbreitet und darf als allgemein bekannt gelten. Mit ihr ist es möglich, Inhalte zu vergrößen, indem man sie mit zwei Fingern „auseinanderzieht“ – oder umgekehrt zu verkleinern. Diese Geste bietet sich dann an, wenn Information dargestellt werden soll, die großflächig und detailiert ist (klassisches Beispiel wäre eine Landkarte). Das Hinaus-Zoomen erleichtert es dem Nutzer den Überblick zu bewahren. Auch wenn die Verfügbarkeit dieser Geste nicht auf den ersten Blick sichtbar ist, so ist sie doch inzwischen so bekannt, dass diese oft über einfaches Probieren entdeckt wird. Idealerweise sollte man den Nutzer trotzdem auf eine solche Möglichkeit hinweisen.
3. DREHEN DES DISPLAYS
   Aufgrund von Größe und Gewicht können mobile Geräte in der Regel sowohl in Quer- als auch in Hochkant-Ausrichtung verwendet werden. Dies ist ein nicht zu unterschätzender Vorteil gegenüber einem festen Monitor. Gängige Praxis ist es dabei – wie z.B. vom iOS-Mailclient gelernt – im Querformat zusätzliche Navigationselemente anzuzeigen. Im Hochformat kann im Gegensatz dazu dann mehr Platz für die Darstellung des Inhalts verwendet werden. Natürlich bedeutet das Design für beide Ausrichtungen Mehraufwand, aber man verschenkt einfach Potential, wenn man dies nicht beachtet und den Nutzer in eine Ausrichtung zwingt.
4. NEIGEN / SCHÜTTELN DES GERÄTES
   Lagesensoren bieten Spielraum für Kreativität im Userinterface. Man kennt das Schütteln des Gerätes, um ein zufälliges Element aus einer Reihe zu erhalten (z.B. bei Spielkarten, Würfeln, Songs im Musikplayer). Ich denke aber, das Potential ist noch lange nicht ausgereizt. Ich kann mir z.B. vorstellen, dass man „Drehregler“ auch gut per Neigung bedienen könnte – vielleicht sogar feinstufiger als Schieberegler per Touch. Natürlich besteht bei der Integration des Lagesensors auch die Gefahr, dass es dem Nutzer die Funktion nicht sofort schlüssig ist. Ich sehe daher Potential vor allem für Funktionen, die nicht essentiell für die Bedienung sind, aber den Komfort oder die Geschwindigkeit für „Power-User“ der Software steigern – dann hätte es einen echten Mehrwert. Ich bin gespannt, was da noch kommt.