Interaction with video content gives viewers an opportunity to participate in the storytelling process and influence further development of the content. This innovative approach to video content has been rapidly growing in popularity across various industries.



In this topic, we will share our experience in creating a platform for designing interactive video content, including the use-case diagrams and our technology stack.

Use-case diagrams are critical in formalizing functional requirements, with a draft being built during the study of the terms of reference. The diagram should include actors and use cases (i.e. services that our system provides to actors), as well as a specification that describes specific sequences of actions (the flow of events) that clients perform when working with the system.

Our user use cases include basic functions such as registration, authorization, and logout, as well as custom functions like creating a project and watching an interactive video. When creating a project, clients can describe the project and upload a preview for the video. Clients can then enter the project editing panel, where they can add scenes and see the preliminary results. Scenes can be edited or deleted by the user, and when editing a scene, clients can enter the scene name, description, upload the video, and add a button if this scene is one of the video branching options. The graph makes it easy to understand the script of the video. For example, if a user clicks on the "Vacuum Cleaner" button, they will see a cat on a vacuum cleaner at the end of the video. Otherwise, if the client presses the "sofa" button, they will see a cat on the couch.

Our technology stack included React for the front-end and Docker, mssql, C#, postman, and swagger for the back-end. TypeScript was used for the client part of the service, and React was chosen as the framework to increase the speed. To automate routine development processes and simplify code writing, ESLint was installed and configured, while Prettier was configured for code style uniformity. The KISS principle (Keep it simple, stupid) was also applied, making the client part of the application simple to understand, maintain, and refine.

The Scene class includes the Projects class and sets of operations like deleting, updating, assigning parent and child scenes, updating video scenes, and moving the scene in the graph. The Scene coordinates in the graph are represented by x and y.

BACKEND part

Back-end: Docker, mssql, C#.

To implement the back-end, we used C# on the asp.net core 3.1 platform, which is an LTS version. LTS versions provide long-term support and receive security updates and bug fixes for a longer period than usual. These versions are considered stable as they undergo thorough testing before release. However, LTS versions do not include the latest features and capabilities or support for the newest hardware and software.

We established contracts between the back-end and front-end parts using Swagger, a framework for the RESTful API specification that allows for viewing and sending requests interactively. We implemented standard handles for authorization and registration and hosted the database in the cloud using MSSQL database.

Postman was used for testing requests and new records were added to the database successfully. However, requests were rejected from the front-end until the CORS policy was configured, which allows access to resources from a server on a different domain.

To address the big data problem of storing large video files, we created a client directory on the disk that contains project directories with the video files and relative paths recorded in the database. The solution for downloading large video files was through the HTTPS protocol.

The topic of architecture lacks sufficient data, including a basic blueprint. One immediate issue is the need to refactor the User class as it combines both user and personal data, which poses problems for many regions, particularly GDPR and CPPA. It's important to note that not all users are people, as there could be integrations with other services in the future.

The tutorial video poses issues on how to effectively use it, considering many students play it in the background while multitasking. One solution is to make the video interactive by adding tests or other forms of interactivity. Choosing the right service is crucial for this.

Some recommended services include Vialogues, which offers Courseare-style interactive video and surveys; Edpuzzle, a simple flexible service with two forms of test tasks and flexible settings; Nearpod, which is part of a lesson constructor and offers a simple interface; Learnis, a straightforward service with two test task forms and no registration required; LearningApps, a popular choice allowing tasks with an accuracy of up to a second (albeit not always convenient); Playposit, the most functional service with a good balance of simplicity and functionality; and H5P which is the most versatile service for creating interactive videos and better used in a convenient or Moodle platform.