Designing Games for Non-Gamers

Dennis Paiz-Ramirez, Sarah Chu, Allison Salmon, and Belinda Gutierrez in User Experience Magazine: Volume 10, Issue 4, 2011

Tutorials: Too Much or Not Enough?

They tested their prototype of a real life simulation game with gamers an non-gamers and a pattern began to emerge:

Ann, the more experienced gamer, was willing to explore; Betty [familiar with computers but with little video game experience] was hesitant to click on anything before confirming it was the right action. [...] We learned that the tutorial should be explicit about what players can do in the game and should explain what happens when a player performs a game action. We also need to allow users to skip the tutorial and explore the game if they feel comfortable doing so.

I think it is import to tell the user, that she can "skip the tutorial and explore the game [AND can] feel comfortable doing so". -- Whatever tell means in this context. -- Otherwise the user might not trust that she can explore it without reading through all the tutorial stuff.

Conventions: Is That Supposed to Mean Something?

They have grayed-out non-clickable buttons, but:

it wasn't enough to follow web standards, especially when the target audience has little familiarity with digital media.

So they decided to not display buttons until they are introduced.

Content: Missing the Point

Too many feature, that are not directly connected to the main goal of the game, distracted the user from the main goal. Also, the head-up display became overcomplicated.
Featuritis -- who does not know the problem, but everybody runs into it from time to time -- everybody!

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.

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.