Die Zukunft von Mobile

Die Zukunft von Mobile heißt nicht Phone oder Tablet;
die Zukunft von Mobile bedeutet, sich diverser Umgebungen bewusst zu sein.
(Menschen lassen sich nicht auf Finger und Augen reduzieren ;)

Bildschirme sind billig, sie werden überall sein;
Personal Devices brauchen eine einheitliche Schnittstelle, dann können wir unsere Aufgaben über mehrere Bildschirme verteilen. Was ist das für ein Nutzererlebnis? Frage an die User Experience Spezialisten.

Mobile und Cloud Computing: Toy Story wurde in 800.000 Rechner-Stunden erzeugt - über die Cloud ginge das in fünf Minuten.

Die Interaktion zwischen Personal- und Mobile Devices bringt völlig neue User Experience; Beispiel: Nike plus.


Offene Punkte für die Zukunft von Mobile: 

• Design, Hardware und Software müssen eng zusammenspielen.
• Umdenken: Geräte sollen auf Menschen reagieren, nicht umgekehrt.
• Neue Entwicklungsprozesse: Dokumentation, Produktion und Nutzung liegen verdammt eng beieinander; es geht nicht mehr um Bürosoftware, die man später den Mitarbeitern einfach vorsetzt.
• Orts- und kontextabhängige Nutzung rückt noch weiter in den Vordergrund. 
• Computer müssen Content filtern und verarbeiten und dürfen nur relevanten Content an den Nutzer liefern. Ansonsten ist die permanente Anwesenheit von Technik nicht akzeptabel.

Quelle: Luke W, Design for Mobile: Future of Mobile UX:

In his opening keynote at the Design for Mobile conference in Chicago IL,. Jonathan Brill discussed several future scenarios for mobile user experience and their potential.

What Brill is focused on now: Multi-display/device interaction, 3D and gestural interfaces, glasses 3D display, Radios in things besides phones, positional and visual search.
Voice recognition, roll-up displays, and mesh networks have been “three years away” for a long time now.
When investigating, predicting, developing new technologies, laughter and delight signal a business opportunity.

HTML5 und Mobile Apps

Warum mögen sich HTML5 und Mobile Apps nicht?

Immer wieder hört und liest man, dass HTML5 keine brauchbare Alternative zu nativen Apps ist - Hauptproblem: Performance!

So hat sich jetzt zum Beispiel angeblich auch Facebook dazu entschlossen, ihre iOS App noch einmal von Grund auf neu zu entwickeln (Facebook Abandoning HTML5 to Speed Up iOS App).

Auf der anderen Seite schafft es aber zum Beispiel ZaptoLab das beliebte Cut the Rope auf HTML5 / JavaScript zu portieren (Behind the Scenes). - Zwar mussten sich die Entwickler sehr auf die Performance konzentrieren, aber es ist ihnen gelungen.

Nun frage ich mich, ob die Performance-Probleme durch die Zwischenschicht zwischen nativ und HTML zustande kommen, ob die meisten HTML-Apps einfach schlecht entwickelt sind oder ob die Hardware der mobilen Geräte der ausschlaggebende Grund sind.

Mobile & UX

Kleine Auszüge aus Jared Spool Mobile & UX: Inside the Eye of the Perfect Storm (Video) auf der Mobilism 2011

Sturgeon's Law

Warum sind 90 Prozent aller Mobile-Anwendungen Mist?

90 Prozent von allem ist Mist!

Marktreife

Das generelle Erlebnis ist wichtiger als neue Funktionen. 

Nutzer sind von einfachen Lösungen begeistert.

Das Kano Model

Kano fragt: 

Wann lohnt es sich, den Nutzer glücklich zu machen?

Das Kano-Model verrät, wann etwas ein Highlight ist und wann etwas zu den Grunderwartungen gehört.

Eine Achse beschreibt die User-Zufriedenheit von entzückend bis frustrierend, die andere die nötigen Kosten. 

Es spielt bei allen Bemühungen aber keine Rolle wie weit man geht, wenn die Grunderwartungen nicht erfüllt werden - diese Feature müssen IMMER vorhanden sein. Für ein langlebiges Produkt ist hierbei zu bedenken, dass die Grunderwartungen über die Zeit zunehmen. Was heute noch entzückt, kann zum Beispiel so hilfreich sein, dass es in Zukunft schon  zu einer erwarteten Basisfunktion wird.

"The Perfect Storm"

UX-Teams aufzubauen, die in diesem Rahmen arbeiten, ist sehr schwierig. Teams, die herausragende User Experience bauen möchten, brauchen die verschiedensten Fähigkeiten wie zum Beispiel Schreiben, Informatins-Architekturen, Design-Prozess-Management, User Research Techniken. Darüber hinaus muss es ein Verständnis der verwendeten Technologie, ROI, Soziale Netze, Marketing, Analytics, Geschäftswissen, Story-Telling und weiterem geben.

Ziel ist es, in Sturgeon's Law zu investieren und sich auf das Nutzererlebnis zu konzentrieren, statt an Technologie und Features zu denken.

Basisfunktionen müssen erfüllt werden und darüber hinaus sollten einige Highlights eingebaut werden.

Nicht immer Responsive Web Design

Responsive Web Design ist in aller Munde und wird derzeit sehr stark gehyped. Auch Luke W ist Befürworter von Responsive Web Design - dennoch hatte er gute Gründe für die mobile Variante von Bagcheck ein eigenes Interface zu entwickeln. Diese Gründe liefert er in seinem Blog-Post "Why Separate Mobile & Desktop Web Pages?", die ich hier kurz aufgreifen möchte:

Oberstes Gebot bei dem Projekt war Site Performance und Geschwindigkeit. Unter diesen Prämissen - und der generellen Philosopie: "Nur so viel wie nötig" - findet Luke vier Gründe:

Sourcecode Reihenfolge

Der Kern von Responsive Web Design ist die Auslieferung einer einzigen (HTML-) Website-Variante an alle Geräte. Die Anzeige des Contents passt sich dann entsprechend den Möglichkeiten des Gerätes an (in der Regel durch CSS gesteuert).

HTML Markup hat aber eine Reihenfolge, die bestimmt, in welcher Reihenfolge was gerendert wird. Diese kann natürlich mittels JavaScript manipuliert werden - aber dies zuverlässig für alle Geräte umzusetzen ist eine herausfordernde Aufgabe.

Ein einfaches Beispiel ist ein Site-weites Navigationsmenü. Während es auf Desktop-Größen in der Regel oben angeordnet ist, ist es für mobile Geräte, insbesondere in Smartphone Größe üblich, diese Menüs ans Ende der Seite zu rendern.

Medien

Responsive Web Design setzt sich auch mit Medien auseinander. Grafiken und Videos werden auf kleineren Displays kleiner dargestellt. Allerdings ist skalieren hier nicht unbedingt die beste Wahl. Erstens werden dabei unnötig Große Dateien übertragen (gerade an mobile Geräte mit evtl. nicht besonders schneller Anbindung). 

Anm.: Hier kommt zum Beispiel auch die iOS Retina--Display Diskussion ins Gespräch, da es sich für diese Geräte anbietet - genügend Bandbreite vorausgesetzt - hochauflösende Grafiken nachzuladen. (Siehe z.B. What the New iPad’s Retina Display Means for Web Developers. - Danke für den Tipp Moritz)

Zweitens kann es durchaus sinnvoll sein, dass man die Medien für unterschiedliche Display-Größen unterschiedlich aufbereitet: Große Grafiken mit vielen Details vs. kleine Grafiken mit weniger Details, also einem anders gewählten Ausschnitt.

URL-Struktur

Anm. vorab: Wie ich in Mobile und Content oder besser Content vs. Mobile? geschrieben habe, gibt es nur ein Web und ein und der selbe Content sollte auch unter ein und der selben URL zu erreichen sein. Aber:

Es gibt Situationen, in denen eine eigene URL-Struktur für kleinere Screens durchaus Sinn ergibt: Luke nennt als Beispiel eine Seite mit User-Content, Kommentaren dazu, Updates und "Likes". Dies passt alles zusammen gut auf eine Desktop-Seite und ist zum Beispiel unter der URL bagcheck.com/bag/7811 zu erreichen. Für kleinere Bildschirme ist es aber durchaus sinnvoll, einige der Informationen auf Unterseiten auszulagern, die dann unter den URLs bagcheck.com/bag/7811/updates, bagcheck.com/bag/7811/comments und bagcheck.com/bag/7811/likes zu erreichen sind.

Anwendungsdesign

Ein letzter entscheidender Punkt, der zu bedenken ist, ist folgender: Auf kleinen Displays kann es sinnvoll sein, längere Tasks von einer Seite auf mehrere zu verteilen.

Drei wesentliche Attribute eines UX-Teams

Jared Spool über die drei wesentlichen Attribute eines effektiven UX-Teams in Dawning of the Age of Experience:

1. Vision

Kann jeder aus dem Team beschreiben, wie es sich anfühlen wird, wenn man ihr Produkt in fünf Jahren verwendet?

2. Feedback

Es muss Teammitglieder geben, die die Zielgruppe persönlich in direkter Interaktion mit dem Produkt erlebt haben. Minimal-Ziel: 2 Stunden Userbeobachtung jeweils innerhalb von sechs Wochen. Die besten Firmen machen dies wöchentlich.

3. Kultur

Werden Mitarbeiter für Designfehler belohnt? Jeder Fehler birgt die Möglichkeit etwas zu lernen: Was haben wir über unsere Nutzer gelernt? Über unser Produkt? Über uns selbst?