Ziel dieses Arbeitspakets ist es, die “Professor S.”-Plattform um HTML5 Video- und Audioverarbeitungsfunktionen zu erweitern und die vorhandenen und benutzergenerierten Audio- und Videoinhalte in ein Content Delivery Network (CDN) einzubinden. Dabei soll auch eine Funktion entstehen, die es Filmproduzenten und Vertrieben erlaubt, Inhalte, die für den Onlinevertrieb bestimmt sind, auf die Plattform zu laden. Diese Inhalte sollen für Benutzer später über ein Empfehlungssystem entdeckbar gemacht werden. In Zusammenarbeit mit der Universität Bamberg soll ein dort entwickeltes Geolocation Spiel in die “Professor S.”-Plattform eingebunden werden. Basierend auf dem Echtzeitnachrichtensystem (AP1.3) soll auch ein Chatbot programmiert werden, der automatisierte Antworten und Nachrichten an die Benutzer versendet. Desweiteren soll ein API für Minispiele programmiert werden, das die Einbindung von Drittanwendungen in die “Professor S.”-Plattform erleichtern soll.
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.
Bei den Hypermedia-APIs 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.
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.
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 des Test-Driven- und Behaviour-Driven-Development (TDD/BDD) geschehen. Desweiteren soll ein HTML5-Uploader und Transcoder für Filminhalte entwickelt werden.
Der Browser soll direkt auf Audio- und Videogeräte zugreifen können, ohne über den Umweg anderer Anwendungen zu gehen. Die entstehenden Audio- und Videoaufnahmen sollen im Client-Rechner verarbeitet werden und anschließend auf einem Media-Server gespeichert werden. Audio- und Videoinhalte sollen auch direkt im Browser abgespielt werden, ohne auf Plugin-Anwendungen wie Flash Player oder Silverlight zugreifen zu müssen.
Es soll eine automatisierte Nachrichtenfunktion entwickelt werden, die in einem gewissen Zeitabstand Nachrichteninhalte auslöst, die an die Schüler versandt werden. Dazu sollen als Antwort auf eine Schülernachricht an Professor S. automatische Antworten ausgelöst werden. Für Lehrer soll eine Funktion entwickelt werden, die es erlaubt, Nachrichten zu einem vorbestimmten Zeitpunkt oder auch per Fernsteuerung über das Zeitportal (siehe auch AP5) auszulösen. Es soll auch eine Funktion entwickelt werden, die es erlaubt, Audio-und Videoinhalte in einem Player eingebettet in die Nachrichten zu integrieren.
Es soll ein ortsgebundenes Spiel entstehen, das über die GPS-Funktion von Tablet- und Smartphone-Clients gesteuert wird. Das Spiel soll ähnlich wie eine Schnitzeljagd funktionieren und ist als Aktivität für Klassen- und Familienausflüge gedacht. Dafür soll ein HTML5-Frontend entwickelt werden, das über ein API (siehe Arbeitspaket 1 – Hypermedia-API) mit einem von der Universität Bamberg entwickelten Backend kommuniziert. Es ist geplant, die unmittelbare Umgebung der Spieler auf einer Karte darzustellen. Die Position der Spieler wird als GPS-Punkt (ähnlich wie bei Apple Maps) angezeigt. Die nächste Station der Schnitzeljagd wird ebenfalls auf der Karte dargestellt. Wenn ein Spieler die nächste Station erreicht hat, sollen Medieninhalte wie Texte (Nachrichten), Videos und Quizfunktionen über das Nachrichtensystem (siehe Arbeitspaket 3) ausgelöst werden.
Hier soll ein automatisiertes System entstehen, das es ermöglicht, Medieninhalte (d.h. Unterhaltungs- und Dokumentarfilme, Aufgaben und Nachrichten) innerhalb des Spiels thematisch und inhaltlich miteinander zu verknüpfen und darauf aufbauend Empfehlungen verwandter Medieninhalte an die Benutzer weiterzugeben. In dieses System sollen auch benutzergenerierte Inhalte eingebunden werden – d.h. Aufgaben- und Medieninhalte, die von Lehrern erstellt wurden und mit anderen Benutzern geteilt werden.
Es soll eine Upload-Funktion entstehen, die es Filmproduzenten und Filmvertrieben erlaubt, Videoinhalte über einen HTML5-Uploader auf die LudInc-Server zu übertragen. Diese Videoinhalte sollen dann auf dem Server in ein geeignetes Format transkodiert und über ein CDN (siehe auch AP1) für Benutzer bereitgestellt werden.
In diesem Schritt sollen die in AP1 und AP2 entwickelten Funktionen während der Einführungsphase (August 2014-Dezember 2014) technisch begleitet werden. Dazu gehört technischer Support für Schulen und Endnutzer zu Hause. Probleme mit Design, Back- und Frontend-Programmierung sollen per Onlinechat oder in einem Support- und Ticketingsystem (siehe auch AP4.4) dokumentiert und nach Priorität bearbeitet werden.