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.

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.

Robots Exclusion Standard: Ein Test

Für einen Test muss ich hier mal zwei (Sub-)Domains verlinken. Über diese Links werden die beiden Domains dann von den Search Engine Crawlern gefunden. Da bei beiden Domains die robots.txt unterschiedlich gesetzt ist, sollte nur eine der beiden Domains in den Index aufgenommen werden.

Warum dieser Test? Ein Bekannter hat mal beobachtet, wie seine Site trotz robots.txt im Google Index gelandet ist. Hiermit wollen wir jetzt prüfen, ob dies an Fehlern in der robots.txt lag oder ob sich nicht alle Crawler an den Robots Exclusion Standard halten. Dieser ist nur eine Empfehlung.

• http://robots-allow.smilinginthesun.de/
• http://robots-disallow.smilinginthesun.de/

Ergebnisse

Wie den Screenshots zu entnehmen ist, wurden beide URLs in den Google-Suchindex aufgenommen. Auch wenn bei der Disallow-Variante zwar keine weiteren Informationen ausgewertet wurden, so ist die URL doch im Index. Will man eine Domain also nicht öffentlich sichtbar machen, sollte sie auch nirgendwo verlinkt sein.

Auch eine Suche nach z.B. "robots disallow smiling the sun" liefert dieses Ergebnis - es liegt also nicht daran, dass die genaue URL bekannt ist.


Zu beachten ist, dass dieser Test mit zwei Sub-Domains einer registrierten Domain durchgeführt wurde. Ob dies Einfluss auf die Aufnahme in den Index hat, kann ich nicht sagen.

Usability-Tests mit Kindern durchführen 1: Die Einleitung

Bei Kindern zwischen 3 und 12 Jahren, sind die verschiedenen Fertigkeiten sehr unterschiedlich weit entwickelt. 

Dies betrifft nicht nur die Fähigkeiten beim Umgang mit dem Computer, sondern auch die Aufnahmefähigkeit und das Verständnis dafür, gestellte Aufgaben gezielt umzusetzen. Nicht zuletzt ist beim Auswerten der Ergebnisse zu bedenken, dass die Kritikfähigkeit und -bereitschaft sich von der erwachsener Menschen und auch innerhalb dieser Altersspanne sehr stark unterscheidet. 

Aus diesen und weiteren Gründen ist es daher unbedingt erforderlich, dass man bei Usability-Tests mit Kindern auf diese Eigenschaften und Bedingungen gezielt eingeht. Nur so kann ein erfolgreiches Gelingen und verwertbare Ergebnise sichergestellt werden. 

In den folgenden Beiträgen gehe ich auf diese Feinheiten ein. In diesem Beitrag beschäftigen wir uns zunächst mit der Einleitung der Tests:

Das System wird getestet, nicht das Kind

Wie auch bei Tests mit Erwachsenen ist es besonders wichtig zu verdeutlichen, dass das System getestet wird und nicht das Kind. Das Kind darf gerne Fehler machen - ja es hilft sogar, wenn es Fehler macht, denn die anderen Kinder, die später das Produkt verwenden werden, werden auch Fehler machen. Daher ist es wichtig zu testen, wie sich das Produkt dabei verhält.

Es muss klar gestellt werden, dass die Meinung des Probanden zum Produkt und ihre Mithilfe gefragt sind. Es geht nicht darum die Leistung des Kindes zu messen oder gar zu beurteilen.

Wenn die Kinder nicht weiterkommen, liegt es in der Regel an dem Produkt und nicht an dem Kind.

Sollten die Eltern nach der Einleitung im Testraum bleiben wollen, sollten sie nach Möglichkeit außerhalb des Sichtfeldes platziert werden. Außerdem schon vor der Session instruieren, dass sie keine Hilfestellungen geben dürfen und ihr Kind nicht ablenken sollen.

Hilfestellung

Da Kinder in der Regel mehr Hilfestellung erwarten, als erwachsene Probanden, muss vor dem Test erklärt werden, dass das Kind die Aufgaben selbstständig durchlaufen soll. Gibt es im späteren Verlauf doch viele Fragen, sollte mit Gegenfragen reagiert werden. "Was meinst Du?"

Usability-Tests mit Kindern vorbereiten

Ein Usability-Test sollte gründlich vorbereitet werden. Dies gilt natürlich auch insbesondere für Tests, die man mit Kindern durchführt.


Folgende Punkte empfehlen die Autoren von "Guidelines for Usability Testing with Children":

• Das Testlabor sollte kinderfreundlich eingerichtet werden, um etwas vom "offiziellen Charakter" zu verlieren. ZB. ein paar Poster an der Wand. Eine Spielecke wäre aber zu viel des Guten und würde eher ablenken.
• Vorschulkinder sollten das gleiche Eingabegerät benutzen können, wie es dies von zu Hause gewohnt ist: Maus vs. Trackball, 1 vs. 2 Button. Die Geschwindigkeit des Mauszeigers sollte auf das Minimum reduziert werden.
• Die Laborausrüstung (Kameras, Mikrophone, etc.) müssen zwar effektiv eingesetzt werden (damit man zB. die Mimik des Kindes gut erkennen kann), sollten aber so unauffällig wie möglich platziert werden. Die Kamera sollte nie direkt vor dem Probanden platziert sein.
• Maximale Dauer eines Tests: eine Stunde, Vorschulkinder: eine halbe Stunde (hier zusätzliche Zeit für freies Spielen und Exploration einplanen).
• Die Pausen zwischen zwei Probanden sollten größer eingeplant werden als gewohnt, da die Zusammenarbeit mit Kindern für den Testleiter anstrengender ist als mit Erwachsenen.
• Wie immer gilt, dass die Reihenfolge der Tasks zwischen den Probanden variieren sollte. Dies ist hier besonders wichtig, da Kinder schneller ermüden und unkonzentrierter werden, als Erwachsene.
• Es sollten immer Kinder für Tests ausgewählt werden, die bereits mindesten ein halbes Jahr Erfahrungen im Umgang mit Computern haben...
• ... allerdings sollten Kinder mit überdurchschnittlichen Erfahrungen (Programmieren, Webseiten bauen) vermieden werden (wenn dies nicht explizit die Zielgruppe ist).
• Kinder von Kollegen und die eigenen sollten nicht als Probanden eingeladen werden: Erstens sind ihnen Terminologien aus dem Produkt, der Branche bekannt und zweitens haben sie eine andere Einstellung zu dem Produkt, wenn ein Elternteil es mit entwickelt hat. Diese Faktoren verfälschen das Ergebnis.