Im Oktober 2010, als das Samsung Galaxy Tab vorgestellt wurde, meldete sich Steve Jobs zu Wort, um seiner Meinung über 7“-Tablets Luft zu machen. Er bezeichnete diese Geräteklasse als ”dead on arrival“ – ”Totgeburt“ – und empfahl, jedem Gerät Schleifpapier beizulegen, um die Finger der Nutzer anzupassen. Nach Jobs Tod dann veröffentlichte auch Apple mit dem iPad mini ein Gerät der zuvor noch gescholtenen 7”-Klasse. Dass es sich bei der Geräteklasse offensichtlich nicht um eine Totgeburt gehandelt hat, wissen wir inzwischen. Mit dem Vorschlag der Anpassung der Nutzerfinger per Schleifpapier indes hatte der Apple-Gründer nicht ganz unrecht, zumal wenn es um die iOS-Geräte geht. Warum das so ist, will ich im folgenden Beitrag deutlich machen…
Vom Finger zum Touch Target
Zunächst stellt sich natürlich die Frage, wieso Steve Jobs nicht auch der Ansicht war, dem iPhone ebenso Schleifpapier mitliefern zu müssen? Immerhin ist ein (damals) 3,5 Zoll-, heute 4 Zoll-Display noch weit kleiner als die angesprochenen 7 Zoll.
Diese Frage lässt sich leicht beantworten, wenn man sich iOS einmal genauer anschaut. Dieses Betriebssystem wurde entwickelt, um auf einem 3,5 Zoll Display bei einer Auflösung von 480 x 320px mit dem Finger bedient werden zu können. Diese Eckdaten definierten die Größe der Arbeitsfläche. Diese Arbeitsfläche hängt bei einem Touch-Betriebssystem jedoch nicht nur von Werten ab, sondern auch vom “Eingabegerät”, in diesem Fall also den Fingern, genauer dem Zeigefinger und Daumen.
Finger haben eine bestimmte Größe und beanspruchen bei der Berührung des Displays eine bestimmte Fläche. Die so beanspruchte Fläche wird als “Touch-Target” bezeichnet. Die Größe des Touch-Targets beeinflusst, wie viele Bedienelemente auf der Arbeitsfläche angezeigt werden können. Apple gibt in seinen Richtlinien ein Touch-Target von mindestens 44 x 44px an, was einer Fläche von ca. 8 x 8mm entspricht.
Beim Wechsel auf die bekannte “Retina”-Auflösung hat Apple an diesem ganzen Konzept nichts geändert, stattdessen einen simplen und doch effizienten Trick angewandt. Ein Pixel wurde in 4 kleine Pixel aufgeteilt, die zusammen die Größe des ursprünglichen Pixel haben. Daraus ergibt sich genau die doppelte Auflösung auf jeder Achse: 960 x 640px. Dieses Vorgehen führt nicht zu mehr Platz auf dem Display, aber zu einer schärferen Darstellung.
Die Touch-Targets sind immer noch ca. 8 x 8mm groß, aber bestehen nun aus doppelt so vielen Pixeln (88 x 88px). Da iOS-Layouts nicht mit relativen, sondern mit absoluten Werten erstellt werden, hat diese Auflösungsänderung keine Auswirkung. Die Werte werden einfach nur verdoppelt, um das gleiche Ergebnis zu bekommen. Somit bleibt die Größe der Arbeitsfläche gleich, obwohl die Auflösung verändert wurde. Das iPhone 5 hat noch ein wenig mehr Veränderung gebracht, die aber nicht von großer Bedeutung sind und spielt daher in den weiteren Betrachtungen keine Rolle.
Der Unterschied beim iPad
Was hat sich nun beim iPad (2) geändert und was ist gleich geblieben? Verändert hat sich die Displaygröße auf 9,7 Zoll und die Auflösung auf 1024 x 768px. Das Eingabegerät ist jedoch gleich geblieben – der Finger. Er ist immer noch genauso groß wie zuvor, hat jetzt jedoch eine größere Fläche vor sich. Somit entsprechen die 8 x 8mm des Fingers ca. 44 x 44px auf dem Display. Durch den größeren Bildschirm passt nun aber mehr drauf. Dieses mehr an Platz definiert das Tablet-Layout.
Durch die vergrößerte Arbeitsfläche ist es möglich, mehr Inhalt darzustellen, welcher mit dem Finger immer noch bedienbar ist. Jedoch sollte man auf einem Tablet die Touch-Targets ein wenig größer gestalten, da das User Interface sonst schnell überladen wirkt und zu keiner angenehmen Erfahrung führt. Beim iPad 3 und 4 ist das Vorgehen (wie oben beschrieben) mit der Verdoppelung der Auflösung gleich.
Der Schleifpapier-Effekt
Kommen wir nun zum fiktiven Schleifpapier und wieso ein 7“-Tablet solches im Lieferumfang enthalten sollte, falls iOS das Betriebssystem der Wahl ist. Zuerst geht man davon aus, dass die Apps auf dem 7”-Tablet das Tablet-Layout benutzen sollen. Immerhin will man ja ein Tablet-Design und kein aufgeblasenes Telefon-Layout. An dieser Stelle entsteht die Schwierigkeit mit den pixelgenauen Layouts in iOS.
Man nimmt also ein Touch-Target (z.B. einen Button) mit der Größe von 44 x 44px, welches auf 9,7" zu einer realen Größe von 8 x 8mm führt, und verkleinert dieses auf ca. 70% dessen. Die Auflösung bleibt die Gleiche. Man erhält also ein Touch-Target, welches 5,6 x 5,6mm groß ist. Der Finger wird jedoch nicht kleiner, nur weil man sich ein kleineres Tablet gekauft hat. Somit bekommt man das Problem, die Touch Targets mit dem Finger nicht mehr so einfach treffen zu können.
Natürlich kann man durch Analyse der Berührungen auf dem Bildschirm versuchen, diese den kleineren Touch-Targets zuzuordnen. Jedoch muss das nicht immer zum Erfolg führen und kann bei Bedienelementen, die nahe zusammenstehen, zu unerwünschten Aktionen führen. Diese Fehleingaben verschlechtern die Benutzererfahrung mit dem Gerät bzw. der App.
Nun gibt es zwei Möglichkeiten dieses Problem zu lösen. Zum Einen kann man eine neue Auflösung und damit ein neues Layout definieren. Dieses Vorgehen führt jedoch dazu, keine kompatiblen Apps für diese neue Auflösung zu haben. Die Layouts müssten neu gedacht und erstellt werden. Was passiert, wenn das passiert, aber nicht passiert, sah man eine ganze Weile am neuen Display im iPhone 5 – Balken dominierten die zusätzliche Fläche.
Die zweite Möglichkeit ist eben das “Abschleifen” der Finger, um sie “präziser” zu machen (ein kapazitiver Stylus würde es wohl auch tun, aber das wäre ja nicht Sinn der Sache).
Die “Größe” des iPad Mini
Apple entschied, das Display des iPad Mini auf 7,9“ zu verkleinern. So wurden aus den Touch-Targets mit 8 x 8mm nurmehr solche mit 6,5 x 6,5mm. Diese Maße wurden seitens der Apple-Ingenieure anscheinend als noch zumutbar erachtet. Es handelt sich hier ”nur" um Unterschiede im Millimeterbereich, was sich recht belanglos anhört. Jedoch merkt man bei der Bedienung eines Gerätes mit Toucheingabe schnell, wie wichtig Bedienelemente sind, die nicht zu klein ausfallen.
Doch keine Sorge. Die meisten Tablet-Apps sind auf dem iPad Mini noch gut bedienbar, da die Touch-Targets auf den 9,7“ Geräten selten die minimale Größe bekommen, sondern eher größer dimensioniert werden. Dies dient der erleichterten Bedienung. Beim iPad Mini führen diese größeren Bedienelemente zu ”genau der richtigen Größe" nach der Verkleinerung, kleinere jedoch zu Schwierigkeiten.
Android und die Vielfalt an Auflösungen
Kommen wir nun dazu, wie Android dieses Problem mit den verschiedenen Auflösungen und Displaygrößen handhabt. Wie kann bei dieser Fragmentierung die minimale Größe des Touch-Targets garantiert werden?
Android ist seit der Version 1.0 in der Lage auf verschiedenen Bildschirmgrößen und den dazugehörigen Auflösungen ein konsistentes Erlebnis zu bieten. Um als Programmierer nicht für jede Auflösung bei verschiedenen Displaygrößen Layouts erstellen zu müssen, wurde versucht, diese konkreten Variablen zu abstrahieren.
Zunächst führte man eine neue Einheit namens DIP (Density Indipendent Pixel) ein. Diese Einheit ist unabhängig von Auflösung bzw. Bildschirmgröße und liefert immer (ungefähr) die gleiche physikalische Größe auf dem Display.
So funktioniert es:
Definiert wird 1 DIP als 1 Pixel bei einer Pixeldichte von 160dpi (mdpi). Die Pixeldichte enthält die Bildschirmgröße und Auflösung im Verhältnis zueinander. Weiter werden Umrechnungsfaktoren definiert, um auch andere Pixeldichten abzudecken.
Bei der Verdoppelung der Pixeldichte auf 320dpi (xhdpi) wird ein Pixel eines 160dpi Display einfach nur in 4 kleinere Pixel unterteilt. Dieses Vorgehen gleicht dem bei iOS. Es ergibt sich der Umrechnungsfaktor 2. 1 DIP, bei einer Pixeldichte von 320dpi, entspricht also 2 Pixeln auf dem Display.
- Bei einer Pixeldichte von 120dpi (ldpi) entspricht 1DIP = 0,75 Pixel.
- Bei einer Pixeldichte von 240dpi (hpdi) entspricht 1DIP = 1,5 Pixel.
- Seit Jelly Bean 4.1 wurde auch noch eine weitere Pixeldichte mit 480dpi (xxhdpi) eingeführt. Bei dieser entspricht 1DIP = 3 Pixel.
- Beim 2012er Nexus 7 finden wir eine Pixeldichte von 217dpi (tvdpi). Dabei entspricht 1DIP = 1,33 Pixel. Das kommende Modell erhöht die Pixeldichte auf 323dpi, 1 DIP entspricht hier rund 2 Pixeln.
Nun kann man also in den Layouts alle möglichen Elemente in DIP definieren und erhält auf jeden Bildschirm bzw. jeder Auflösung fast die gleiche physikalische Größe. Somit können Touch-Targets in der richtigen, weil bedienbaren Größe gehalten werden.
Und wo ist jetzt der versprochene Unterschied zwischen iPad Mini und Nexus 7?
Wir haben also festgestellt, dass ein iPad Mini die gleiche Arbeitsfläche hat wie ein 9,7" iPad und somit exakt das Gleiche darstellen kann. Es wird zwar alles kleiner, aber die Apps zeigen auf allen iPads den gleichen Inhalt.
Bei Android Tablets funktioniert die Bestimmung der Größe der Arbeitsfläche anders. Ich verdeutliche es mal an 2 Beispielen.
Nexus 7: Die Auflösung beträgt 1280x800px mit 7" Diagonale und führt zu einer Pixeldichte von 217dpi. Der Umrechnungsfaktor bei dieser Pixeldichte beträgt 1,33, da es sich um tvdpi handelt.
Wenn man nun die Auflösung durch diesen Faktor teil, erhält man die Größe der zur Verfügung stehenden Arbeitsfläche.
1280px / 1,33 = ca. 962dip | 800px / 1,33 = ca. 600dip
Die Arbeitsfläche beträgt also 962 x 600dip.
Nexus 10: Die Auflösung beträgt 2560 x 1600px mit 10,055" Diagonale und führt zu einer Pixeldichte von 300dpi. Damit fällt es in die Klasse xhdpi und der Umrechnungsfaktor beträgt hier 2.
2560px / 2 = 1280dip | 1600px / 2 = 800dip
Die Arbeitsfläche beträgt also 1280 x 800dip.
Dies ist genauso viel wie ein 10" Tablet mit 1280x800px (160dpi) Auflösung bis jetzt auch geboten hat. Dadurch müssen bei einer App für das Nexus 10 nur die Pixelgrafiken in der entsprechenden Auflösung neu hinterlegt werden. Das Layout bleibt das Gleiche.
Wenn man sich die Arbeitsflächen jetzt anschaut und vergleicht, kommt man zu dem Schluss, dass das Nexus 7 eine kleinere Arbeitsfläche besitzt als ein 10" Android Tablet mit der gleichen Auflösung. Somit kann man eben nicht wie beim iPad die gleichen Apps mit den gleichen Layouts verwenden, da nicht genug Platz vorhanden ist.
Somit braucht das Nexus 7, wie auch andere 7“-Tablets, sein eigenes User Interface Layout und seine eigene Benutzerführung. Das ist der große Unterschied, wieso auf dem iPad Mini ”Tablet Apps" laufen und auf dem Nexus 7 ein eigenes Layout erstellt werden muss.
Vor- und Nachteile bei iOS
Pro:
- Alle Apps des iPad bleiben mit dem iPad mini kompatibel.
- Man kennt die Größe der Arbeitsfläche und hat nur 1 Layout als Entwickler zu erstellen. Das senkt die Entwicklungskosten für den Anbieter und den Anschaffungspreis für den User.
- Bei der Verdoppelung der Auflösung müssen nur die Pixelgrafiken aktualisiert werden, was den Aufwand eines Updates minimiert.
Contra:
- iOs ist “gefangen” in seinen Auflösungen oder dem Doppelten davon. Jedoch wird es schwierig werden, 2048 x 1536px oder 960 x 640px nochmals zu verdoppeln. Wir werden also für lange Zeit diese Auflösungen sehen und wohl auch keine anderen Größen bei Geräten.
- Bei der Einführung einer neuen Auflösung werden alle vorhandenen Apps “nutzlos”. Man kann sie zwar noch ausführen, aber dies geschieht in einer “Letterbox”, wie beim iPhone 5 gut zu sehen ist (Schwarze Balken oben und unten).
- Bei einfacher Verkleinerung der Bildschirmgröße ohne gleichzeitige Verkleinerung der Arbeitsfläche kann es zu Problemen mit den Touch Targets kommen, da sie zu klein ausfallen können -> kein konsistentes Nutzererlebnis.
Vor- und Nachteile bei Android
Pro:
- Touch-Targets behalten immer die vorgesehene Größe.
- Jede Auflösung und jede Bildschirmgröße ist möglich und führt zu einer Vielfalt von Geräten mit verschiedensten Formfaktoren.
- Beim Programmieren muss man sich keine Gedanken über die Pixel machen, sondern nur über die verschieden großen Arbeitsflächen. Der Fokus kann auf die Nutzerführung und Ergonomie gelegt werden.
- Das System kümmert sich darum, die richtigen Bilder und Layouts für das jeweilige Gerät darzustellen.
Contra:
- Es müssen mehrere Layouts erstellt werden, was zu höheren Entwicklungskosten führt.
- Layouts können nie pixelgenau sein, sondern müssen in der Höhe und Breite flexibel auf kleine Änderungen reagieren können. Dadurch kann man sich nie ganz sicher sein, wie das Layout beim User dargestellt wird.
- Es besteht nicht nur ein höherer Aufwand beim Programmieren, sondern auch ein erhöhtes Fehlerpotential.
Sie sehen, beide Plattformen haben ihre eigene Vorgehensweise beim Umgang mit Auflösungen und Displaygrößen. Diese Vorgehensweisen haben Vor- und Nachteile, die sich sowohl auf das Nutzererlebnis, wie auch den Entwicklungsaufwand auswirken. Welches Konzept besser ist, kann nicht allgemeingültig und mit einfachen Worten definiert werden.
Am Ende ähnelt das Android-Konzept eher dem Konzept des modernen Web, in welchem pixelgenaue Layouts ebenfalls auf dem Rückmarsch sind, während iOS an die Glanzzeiten von Quark Xpress anknüpft. Der geringere Entwicklungsaufwand, nicht zuletzt wegen der überschaubareren Gerätezahl, liegt in jedem Falle bei iOS.
Über den Autor: Michael Panzer ist 28 Jahre alt und studiert Technische Redaktion an der HS Merseburg. In diesem Studiengang lernt man technische Sachverhalte einfach und verständlich wieder zu geben. Als kleine Übung verfasst er ab und an Artikel. Seit gut 1,5 Jahren programmiert für die Android-Plattform.
photo credit: dcysurfer / Dave Young via photopin cc
(dpe)
