Work Package 1 – “Professor S.” Platform Phase 1

Industrial Research – Staff capacity: 13,90 PM, external labour: 46.860 EUR

Aim of the Work Package in the Overall Context of the Project:

The aim of this work package is to port the frontend of the existing prototypes of the educational game platform “Professor S.” and to expand HTML5 video and audio processing functions. The existing backend is intended to be ported to the Ruby on Rails framework. The game mechanics for students and teachers will also be developed in this step. In addition, a real-time messaging system will be developed which allows communication among users of the platform. This messaging system is also a means of communication between the different platform modules like Chatbot (WP2.2), teacher reports (WP1.6) and Quiz Game (WP3.2). Included in this work package is the design and programming of this system. Furthermore, a hypermedia API to collect data on the activities and track the progress of the student will be developed. This data will then be collected on a website, accessible for the teachers. This application will also be developed in this step.

Result as Conclusion of the Work Package

The following elements and functions are to be developed:

revision of the UX design of “Professor S.” prototype
a functioning prototype HTML5 frontend of “Professor S.”
a functioning Ruby on Rails 4.x backend of “Professor S.” prototype
first draft of the student game mechanics
first draft of the teacher game mechanics
a functioning real-time messaging system
a functioning hypermedia API for teacher reports
a functional graphical visualization of teachers report data
Technological Risk of the Work Package

In the hypermedia API, client integration will be facilitated through the use of a semantic structure. The assessment is the successful application of automatic recognition of URI endpoints and data structures by the client system. The semantic of the communication range of characters from URI endpoints and data structures is still at an early stage of development. The risk that arises due to the time of development of this structure is to be mitigated by the parallel creation of a traditional API documentation. Although the W3C “Media Source Extension” means the use of HTML, MediaSource provides elements supporting Java Script-generated media streams to functions such as client-side audio and video processing, which are still in the experimental phase and are so far supported by only a few browsers. It is currently unclear, whether the corresponding standards will be widespread enough with the release of the platform. To mitigate this risk, the implementation of a Flash-based fallback is planned. The technological risk in the development of game mechanics is due in large part to the impact that small changes in the game design can have on technological elements. Since game design is about human behavior and the way in which people deal with the developed rules, small changes can have surprising effects on the entire game system. Technology is particularly prone to error in this regard. This risk will be countered by developing the game rules based on the experience gained over the last four years and also by defining the game mechanics at the beginning of the project, and testing them under real conditions as much as possible. Major changes towards the project end shall be avoided. The research on server-client applications for real-time data exchange with event-driven, non-blocking I/O model currently is still in its infancy. Therefore, the development of such a system involves the risk of missing features at the end of the development phase. This risk will be mitigated by the parallel implementation of a Flash-based messaging system.

Description of the Work Package

Flexible hypermedia APIs are designed to facilitate the integration of client systems. A hypermedia API serves its purpose only when the function of the URI endpoints and the data structure can be successfully communicated to the client computer. The challenge for the programmer therefore is in the definition and communication of the offer characters of the URI endpoints and the data structure. If an effective semantic structure is established, the underlying resources may be moved, without the functionality of the client computer being impaired. The main functions of the existing prototypes of the “Professor S.” platform will be ported to an HTML5 frontend. An in-browser video/audio recording feature is to be created, which allows users to record video and audio directly through the browser. The backend of the platform is intended to be ported from the existing SilverStripe Framework (PHP) onto the Ruby on Rails framework. This will be done using the principles of Test Driven and Behavior Driven Development (TDD/BDD). There are game mechanics to be developed to make the experience of the “Professor S.” game interesting and appealing for all users (students, teachers and parents). All elements of the game are to be designed so that they complement each other. At certain points within the game, incentives and rewards create new motivation to solve tasks and contribute content. However, there should also be space to experiment and relax. For example, longer periods of work are always rewarded with little play or relaxation rest periods. Progress within the game will be rewarded with badges, levels and asterisks. There is also a league table up, which can be used in the classroom to motivate. Within this league, however, each child should be regularly awarded for certain activities, so that it is not always the same children in the top ranks of the table.

Work Package 1.1 – Preparation and Porting the Platform

In this step, the existing functions of the prototype for “Professor S.” will be ported to a platform with HTML5 frontend. The existing backend PHP is intended to be transferred to the Ruby on Rails 4.0 framework. The purpose of this port is the introduction of TDD and BDD that will ensure for the long-term stability of the platform and the quality of updates. Ruby on Rails also has a much larger developer community as the current PHP framework SilverStripe. The RoR porting shall therefore simplify the recruiting of staff development.

Work Package 1.2 – Student Game Mechanics

In this step, we plan to develop the student game mechanics for the “Professor S.” game. Here, existing functions will be further developed and new functions will be created. All elements of the game are to be designed so that they complement each other. At certain points within the game, incentives and rewards create new motivation to solve tasks and contribute content. However, there will also be space to experiment and relax. For example, longer periods of work are always rewarded with little play or relaxation rest periods. The following areas should be checked for their suitability for the “Professor S.” game elements:

Challenges
The challenges are predefined missions with appropriate rewards that are issued when predefined goals are achieved. Teachers can start challenges at a set time with a predefined message (but customizable) including media content. Teachers can end these challenges with a predefined (but customizable) message including media content. Points User activities are rewarded by the award of this digital currency. Points can also be redeemed for any virtual or real goods. Points are given by the teachers as ratings on messages submitted by the students.

Avatar system
Avatar pictures allow the user to express individuality on their profile and thus increase the binding to the game. Avatars can be purchased with points. Trophy shelf It shows users a list of available rewards, as well as their progress on the way to archiving these trophies. Archived trophies are shown on the profile and relate to small achievements within the game. For example, if a user successfully completes a mini quiz or video quiz, they receive a trophy.

Levels
They allow users to earn titles which define their status in a community. Users start at level 1. They can earn points by having their messages rated and completing challenges such as mini games and quiz games. Once they have accumulated a certain number of points, they achieve level 2.

Ranking table
Every day, the accomplishments of the users within a class are evaluated according to a variety of criteria, some of which are applied manually by the teacher, others are assigned automatically. One such criterion is the total number of points acquired by a user, another is the time it took to complete a challenge like solving a mini game or quiz puzzle. An example of a manually chosen criterion is the best picture uploaded by a student or most innovative video essay produced.

Groups
They allow users to collectively solve tasks by sharing a session. The users have to log in together on the same web session to be in a group (already part of the prototype student game).

Competitions
They allow users or groups to compete against or challenge each other in competitions.

Teacher-generated mini quiz games
Teachers can generate their own quiz questions. These questions may be answered by presenting multiple choice options to the student or through the entry of verbatim text and numbers. Verbatim text has to be evaluated manually by the teacher and assigned a point value. Numbers are validated automatically, like in the case of mathematics tasks (1+2=?).

Friends
Users can build contacts and write messages to each other. This system will allow users to make friend requests, which must be accepted before a user can communicate with another user. Friends can send messages to each other. Once a user is friends with another student, the connection can be broken by unfriending the other student.

Star rating system
It allows teachers to evaluate the activity/work of students. Star ratings can be applied to messages.

Comments
A commenting function on the user profile allows for dialogue and thus creates motivation for frequent use of the platform.

Messaging feed
It allows a contant news feed about other user activity.

Notifications
These allow notifications and messages to inform users about new challenges, scores or new platform functions.

The development of the game mechanics will be continuously refined, based on user feedback, throughout the entire development phase.

Work Package 1.3 – Real-Time Messaging System (Milestone)

In this step, a real-time communication model will be employed that is based on an event-driven, non-blocking I/O model. This should ensure an effective exchange of data among users.

- A real-time messaging system will be used to allow users to communicate and exchange files with each other.
- The messages are stored in a history and displayed similar to the Facebook news stream.
- Audio and video messages are displayed in an HTML5 player in real time.

Work Package 1.4 – Teacher Game Mechanics

In this step, game mechanics will be developed to encourage teachers to make contributions on the platform. In particular, teachers will be encouraged to publish educational materials (such as tasks and instructions). This should include a level and badge system similar to the forum game mechanics at StackOverflow. A regular competition will be held, where the most inventive teacher generated task is rewarded with the filming of a bespoke episode of “Professor S.”

Example of the teacher support interface

Work Package 1.5 – Teacher Reports Hypermedia API

In this step, a hypermedia API will be developed that will allow the transmission of user data in realtime from third-party applications and quizzes to be displayed in the teacher reporting tool (WP1.6). Detailed API-Endpoints have to be determined while building the integration of the reporting tool with third-party applications.

Work Package 1.6 – Teacher Reporting Tool

In this step, a visualisation system will be developed that allows teachers to monitor the activities and progress of students in real time. The system will measure each student’s progress and points achieved within quizzes and mini-games and visualise the data for the teacher as a graphic representation. If required, the data will be visualised in a simplified form. A scoring system will be developed, which is based on competencies such as social competency and media literacy. The data collected includes messaging activity (How many messages has the student sent and in what frequency?).