New video player architecture (React-based Video Player)
- Mariia Moskalenko
- Edward Zarecor
- Sarina Canelake
- Glib Glugovskiy
Document owners: @Glib Glugovskiy @Mariia Moskalenko
The goal of the document
Clarify and specify requirements and use cases needed to be covered by the new video player. Define approaches to the use cases and make high-level decisions on the solution for them (it can be a high-level solution approach or ADR for some).
Context
Non-functional requirements and use cases were discovered through the document analysis of the Approach Memo & Technical Discovery: React-based Video Player, exploration of the latest Open edX release (Palm) UI and back-end with feature flags for the video player and new studio on the MFE, new studio design, community feedback, project stakeholders' feedback.
Glossary
Open edX | is a service-oriented platform for authoring and delivering online learning at any scale |
edX platform | LMS and CMS services of Open edX |
Video component | Current vanila JS video player xblock that is used in edx-platform |
New video player | ReactJS implementation of the video block based on video.js library |
New Video xblock | New xblock with ReactJS frontend and Python backend (that is refactored version of Video Block), it should be backward compatible with Video Component |
New video editor | the new design with the new user experience of the live video preview |
Quality attributes and non-functional requirements
The structure can be changed during the discovery.
Priorities:
high - requirements are needed for the beta-testing (for 10 courses on edx.org)
medium - requirements are needed for the launch, but not crucial for beta-testing
low / out of scope - requirements can be added later as a plug-in or developed by community members - for now, considered out-of-scope items
Initial requirement from the Approach Memo & Technical Discovery: React-based Video Player | Quality attribute/Rules | Non-functional requirement | Priority | Implementation approach |
|---|---|---|---|---|
The player is FOSS and compatible with the Open edX platform’s software license | Compatibility | Video.js video player has to be used as a new player in Open edX as the best option due to the discovery among several options. Video.js Library was selected as the implementation for video player, it alligned with Open edX platform’s software license. | high | |
The video player is layer upon layer upon layer of crufty compatibility code. We could probably make something a lot simpler overall if we created a new XBlock entirely and migrated video data over to it, though that would make gradual rollout/rollback more difficult | Compatibility | The new video player has to be integrated into Open edX infrastructure to make possible all necessary changes and improvements. | High | |
New videos can just persist that new, sane data model, while old ones get converted as needed. | Compatibility | New video player has to coexist with the Video component. Some videos can be processed through the Video component and some of them will be processed through the new video player. | High | |
Gradual rollout/rollback | Administrability | The new video player experience has to be implemented in a way that during the upgrade to the new version of the Open edX Platform admin will be able to test the new video player experience with existing videos within the particular organizations and on the particular courses and switch back to the video component in case of unexpected difficulties. | High | |
The video player is layer upon layer upon layer of crufty compatibility code. | Compatibility | The video component has to be refactored and some features have to be deprecated to make further development easy. | High | ADR#1 or #2? |
Features of the old video player have to be revised and deprecated as needed Some pieces of data can just be dropped entirely, like multi-version-YT nonsense used ages ago to provide different video speeds (before YT provided this functionality natively). Multi-speed YouTube upload option We used in 2012 before YT started generating multiple speeds for you. Open questions: Is anyone using video bumpers? What features weren’t ported to the MFE, or are no longer exposed in the UI? etc | Maintainability | Features of the old video player have to be revised and deprecated as needed. | high | ADR#1 or #2? |
Make it so that the new video player has a simple, sane data model to follow, and write a terrible shim layer to convert (up front and in one place) the layers of old terrible into the format the new system expects. | User experience | The goal is to introduce the new feature without additional effort from the end-users side.
|