Cubeware Business Intelligence Blog

Von der Krux verschiedener mobiler Betriebssysteme

Dez 4, 13 • AllgemeinNo CommentsRead More »

iPhone5c-yellowIm letzten Beitrag haben wir uns mit den verschiedenen Nutzungsmöglichkeiten eines Smartphones auseinandergesetzt. Kurz nach der Veröffentlichung wurde ich von einem Kollegen für die Behauptung gerüffelt, dass ein Smartphone für das Telefonieren optimiert sei. Natürlich ist dem nicht so – zumindest nicht nur. Ein rein zum Telefonieren optimiertes Gerät sieht in etwa so aus. Aber Smartphones sind selbstverständlich auch fürs Telefonieren konzipiert. Aber mal ehrlich: Haben Sie schon mal jemanden mit einem Samsung Galaxy Tab telefonieren sehen? Ich ja, es wirkte jedoch etwas unnatürlich – anderes Thema.

Geht man davon aus, dass ein Smartphone anderen Design-Paradigmen unterliegt als Tablets und PCs, erscheint es unlogisch, sie für das gleiche Aufgabenspektrum verwenden zu wollen. Machen Sie doch einfach mal den Selbstversuch mit einem Standardprogramm für die Tabellenkalkulation. Ich wünsche viel Spaß dabei!

Das kleinere Display des Smartphone ist der entscheidende physische Unterschied. Der psychologische Unterschied im Nutzungsverhalten wiegt jedoch mehr. Die Smartphone-Devise lautet: Immer griffbereit, immer online, immer verfügbar! Ich persönlich nutze mein Smartphone nur, wenn es mir einen tatsächlichen Mehrwert bietet – zeitlich wie funktionell. Eine BI-App muss sich deshalb von anderen Distributionsformen klar unterscheiden und sollte nicht als Surrogat verstanden werden. Auch sollten die Informationen, die ich über eine BI-App erhalte, nicht identisch sein mit denen, die ich über klassische BI-Systeme beziehe. Gerade bei der Entwicklung von Smartphone-optimierten BI-Apps gilt es, das „natürliche“ Nutzungsverhalten optimal abzubilden. Die visuelle Aufbereitung der Informationen für das kleinere Display nimmt dabei eine Schlüsselrolle ein. Nur wenn die Adaption optimal geschieht, bleibt der zeitliche Vorteil gegenüber anderen Gerätetypen bestehen. Wenn nicht, werden Nutzer allein durch das Scrollen und Zoomen in Tabellen und Grafiken unglaublich viel Zeit verlieren – vom steigenden Frustrationslevel ganz zu schweigen. Smartphones haben durch ihre inhärente Internetfähigkeit, durch verschiedene geräteseitig verbaute Sensoren und durch ihre Funktion als Personal Information Manager (PIM) viel mehr Möglichkeiten zur bedarfsgerechten Informationsaufbereitung als ein Tablet oder der klassische PC. Warum also nicht Synergien suchen und konsequent ausnutzen? Anhand der GPS-Koordinaten und dem synchronisierten Kalender eines Außendienstlers ließe sich so beispielsweise die aktuelle Umsatzentwicklung des zu besuchenden Kunden auf dem Display anzeigen.

Der Zugriff auf diese Systemfunktionen setzt jedoch eine fundierte Auseinandersetzung mit dem jeweiligen Betriebssystem voraus. Hybride Ansätze auf HTML5-Basis oder spezielle Frameworks stoßen hier schnell an ihre Grenzen. Die Aussage, ‚eine App für alle Geräte‘, klingt verlockend, hält aber nur rudimentären Anforderungen stand. Den kleinen (und großen) Raffinessen der einzelnen mobilen Betriebssysteme wird ein hybrider Ansatz nicht gerecht. Nichts spricht gegen eine partielle Einbindung von hybriden Elementen, um sich doppelten Programmieraufwand zu sparen. Dabei sollte aber stets hinterfragt werden, ob dadurch der Nutzen der App nicht zu stark eingeschränkt wird.

Eine simple App mit eingeschränktem Funktionsumfang lässt sich mit dem hybriden Ansatz schnell entwickeln und auf verschiedenen Endgeräten bereitstellen. Spezifische Gerätefunktionen werden aber vom HTML5-Standard meist nicht unterstützt oder müssen im jeweiligen Framework explizit zur Verfügung gestellt werden. Jedoch bleibt bei dem Versuch, mit einem hybriden Ansatz spezifische Eigenheiten der verschiedenen Geräte abzufangen, eine große Menge an ungenutztem Code zurück. Dieser Überschuss hat dann meist negative Auswirkungen auf die gesamte App-Performance. An dieser Stelle stechen wieder die Aspekte „Zeit“ und „Frust“.

Weiterhin gilt es abzuwägen, inwieweit die Einheitlichkeit der Apps für verschiedene mobile Betriebssysteme gewährleistet sein soll oder ob der Fokus eher auf der stimmigen Einbettung in das jeweilige OS liegt. Ein kohärentes Design bei den eigenen Apps für verschiedene Systeme entspricht vielleicht der Corporate Identity, aber die wenigsten Nutzer werden in ihrem Alltag regelmäßig zwischen einem Android- und einem iOS-Tablet wechseln. Bestimmt werden sie aber mehr als eine App auf dem jeweiligen Endgerät nutzen. Eine App sollte sich daher auch so anfühlen, als gehöre sie dort hin. Sie sollte nativ sein.

Dies betrifft nicht nur das spezifische Aussehen von Buttons. Die einzelnen Betriebssysteme verfolgen eigene Design-Richtlinien. Um mal ein paar offensichtliche zu nennen: Android bietet Widgets (Mini-Apps, die Informationen direkt auf dem Startschirm integrieren), Windows 8 hat Live-Tiles (App-Icons bieten bereits kontextabhängige Informationen) und iOS setzt auf Push-Nachrichten im Lock-Screen. Alle drei Betriebssysteme ermöglichen es dem Nutzer, an Informationen zu gelangen, ohne die App zu öffnen – auf ihre eigene Art und Weise. Alle drei Varianten müssen unterschiedlich angesprochen werden und setzen eventuell unterschiedliche Informationen aus der eigenen App voraus. Der Nutzer erwartet, dass diese Betriebssystem-spezifischen Features unterstützt werden. Neben diesen offensichtlichen Unterschieden gibt es noch zahlreiche weitere Feinheiten, oftmals auch weniger augenfällig, die aber ebenfalls maßgeblich für das Nutzungserlebnis sind.

Ein weiterer Aspekt, den es zu berücksichtigen gilt, ist das Look-and-Feel der Betriebssysteme. Windows Phone 8 und Android bedienen sich eines stets verfügbaren Zurück-Buttons, der in allen Apps zum Einsatz kommt. Bei Windows 8 oder iOS sucht man Vergleichbares jedoch vergeblich. Mit der nunmehr siebten Version von iOS wurde in Safari eine Zurück-Wischgeste eingeführt. Vorherige iOS-Versionen unterstützen dieses Feature nicht. Bei Windows 8 werden Einstellungen über ein Fly-Out am rechten Bildschirmrand aufgerufen, bei iOS werden die App-Einstellungen zentral verwaltet und Android lässt Einstellungen innerhalb jeder einzelnen App machen. Diese Liste mit identischen Funktionalitäten, die aber anders designt wurden, lässt sich beliebig fortführen. Im Ergebnis sollte eine gute App aber all diesen Betriebssystem-bedingten Besonderheiten Rechnung tragen. Nur dann lässt sich die Gunst der Endanwender gewinnen – wohlgemerkt nur im Hinblick auf das reine Nutzungserlebnis. Von den fachlichen beziehungsweise inhaltlichen Aspekten einer App war bis jetzt überhaupt noch nicht die Rede.

Kleine Randnotiz: Mobile Betriebssysteme neben Android, iOS und Windows Phone 8 habe ich absichtlich nicht berücksichtigt. Deren Verbreitung im Business- und Consumer-Umfeld ist hierfür noch zu gering. Um einem möglichen Diskriminierungsvorwurf vorzubeugen, hier noch das ein oder andere mobile Betriebssystem beim Namen: Symbian, RIM, Web OS, Windows Phone 7, Bada … Sollten Ihnen noch weitere einfallen, gerne als Kommentar einfach unter diesen Beitrag schreiben. Bekommen wir zwei Hände voll?
Natürlich interessieren mich auch Ihre Erfahrungen hinsichtlich der Usability von (BI-)Apps und welchen Entwicklungsansatz Sie präferieren und vor allem das „Warum“.

Autor: Christoph Hein, Produktmarketing

Tags: ,

Comments are closed.