Technische Herausforderungen

Nach den eher businessorientierten UX Themen der letzten Tage heute als persönliches Highlight für mich User Experience in Spielen

Spiele sind Programme mit Unterhaltungsaspekt!

Unterschiedliche Plattformen:

Diese Programme gibt es heute für die unterschiedlichsten Plattformen wie zum Beispiel PC, Mac, XBox, Playstation, Surface, Gameboy, Handy sowie die “historischen Spielecomputer”. Die aufgezählten sind jedoch lange nicht alle.

Aufteilung in Genres:

Spiele werden auch in unterschiedlichste Kategorien untergliedert wie Board / Card-Games, Point & Click, Echtzeit / Strategie-Spiele, Jump & Run, First-Person, Rennen, RPG / Hack & Slay und Multiuser-Games und dennoch sind sie alle ähnlich vom Grundaufbau.

Die Innovation liegt in der Spieleidee innerhalb eines Genres.

Das Game steht im Mittelpunkt und es wird mit einem Eingabeerät bedient. Z. B. Keyboard, Mouse, Controller (Joystick, Padel, Gitarre) , Hand (Touchscreens), Gestensteuerung (Kinect).
Die folgenden technologischen Aspekte wie Sound, 3D-Raum, Tags, Internet kommen noch hinzu.

Spielekonzepte:

Strategie-Spiele
First-Person-Shooter = Ich steuere und sehe mich bewegen durch das Spiel bewegen. Informationen ganz dezent. Wenig Raum wird für das UI genutzt.

Hack & Slay = Ich schaue auf die Welt von oben und steuere den Avatar. Auch hier wieder maximaler Gameraum und das UI dezent drumrum.

Rollenspiel = Hier wird die Story beschrieben was die Story ist und der Nutzer kann diese beeinflussen.

MassivMultiplayerOnlineRolePlayGame = Obschon sich alles im Zentrum abspielt, braucht das Game sehr viele Informationen über die Umwelt. Das macht das Interface, das wieder eher am Rand steht sehr voll.

Rennspiel = Rennen innerhalb der 3D-Welt wie bei einem First Person Shooter. Interaktion mit der Welt steht im Fordergrund – Headup-Display.

Moderne Spiele arbeiten im 3D-Raum. (Brettspiel-Klone und alte Casual Games ausgenommen). 3D geschieht in Echtzeit, nicht Eventgetrieben.

While (true) Schleife:
Technisch gesehen immer die gleiche Gameloap: Das Game prüft, ob was passiert und zeichnet es am Bildschirm.

Technische Limits:

Echtzeit-Rendering, Netzwerkkommunikation, Soundeffekte, verschiedenste Eingabeformen, 3D-Projektion

Harte Entwickler-Verzahnung sowie Game-Designer vs. UI-Designer. Die Zusammenarbeit zwischen Entwickler und Designer ist sehr wichtig auch wenn oft nicht einfach.

Neuerungen in den Spielen?

Be Neuerungen ist eines dabei jedoch ganz wichtig das Konzept muß gleich bleiben. Neuerungen wie neue Steuerung oder neues Interface sind gefährlich. Denkbare Neuerungen sind zum Beispiel eine Gute Story (Monkey, Gothic, …), eine Bessere grafik (FarCry, Halo …), Aktuellere Inhalte oder sogar Neue Features jedoch immer unter dem Aspekt die Anforderungen an ein UI zu beachten.

Die Anforderungen an das UI eines Spieles sind unter anderem das es schnell verständlich, logisch und ergonomisch aufgebaut sein muss.

Nun folgen ein paar Beispiele für neue gute Konzepte:

Limbo (Jump and Run ohne UI in Schwarzweiss)
Flow (hoch intuitiv gesteuertes kleines Planton, was sich “Groß” frisst. Das Game wird ornamental-typografisch)
Dead Space (Egoshooter komplett ohne UI)
Mirrors Edge (Ego-Jump&Run als Parkour-Läuferin. Kein Interface, sondern nur Rot als Umfärbung der Objekte, die die Richtung bestimmen.

Umsetzungstechnologien:

Es gibt für Spiele verschiedenste Umsetzungstechnologien wie Hardcore-3D (C++, Direct X und OpenGL
X-Box, Phone), Silverlight (XNA ist die Plattform), Casual Games im Browser (früher Plugins – künftig Unity / HTML 5)

Fazit:
UI-Design in Spielen hat andere Konzepte, andere Interfaces, andere Controller sowie andere Prozesse.
UI Design in Spielen verwendet aber dennoch die allgemeinen Gesetze des UI Designs.

Felix Rieseberg

Beginnend mit der Aussage : Websites sind keine Flyer mehr, sie entwickteln sich mehr und mehr zu Anwendungen.

Es soll um ausgewählte Themen gehen und nicht um einen Wettlauf durch alle HTML5 Funktionen.

Zuerst geht es um Nutzerinteraktionen. Die Anzahl der Nutzereingaben wächst stetig. JQuery UI versucht zu realisieren was dringend notwendig war. Standardcontrols wie einen Datepicker einfach zu realisieren. Mit HTML5 soll z.B. der Datepicker einfach aus HTML heraus zur Verfügung stehen.

Bisher gibt es z.B. auf jeder Seite unterschiedliche Arten der Formvalidierung. Mit HTML5 kann man dem Textfeld sagen welchen Inhalt es enthalten soll, dies wird mit Eingabetypen wie input type="text für eine Mailadresse realisiert. Auch die Eingabe der Werte wird unterstützt mit Elementen wie einem Ziffernblock zur Zahleneingabe oder einem Colorpicker für Farben. Es gibt für Formulare und Formularelemente Eingabetypen, Eingabevalidierung, Autovervollständigung, Platzhalter und Checkboxen.

Demo

Es folgt eine kleine Demo mit Opera, da dieser Browser bei Inputtypes wohl die bisher beste Unterstützung bietet. Auch der IE wird gezeigt, bei dem sich die Bildschirmtastatur an ein Textfeld mit Ziffern anpasst.

Die eingebaute Validierung sorgt zusätzlich dafür,dass in einem Browser auf allen Seiten Meldungen für Falscheingaben einheitlich aussehen, da das Meldungselement vom Browser und nicht von der Seite selbst kommt.

Eine Autovervollständigung kann ganz einfach mit einer Datalist Erstellt werden.

Platzhalter realisieren einen Beispieltext ähnlich der bekannten Wasserzeichen welche beim hineinklicken verschwinden.

Zu den Checkboxen kommt ein dritter Status hinzu, der inditermant State, bei dem die Checkbox mit einem rechteck gefüllt ist.

Felix sagt kurz was ihn bisher an Formularen nervt, Punkt eins sind Kalender (z.B. Bei der Flugbuchung), Nummer zwei ist der allseits beliebte Zurück-Button (allgemeines Stöhnen im Saal).

Manipulierung der History

Hier kann bei HTML5 mit history.pushState oder history.replaceState in das Verhalten des Zurück Knopfs eingegriffen werden. Mit pushState wird eine Adresse an die Adresszeile geschickt aber nicht aufgerufen. Mit replaceState wird die zuletzt Besuchte Seite geändert.

Damit ermöglicht der pushState Parameter in die URL zu schreiben, obwohl die Daten eigentlich per Ajax zum Server gelangen.

Es findet momentan keine Common Origin Prüfung statt. Das ist für den Entwickler mächtig, für den Nutzer allerdings gefährlich.

Wo Licht ist, da ist auch Schatten und so kommt Felix jetzt zu Grenzen und Problemen.

Leider sind nicht für alle Browser eigene Controlls für alle Typen möglich.

Die Validierung bietet im Moment eine sehr geringe Flexibilität, so ist eine Prüfung über externe Schnittstellen (Bsp. Kreditkarten) nicht möglich.

Drag & Drop

Die Funktionalität ist gut, die API wohl aber sehr schlecht.

Die Grundprinzipien sind klar, werden aber der Vollständigkeit halber nochmals genannt: draggable, droppable & Datentransfer.

Die “Killerapplikation” ist die Desktopintegration z.B. der Upload von Bildern per einfachem Heranziehen in den Browser.

Es gibt eine ganze Menge Events, die meisten nur um Drag & Drop zu killen.

Neu ist das dataTransfer Objekt, auf das man im Dom und somit auch per JS zugreifen kann.

Bisher Upload und Bildauswahl per Flash, danach die Frage wer im Raum denkt das in 5 Jahren noch Flash genutzt wird. Keiner meldet sich ; )

Beispiel

Ganz kurz erwähnt wird Cross-Document-Messaging, was durch die Messaging API realisiert wird. Es folgt ein Bsp. das Bild wurde per Drag & Drop auf unseren Bilderservice geladen. Jetzt soll es auf Facebook veröffentlicht werden, was im zweitem Tab offen ist. Nach Nutzerintegration kann das Bild x nun von der einen Seite zur anderen geschickt werden.

Damit ist der Teil User Controls abgeschlossen.

Weitere Möglichkeiten von HTML5

Den Anfang macht das Canvas.

Das Canvas ist eine frei programmierbare Leinwand. Es gibt zwei Dinge zu unterscheiden, den 3D Kontext und den 2D Kontext. Um 3D soll es heute nicht gehen da es ein sehr umfangreiches Thema ist (Stichwort WebGL mit Shadern etc.) Der 2D Context wird weit unterstützt.

Das Vorgehen ist an Zeichnen angelegt, man wählt erst einen Pinsel (rot) und zeichnet dann ein Rechteck, es ist nicht möglich ein Rechteck zu zeichnen und dann zu sagen es soll bitte rot sein.

Nicht nur gerade Linien sind möglich, dafür aber Kreisbögen, Farbverläufe etc.

Felix weißt vor den Beispielen darauf hin, dass wenn irgend möglich auf Canvas verzichtet werden soll.

Es gibt viele Frameworks, die sich in Entwicklung befinden. Drei sollen heute vorgestellt werden. CAKE, fabric.js und Processing.

Es werden einige nette Effekte gezeigt, die mit CAKE realisiert sind und bisher nur mit Flash (oder Silverlight) möglich waren. Auch mit fabric lassen sich nette Animationen erstellen (z.B. Fliegende Bugs). Processing erlaubt es relativ komplexe Daten einfach zu visualisieren und animieren.

Felix warnt: das erste mal Canvas bearbeiten sieht am Anfang grausam aus, aber mit den Frameworks lässt sich in erträglicher Zeit einiges erreichen.

Jetzt kommen Media Queries, welche sich dem Problem der vielen unterschiedlichen Geräte annimmt, mit denen heute Websites angesehen/benutzt werden. Man kann jetzt mehr Sachen von den Geräten Abfragen wie z.B. Höhe, Breite, Orientierung, Seitenverhältnis, Auflösung, Color, Scan und Grid. Scan ist interessant für Fernseher und das Grid gibt an ob ein Raster zugrunde liegt (z.b. bei dem Kommandozeilenbrowser Lync).

Mit den Informationen aus den Media Queries ist es dann entsprechend möglich, je nach Gerät ein spezifisches Stylesheet zu verwenden und dem Nutzer die bestmögliche Darstellung zu bieten.

Von der Verwendung der Handheld-Eigenschaft wird abgeraten da z.B. Androide und iOS das “volle” Web bieten und die Eigenschaft ignorieren.

Jetzt kommt der Modernizer zum Einsatz, der innerhalb kürzester Zeit CSS Funktionen und Co auf Verfügbarkeit prüft. Wenn der Browser etwas nicht anbietet, greift ein polyfill (Fallback) was durch das Framework realisiert wird.

Es gibt eine Seitenempfehlung: http://Bit.ly/fr_polyfills Hier wird gut gezeigt wie man Polyfills geschickt einsetzt um HTML5 zu nutzen ohne Nutzer mit älteren Systemen auszuschließen.

Es gibt keine Fragen zu diesem wirklich guten Vortrag. Damit neigt sich der erste Tag der GUI & DESIGN langsam dem Ende entgegen. Es folgt das Panel zu ’Begriffen und Rollen’ und im Anschluß dazu die Abendveranstaltung.

Peggy leitet in das Thema mit einer Beschreibung von den Grundsätzen zu Sketch Flow Prototypen ein.
Was ist ein Sketch Flow Prototyp?

• Echte Applikationen die mit Blend erstellt werden
• Für Designer, Usability Experten und Entwickler

Warum sollte man Sketch Flow Prototypen nutzen?

• konstengünstiger und schneller als “reale” Produkte
• Nutzer Feedback
• es wird EIN Prototyp erstellt an dem alle Beteiligten mitarbeiten können

Es folgt ein kurzer Abriss über die “normalen” Prototypen.
Lars spricht jetzt über Probleme der “normalen” Prototypen. Es ist überraschend was man von kreativen Leuten geliefert bekommt.. Klassiker wie das mischen von deutschen und englischen Namen oder die allseits beliebte Solution Application. Es gibt eine Demo eines WorstCase Szenarios, bei dem man den erstellten Prototypen nur noch verwerfen kann wenn daraus ein Finales Produkt werden soll.

Nach dem don’t do folgt nun das do.
Folgende Schritte werden vorgeschlagen:

• Zielgruppen und Personas bestimmen
• Anforderungen und Nutzerwünsche
• ein Organigramm erstellen um die Kundenwünsche an den Programmierer heranzutragen.
• aus den Ideen erstellt der Entwickler eine Solution-Architektur
• Integration von ViewModels, anlegen von Views etc.

Dazu wird in einer kurzen Demo der Unterschied vom WorstCase zur guten Solution-Architektur gezeigt, mit einer Aufteilung zwischen prototypsichen Komponenten, Theme Komponenten und der Basisanwendung. Dabei ist es auch hier wieder wichtig auf die Blendability zu achten, denn Grafiker/Designer arbeiten nicht mit VS sondern mit Blend.

Es fällt die Frage wer als erstes aktiv wird? Antwort: Hier ist der Entwickler an der Reihe, denn die Probleme beginnen schon wenn man die ersten Elemente in ein von Blend erstelltes Projekt wirft mit generierten Klassen etc. Lars als Entwickler bezieht sich oft auf die Session vom Daniel, denn wenn man an dieser Stelle dem Designer die richtig vorbereiteten Grundlagen an die Hand gibt vermeidet man viele der genannten Fehler z.B. In dem man implizite Styles verwendet.

Weiter geht es mit Peggy, die Beispieldaten in die Solution integriert. Zur Anwendung in dem Prototypen kommen die richtigen Controls, so dass eine Checkbox nicht nur so aussieht als wäre sie eine, sondern eben eine Checkbox ist.Es gibt auch die Möglichkeit für den Kunden Feedback in den Prototypen zu schreiben und dieses als Datei an den Designer zu schicken damit er reagieren kann.

Der nächste Schritt geht nun wieder an Lars der die Sketch Styles zu Simple Styles ändert und den aufgeräumten Code wieder an Peggy weiter gibt.

Nun folgt die Umsetzung des Screendesigns über den Prototypen. Indem Peggy die Eigenschaften der einzelnen Controls, die Typografie und die Farben der Hintergründe verändert.

Lars übernimmt jetzt das Ruder und erklärt wie man nun vom gestyltem Sketch Flow Prototypen zur Grundlage des “echten” Produkts kommen kann.  Der Sketch Flow Rahmen wird solange wie möglich gehalten, um eventuelle Anforderungen die später kommen wieder mit einem Prototypen evaluiert werden kann. Aus dem Sampeldate werden entsprechende ViewModels angelegt, der NavigationManager wird verworfen. Dann kommt noch ein Fenster drum und schon kann es los gehen. In der Solution besteht dann die Möglichkeit die Anwendung als solche oder mit dem Rahmen von Sketch Flow zu starten.

Es kommt noch eine Frage zum Import von Illustrator hinzu XAML, was wohl automatisch geht, wovon aber abgeraten wird (ein Teilnehmer berichtet von Erfolg im eigenem Projekt mit der Importfunktion).

Warum Design mehr ist als reine Dekoration

Los gehts mit Resolution indipendence und einer kurzen Erklärung zum Mythos: Pixelanzahl vs. Auflösung. Kurze Übersicht zu Bezeichnungen wie VGA, Full HD etc. und Displaygrößen mit Diagonale, Höhe und Breite.  Jetzt kommt ein Diskurs wie Pixelanzahl und Displaygröße Zusammenhängen – es gibt z.B. Smartphones die fast Desktoppixelzahlen besitzen aber eine Diagonale von nur 3,5 Zoll.