HTML/H5P Player v2.0 Design
Introduction:
This document describes the design approach for HTML/H5P player
SB-28712: Tech Design - HTML Player V2 - Part 2Released
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:
Player - Define player and its dependencies and interactions with other components and the parent container
Player config - simplifying the player input configuration to start the content play
How to handle telemetry events
The player should support to the all screen resolutions
Performance of player should be better compared to older player
How to handle content consumption progress bar
How to handle page change events
How to show end page for html content
How to handle pagination for html and h5p content
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 :
Player config:
Telemetry property description:
Property Name | Description | Default Value |
---|---|---|
| It is an |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
| It is an |
|
| It is an |
|
| It is an |
|
| It is an |
|
| It is |
|
| It is an |
|
| It is an |
|
Config property description:
Property Name | Description | Default Value |
---|---|---|
| It is an |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
| It is an |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
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
Open menu
This is one of the player event which is triggered when user clicks on menu iconClose menu
This is one of the player event which is triggered when user clicks on menu close iconShare
This is one of the player event which is triggered when user clicks on share iconMinimize screen
This is one of the player event which is triggered when user clicks on minimizeFull screen
This is one of the player event which is triggered when user clicks on fullscreenTurn off sound
This is one of the player event which is triggered when user clicks on turn off soundTurn on sound
This is one of the player event which is triggered when user clicks on turn on soundReplay
This is one of the player event which is triggered when user clicks on replay
Property Name | Description | Default Value |
---|---|---|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
| It is |
|
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 https://github.com/project-sunbird/sunbird-telemetry-sdk/tree/release-3.3.0
Sunbird client services https://github.com/Sunbird-Ed/sunbird-client-services/tree/release-4.6.0