HTML/H5P Player v2.0 Design

Introduction:

This document describes the design approach for HTML/H5P player

https://project-sunbird.atlassian.net/browse/SB-28712

Background:

Now to play HTML or H5P content we use content player version 1 which is the combination of all the players as a single player.

• Playing of the content is with the initial load is slow due to the heaviness of the player since it has all the players embedded as one

• Extending it for further enhancements are harder to implement since it is tightly coupled with other players as once player

• The current player is not adaptable to all the screens and it is having limitations on rendering in all the screen resolutions

Problem Statement:

• Html player should be independently launched and player specific to html only

• The player should have better performance

Key design problems:

1. Player - Define player and its dependencies and interactions with other components and the parent container

2. Player config - simplifying the player input configuration to start the content play

3. How to handle telemetry events

4. The player should support to the all screen resolutions

5. Performance of player should be better compared to older player

6. How to handle content consumption progress bar

7. How to handle page change events

8. How to show end page for html content

9. How to handle pagination for html and h5p content

10. How to handle next and previous interact events

Solution :

• As we are building independent player performance will be better because its not tightly coupled with any player and it will be light weight

• We can pass minimal player config to player or mandatory config to the player

  playerConfig = { "context": {}, "config": {}, "metadata": { "identifier": "", // Mandatory, content id "name": "", // Mandatory, name of the content "pkgVersion": "", // Mandatory, package version "streamingUrl": "", // Mandatory, defines the streaming url "artifactUrl": "", // Mandatory, Defines the artifact url "isAvailableLocally": "", // Mandatory, defines the content availability status "basePath": "", // Mandatory, defines the base path "baseDir": "", // Mandatory, defines the base directory }, }

• The screen resolution issue will be resolved by adding css to the iframe

• we can handle telemetry events by using html interface file provided by html content

• We can handle content consumption progress by using interface file provided by html content , below is the code snippet

• org.ekstep.renderer.html.ProgressBar = function(flag){ org.ekstep.contentrenderer.progressbar(flag); }

• We can handle end page by using methods provided by interface file , bellow is code snippet

  org.ekstep.renderer.html.showEndPage = function() { org.ekstep.renderer.html.EkstepRendererAPI.showEndPage(); };

Design :

Open

Player config:

Telemetry property description:

Config property description:

Player events:

a) Start

This event is the beginning of the player event and will be triggered when the player starts.

b) End

This is one of the player event , which will be triggered when the player reaches the end of the content.

c) HEARTBEAT

The player also has some other events like share, full screen, minimize screen, open menu, close menu, reply. and bellow are the type of heartbeat events with sample data

1. Open menu
   This is one of the player event which is triggered when user clicks on menu icon

2. Close menu
   This is one of the player event which is triggered when user clicks on menu close icon

3. Share
   This is one of the player event which is triggered when user clicks on share icon

4. Minimize screen
   This is one of the player event which is triggered when user clicks on minimize

5. Full screen
   This is one of the player event which is triggered when user clicks on fullscreen

6. Turn off sound
   This is one of the player event which is triggered when user clicks on turn off sound

7. Turn on sound
   This is one of the player event which is triggered when user clicks on turn on sound

8. Replay
   This is one of the player event which is triggered when user clicks on replay

Telemetry events:

a) Start Event

This is the start event that will be triggered when the player starts playing and the following is the sample telemetry data.

b) Interact Event

This is the Interact event which will be triggered when the user does any interaction in the player like menu open or share and etc and following is the sample telemetry data.

c) Impression Event

This is the impression event that will be triggered when we open the player and the following is the sample telemetry data.

d) End event

This is the end event and the following is the sample telemetry data.

Sample complete telemetry data

Pros:

• Separation of Concern: With Separation of Concern we will have highly modular and maintainable code . Tight Coupling of Systems ends up constraining the player to put most part of the code which is non-functional for itself.

• Any Potential changes to telemetry shouldn’t ideally end up republishing the player. An update on CSL should be enough. Which kind of reduces the risk of regression to Telemetry Only.

• Modular Player: Since the entire player is an npm repo. It becomes easy to detach the existing player and move into the new one without any hassles

• It is quite practical to interpret telemetry spec in a very customized way for most of the adaptors of Sunbird. This telemetry behaviour should be allowed to override with minimal effort.

• Any new players created in future, will be less context aware and more functional in nature.

Cons:

• Any player created in the future will have a dependency on CSL for default telemetry implementation. Could potentially be a source of friction.

• Creating a Telemetry Interpreter can be a two-step task.

References:

Sunbird content player https://github.com/project-sunbird/sunbird-content-player/tree/release-4.6.0

Sunbird player sdk https://github.com/project-sunbird/sunbird-player-sdk/tree/release-4.8.0

Sunbird telemetry sdk

Sunbird client services