Die Sieben Tödlichen Mythen über Mobile

Gestern Abend gab es zwei sehr interessante Vorträge bei der Interaction Design Association Hamburg.

Josh Clark, author of "Tapworthy: Designing Great iPhone Apps" and "Best iPhone Apps", and Karen McGrane, author of "Content Strategy for Mobile," (coming in 2013), will each give a thirty minutes presentation talking about mobile usage, design and content creation.

Josh Clark (http://www.globalmoxie.com/) hat über "The Seven Deadly Myths of Mobile" gesprochen. Anschließend Karen McGrane (http://www.karenmcgrane.com/) über „Adapting Ourselves to Adaptive Content“.

Zunächst zu den Sieben Tödlichen Mythen über Mobile:

A set of persistent myths are driving the development of mobile experiences that frustrate more than delight. "Info snacking." "The distracted, rushed mobile user." Those behaviors don't always, or even usually, exist, yet too often we design solely for those contexts, creating mobile apps as lite versions of their desktop counterparts. Instead, mobile apps should almost always do MORE than their desktop counterparts. Josh Clark explains the difficult craft of designing simple interfaces for complex mobile apps, sharing techniques for future-friendly mobile efforts and, along the way, debunking seven stubborn mobile myths.

Mythos #1: Mobile-Users sind immer in Eile - sind quasi IMMER auf dem Weg zum Bus

Ebay verkauft täglich Autos über ihre mobile App, also gibt es wohl doch User, die am Smartphone sitzen und Zeit haben sich mit dem Content in Ruhe zu beschäftigen.

• 28% der mobile Users in den USA nutzen (fast) ausschließlich mobile Geräte. 
• 11%, wenn man nur erwachsene User betrachtet.

Mobile != In Eile

Mythos #2: Mobile = Weniger

Schon mal auf einer smartphone-optimierten Website gewesen, deren Content sich perfekt an die Displaygröße angepasst hat? Dann aber den entscheidenden Menüpunkt nicht gefunden (weil der Anbieter der Meinung war, dass die Mobilen-User sich nicht dafür interessieren)? Ganz unten findet man ja meist einen Link „Full Desktop Version“. Dann hat man zwar eine nicht leserliche minikleine Seite auf dem Screen, aber irgendwie bekommt man es schon hin - durch vieles scrollen und zoomen - dann doch den Menüpunkt zu finden, zu bedienen und schwupp, nur wenige genervte Minuten später hat man endlich die Infos, die man gleich hätte haben können, wenn der Anbieter den Menüpunkt einfach auch in die mobile Version der Website gepackt hätte.

Der Fehler ist, dass Kontext und Vorsatz häufig verwechselt werden!
Der Mobile-User kann ja auch auf der Couch sitzen und nur zu faul sein, sich seinen Laptop zu holen oder ins Arbeitszimmer zu gehen.
Für uns heißt das, dass die mobile Version eines Services immer den vollen Umfang bieten sollte.

Mobile != Weniger

Mythos #3: Komplexität vermeiden und
Mythos #4: Extra Taps vermeiden

Die Regenschirm App verbirgt die Komplexität der Wettervorhersage in die einfache Antwort: „Brauche ich heute einen Schirm oder nicht?“ Sie kennen ihre User, denn dem Wetterinteressierten wären das zu wenige Informationen. Der Wetterexperte möchte eine komplexe App mit diversen Wetterdaten. Diese sollten ihm auch geboten werden. Komplexität sollte also nicht zwingend vermieden werden - sollte nicht als Gegenteil von Einfachheit verstanden werden. Ein komplexer Service kann ein einfaches Interface haben. Früher, als Webseiten noch Minuten zum Laden brauchten, war es wichtig, den User mit möglichst wenig Klicks zum Ziel zu bringen. Heute gilt dies nicht mehr. (Anm.: Ich habe auch mal gelesen, dass mehrere Klicks bei denen der User genau weiß, was sich hinter dem Link verbirgt, weniger störend empfunden werden, als ein einzelner Klick, bei dem der User dies nicht weiß. Wenn die iOS Human Interface Guidelines von Apple sogar davon sprechen, dass Scrollen auf einem Touch-Device zur positiven User Experience gehören, dann kann ein Tab wohl kaum störend sein.)

Das Interface eines Services sollte Komplexität in der Form verbergen aber bereitstellen, in der ein User an ein Problem herangeht. Frage -> Antwort -> Frage -> Antwort: Der User hat eine Frage: „Wie wird das Wetter die Tage?“ Die App antwortet: „sonnig“. Frage: „Wie wird das Wetter morgen genau im Verlaufe des Tages?“ Tab auf die zusammenfassende Vorhersage für morgen. Als Antwort wird dann der genaue Wetterverlauf gezeigt. Kaum ein User braucht wohl bei einer 5-Tages-Vorhersage bereits stundengenaue Werte.

Wenn jeder Tab neue und zufriedenstellende Informationen auf die aktuell gestellte Frage bietet, ist jeder Tab ein Gewinn für den User und trägt zur positiven User Experience bei.

Komplex != Kompliziert
Tab-Qualität sollte also vor Tab-Quantität stehen.

Mythos #5: Man braucht eine Mobile-Website

Es gibt so viele verschiedene Bildschirm-Formate im mobilen Bereich. Wie viel Aufwand will man betreiben, um all diesen Auflösungen gerecht zu werden? Und was ist mit den diversen anderen Kanälen? Warum nicht in ein paar Jahren auch auf dem TV stattfinden? Oder Radio. Sprachausgabe und -erkennung - Zukunft? Noch ist Apples Siri beta, aber bald wird es wohl Standard sein.

„Es gibt kein ,mobiles' Web.“ Es gibt nur Content. Einmal generierter Content muss für alle Kanäle passen. Content First, nicht Mobile First.

URL: Uniform Resource Locator (dt.: einheitlicher Quellenanzeiger). Schon mal einen Link auf mobile.mySite.com/... zugeschickt bekommen und auf einem großen Monitor geöffnet?
„Es gibt nur ein Web.“

Mythos #6: Mobile = App

„Eine App ist keine Strategie, es ist einfach nur eine App“ - ein Container!
Ein Produkt an sich ist meist nur Content.
Bruce Lee sagte einmal:

Wenn man Wasser in eine Tasse gießt, wird es zur Tasse. Gießt man Wasser in eine Flasche, wird es zur Flasche. Gießt man Wasser in eine Teekanne, wird es zur Teekanne.

Das Ziel: Ein Content, auf allen Geräten, immer synchron.

Mythos #7: CMS und API ist nur für Datenbank-Nerds

Ziel ist es nicht, das Design zu überdenken, wie der Content wo dargestellt werden soll. Ziel ist es, das Anlegen und die Speicherung des Contents zu überdenken. Wenn man alles richtig macht, dann ist Metadaten angereicherter Content, der über sinnvolle Schnittstellen angeboten wird, in jeglicher Form nutzbar - völlig unabhängig vom Präsentations-Layer.

Content as a Service

Dies war auch die Kernaussage von Karen McGrane über die Frage, wie wir uns anpassen müssen, um in der Zeit des „anpassbaren Contents“ Schritt halten zu können.

For years, we've been telling designers: the web is not print. You can't have pixel-perfect layouts. You can't determine how your site will look in every browser, on every platform, on every device. We taught designers to cede control, think in systems, embrace web standards. So why are we still letting content authors plan for where their content will "live" on a web page? Why do we give in when they demand a WYSIWYG text editor that works "just like Microsoft Word"? Worst of all, why do we waste time and money creating and recreating content instead of planning for content reuse? What worked for the desktop web simply won't work for mobile. As our design and development processes evolve, our content workflow has to keep up. Karen will talk about how we have to adapt to creating more flexible content.

Präsentations-unabhängiger, strukturierter und mit Metadaten angereicherter Content als Ausgangslage, um schnell auf allen Plattformen stattfinden zu können.
Von „Create Ones, Puplish Everywhere“ spannte sie den Bogen zu „Publish Once, Distribute Everywhere“. Umdenken ist gefragt.


Vielen Dank auch an FORK als Veranstalter.