2012-06-20

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/updatesbagcheck.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.



2012-06-15

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?


2012-06-12

Keep it Simple. At First. - Designing spielbasierte Tools für Kinder

Sarah Clue und Constance Steinkuehler beschreiben in "UX User Experience, Volume 10, Issue 1, 2011" (S.28ff), wie die World of Worcraft Entwickler es geschafft haben, das Interface so zu gestalten, dass es für Einsteiger einfach und übersichtlich ist und für erfahrene Spieler die notwendige Komplexität bietet, um alle benötigten Funktionen abzubilden.

  1. Das Interface ist beim Einstieg in das Spiel einfach gehalten und bietet nur die notwendigsten Funktionen. So können die Spieler am Anfang zum Beispiel einfaches Herumlaufen üben.

  2. Informationen und Funktionen werden erst nach und nach eingeführt - wenn der Spieler an entsprechende Stellen kommt, an denen er sie benötigt.

  3. Die Menge an geschriebenen Informationen ist auf ein Minimum reduziert. Es würde den Spieler eher stören, wenn am Anfang jede Minute ein neues Tutorial-Fenster aufpoppen würde.

  4. Individualisierung des Interfaces ist möglich: Spieler können selbst Interface-Addons entwickeln und installieren - je nach Bedarf und individuellem Gameplay. Dies optimiert nicht nur die Effizienz beim Spielen sondern fördert gleichzeitig auch die Community.


2012-06-05

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.