Arbeitspaket 1 – “Professor S.”-Plattform Phase 1

Industrielle Forschung – Personenkapazität: 13,90 PM

Ziel des Arbeitspakets im Gesamtprojektkontext

Ziel dieses Arbeitspakets ist es, das Frontend des bestehenden Prototypen der Lernspielplattform „Professor S.“ zu portieren und das HTML5-Video sowie die Audioverarbeitungsfunktionen zu erweitern. Das bestehende Backend soll dabei auf das Ruby-on-Rails-Framework portiert werden. Die Spielmechaniken für Schüler und Lehrer sollen ebenfalls in diesem Schritt erarbeitet werden. Außerdem soll ein Echtzeitnachrichtensystem entwickelt werden, das Kommunikation unter den Benutzern der Plattform erlaubt. Dieses Nachrichtensystem soll auch die Kommunikation der verschiedenen Plattformmodule ermöglichen wie z.B. Chatbot (AP2.2), Lehrerberichte (AP1.6) und Quizspiel (AP3.2). Eingeschlossen in diesem Arbeitspaket sind die Gestaltung und Programmierung dieses Systems. Desweiteren soll ein Hypermedia-API zur Sammlung von Daten über Aktivitäten und Fortschritte der Schüler entwickelt werden. Diese Daten sollen dann grafisch auf einer Website für die Lehrer dargestellt werden. Diese Applikation soll ebenfalls in diesem Schritt entwickelt werden.

Ergebnis als Abschluss des Arbeitspakets

Folgende Elemente und Funktionen sollen entwickelt werden:

Überarbeitung des UX-Designs des “Professor S.”-Prototypen
funktionstüchtiges HTML5-Frontend des “Professor S.”-Prototypen
funktionstüchtiges Ruby-on-Rails-Backend des “Professor S.”-Prototypen
erster Entwurf der Schülerspielmechaniken
erster Entwurf der Lehrerspielmechaniken
funktionstüchtiges Echtzeitnachrichtensystem
funktionstüchtiges Hypermedia-API für Lehrerberichte
funktionstüchtige grafische Visualisierung der Lehrerberichtsdaten

Technologisches Risiko des Arbeitspakets

Bei dem Hypermedia-API soll die Client-Integration durch den Einsatz einer semantischen Struktur erleichtert werden. Die Erfolgskontrolle ist die erfolgreiche Anwendung der automatischen Erkennung der URI-Endpunkte und Datenstrukturen durch das Client-System. Die semantische Kommunikation der Angebotscharaktere von URI-Endpunkten und Datenstrukturen befindet sich noch im Anfangsstadium der Entwicklung. Das Risiko, das sich durch den Zeitaufwand der Entwicklung dieser Struktur ergibt, soll durch die parallele Erstellung einer traditionellen API-Dokumentation gemildert werden.

Obgleich die W3C „Media Source Extension“ den Einsatz von HTML-Media-Source-Elementen vorsieht, um Java-Script-generierte Mediastreams zu unterstützen, befinden sich Funktionen wie Client-Side-Audio und Videoverarbeitung noch in der experimentellen Phase und werden bislang noch von wenigen Browsern unterstützt. Ob bis zur breiten Veröffentlichung der Plattform die entsprechenden Standards weit genug verbreitet sind, ist momentan noch unklar. Um dieses Risiko abzumildern, ist die Implementierung einer Flash-basierten Ausweichlösung geplant.

Das technologische Risiko bei der Entwicklung von Spielmechaniken liegt zum großen Teil in den Auswirkungen, die bereits kleine Veränderungen im Gamedesign auf technologische Elemente haben können. Da es beim Gamedesign um menschliches Verhalten geht und die Art und Weise, wie Menschen mit den entwickelten Spielregeln umgehen, können kleine Veränderungen überraschende Auswirkungen auf das gesamte Spielsystem haben. Besonders Technologie ist in dem Fall fehleranfällig. Diesem Risiko soll begegnet werden, indem wir die Spielregeln aufbauend auf den gesammelten Erfahrungen der letzten vier Jahre entwickeln und die Spielmechaniken zu Beginn des Projektes definieren und soweit möglich auch unter realen Bedingungen testen. Größere Veränderungen zum Projektende hin sollen vermieden werden.

Die Forschungsarbeit an Server-Client-Anwendungen für den Echtzeitdatenaustausch mit einem “event-driven, non-blocking” I/O-Modell steckt derzeit noch in den Kinderschuhen. Daher birgt die Entwicklung eines solchen Systems das Risiko fehlender Funktionen am Ende der Entwicklungsphase. Dieses Risiko soll durch die parallele Implementation von einem Flash-basierten Nachrichtensystem abgemildert werden.

Beschreibung des Arbeitspakets

Es sollen flexible Hypermedia-APIs entwickelt werden, die eine Einbindung von Client-Systemen erleichtern. Ein Hypermedia-API erfüllt seinen Zweck erst dann, wenn die Funktion der URI-Endpunkte und der Datenstruktur erfolgreich an den Client-Rechner kommuniziert werden kann. Die Herausforderung an den Programmierer liegt daher in der Definition und Kommunikation der Angebotscharaktere der URI-Endpunkte und der Datenstruktur. Wenn eine effektive semantische Struktur aufgebaut ist, können die unterliegenden Ressourcen verschoben werden, ohne dass die Funktionalität des Client-Rechners dabei beeinträchtigt wird.
Die Hauptfunktionen des bestehenden Prototypen der “Professor S.”-Plattform sollen auf ein HTML5-Frontend portiert werden. Es soll eine in-Browser Video/Audio-Aufnahmefunktion geschaffen werden, die es Benutzern erlaubt, Video und Audio direkt im Browser aufzunehmen. Das Backend der Plattform soll dabei von dem bestehenden Silverstripe-Framework (PHP) auf das Ruby-on-Rails-Framework portiert werden. Dies soll unter Anwendung der Prinzipien von Test-Driven- und Behaviour-Driven-Development (TDD/BDD) geschehen. Es sollen Spielmechaniken entwickelt werden, die das Erlebnis des “Professor S.”-Spiels für alle Benutzer (Schüler, Lehrer und Eltern) abwechslungsreich, interessant und reizvoll gestalten. Alle Elemente des Spiels sollen so gestaltet werden, dass sie sich gegenseitig ergänzen. An bestimmten Punkten innerhalb des Spiels sollen immer wieder Anreize entstehen, neue Aufgaben zu lösen und Inhalte beizutragen. Es soll aber auch Freiraum zum Experimentieren und Entspannen entstehen. So ist z.B. vorgesehen, dass längere Arbeitsperioden immer mit kleinen Entspannungsspielen oder Ruheperioden belohnt werden. Fortschritte innerhalb des Spieles sollen mit Abzeichen, steigenden Levels und Sternchen belohnt werden. Es soll auch eine Tabellenliga entstehen, die im Klassenraum zur Motivation eingesetzt werden kann. Innerhalb dieser Liga soll jedoch jedes Kind für
bestimmte Tätigkeiten regelmässig ausgezeichnet werden, sodass nicht immer die selben Kinder an der Spitze der Tabelle rangieren.

Arbeitspaket 1.1 – Vorbereitung und Portierung der Plattform

In diesem Schritt sollen die bestehenden Funktionen der Prototyp-Plattform auf ein HTML5-Frontend portiert werden. Das bestehende PHP-Backend soll dabei auf das Ruby-on-Rails-Framework übertragen werden. Zweck dieser Portierung ist die Einführung von TDD- und BDD-Prozessen, die langfristige Stabilität der Plattform und die Qualität von Updates gewährleisten soll. Ruby on Rails hat auch eine wesentlich größere Entwicklergemeinde als SilverStripe. Die RoR-Portierung soll daher auch die Rekrutierung von Entwicklungspersonal vereinfachen.

Arbeitspaket 1.2 – Schülerspielmechanik

Es sollen Spielmechaniken entwickelt werden, die das Erlebnis des “Professor S.”-Spiels für alle Schüler
abwechslungsreich, interessant und reizvoll gestalten. Dabei sollen bestehende Funktionen weiterentwickelt und neue Funktionen erdacht werden. Alle Elemente des Spiels sollen so gestaltet werden, dass sie sich gegenseitig ergänzen. An bestimmten Punkten innerhalb des Spiels sollen immer wieder Anreize entstehen, Aufgaben zu lösen und neue Inhalte beizutragen. Es soll aber auch Freiraum zum Experimentieren und Entspannen entstehen. So ist z.B. vorgesehen, dass längere Arbeitsperioden immer mit kleinen Entspannungsspielen oder Ruheperioden belohnt werden. Folgende Bereiche sollen auf ihre Eignung hin für die “Professor S.”-Spielelemente in Erwägung gezogen werden:

Herausforderungen: vordefinierte Missionen, bestimmte Ziele zu erreichen mit entsprechenden Belohnungen, wenn diese Ziele erreicht sind.

Punkte: Benutzeraktivitäten werden durch die Vergabe dieser digitalen Währung belohnt – Punkte können eventuell auch gegen virtuelle oder reale Güter eingetauscht werden.

Avatarsystem: Avatare erlauben es dem Benutzer, Individualität auszudrücken und erhöhen damit die Bindung an das Spiel (Avatare können mit Punkten erworben warden).

Trophäenregal: zeigt den Benutzern eine Liste der verfügbaren Belohnungen sowie den eigenen Fortschritt auf dem Weg dorthin

Levels: erlauben den Benutzern, sich vordefinierte Erfahrungen zu verdienen und definieren ihren Rang in einer Gemeinschaft

Rangliste: erlaubt es dem Spiel, die Erfolge von einzelnen Benutzern nach vordefinierten Kriterien zu verfolgen und ggf. zu publizieren

Gruppen: erlauben es Benutzern, Aufgaben kollektiv zu lösen (bereits Teil des Schülerspieles im Prototypen)

Wettbewerbe: erlauben es Benutzern oder Gruppen, gegeneinander anzutreten und sich gegenseitig herauszufordern

Benutzergenerierte Miniquiz-Spiele: benutzergenerierte Fragen, die per Zufallsgenerator oder Slideshow präsentiert werden

Freunde: erlauben es Benutzern, starke Kontakte mit anderen Benutzern aufzubauen und bieten ein Publikum für selbst-generierte Inhalte und Kommentare

Stern-Bewertungssystem: erlaubt es Benutzern, die Inhalte anderer Benutzer zu bewerten

Kommentare: Eine Kommentarfunktion auf einer Benutzerprofilseite liefert Anreize, die Plattform häufiger zu besuchen, um zu sehen, wie sich der Dialog entwickelt.

Nachrichtenfeed: erlaubt einen ständigen Strom von Neuigkeiten über die Aktivitäten von anderen Benutzern

Benachrichtigungen: erlauben Rückmeldungen und Nachrichten an die Benutzer um diese über neue Herausforderungen, Punktestand oder neue Funktionen der Plattform zu informieren

Die Entwicklung der Spielmechaniken soll über die gesamte Entwicklungsphase unter Berücksichtigung von Benutzererfahrungen verfeinert werden.

Arbeitspaket 1.3 – Echtzeitnachrichtensystem (Meilenstein)

In diesem Schritt soll ein Echtzeitkommunikationsmodell entwickelt werden, das auf einem “event-driven, non-blocking” I/O-Modell aufbaut. Dadurch soll ein effektiver Datenaustausch unter Benutzern und Sitemodulen gewährleistet werden. Es soll ein Echtzeitnachrichtensystem entwickelt werden, das es Benutzern ermöglicht, mit Nachrichten untereinander zu kommunizieren und Dateien miteinander auszutauschen. Die Nachrichten sollen in einem Verlauf gespeichert und ähnlich einem Facebook-Nachrichtenfeed visualisiert werden. Benutzern soll es auch ermöglicht werden, Audio- und Videonachrichten und Dateien wie PDFs und Textverarbeitungsdokumente untereinander auszutauschen. Audio- und Videonachrichten sollen, in einem HTML5-Player eingebettet, ebenfalls im Nachrichtenfeed in Echtzeit visualisiert werden. Außerdem soll ein System entwickelt werden, das automatische Antworten und vorprogrammierte Nachrichteninhalte auslöst.

Arbeitspaket 1.4 – Lehrerspielmechanik

In diesem Schritt sollen Spielmechaniken für Lehrer entwickelt werden, um diese zu eigenen Beiträgen auf der Plattform zu motivieren. Im Besonderen geht es hier um die Bereitstellung und Veröffentlichung von Lehrmaterial (so wie Aufgaben und Anleitungen), aber auch um direktes Feedback für Schüler in Bezug auf schülergenerierte Inhalte. Geplant ist u.a. ein Level- und Badge-System, ähnlich der Forumspielmechanik bei Stackoverflow. Wie auch bei den Schülerspielmechaniken sollen Avatare, Trophäenregale, Herausforderungen und Wettbewerbe bei der Konzeption in Erwägung gezogen werden. Die Entwicklung der Spielmechaniken soll über die gesamte Entwicklungsphase unter Berücksichtung von Benutzererfahrungen verfeinert werden.

Beispiel des Supportinterface für Lehrer:

Arbeitspaket 1.5 – Lehrerberichte Hypermedia-API

In diesem Schritt soll ein Hypermedia-API entwickelt werden, das erlaubt, Daten über Benutzerfortschritte in Drittanwendungen und Quizspielen an die Lehrerberichte (AP1.6) zu übermitteln.

Arbeitspaket 1.6 – Lehrerberichte

Es soll ein Datenvisualisierungssystem entwickelt werden, das es Lehrern ermöglicht, die Aktivitäten der Schüler in Echtzeit zu verfolgen und sowohl quantitativ als auch qualitativ auszuwerten. Dazu sollen Echtzeitdatenaustauschfunktionen entwickelt werden, die Aktivitäten wie z.B. Fortschritte innerhalb von Quizzes und Minispielen messen und direkt im Lehrerberichtwerkzeug sichtbar machen. Die so gemessenen Daten sollen mit Hilfe von Algorithmen zusammengefasst und vereinfacht visualisiert werden. Dabei sollen u. a. auch Bewertungssysteme in Erwägung gezogen werden, die auf Kernkompetenzen wie Handlungs- und Medienkompetenz basieren.