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.
(https://static.frieze.com/files/styles/hero_image/public/article/main/main-images-20a.-t.-rex-wall-projection-rm.png)
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.
The use-case diagrams play a pivotal role in formalizing the functional requirements of the system, thus providing a bird's-eye view of the interactions between different actors and the use cases they engage in. By structuring the system's functionality through use cases, the platform's design aims to prioritize user experience and create an intuitive interface for both content creators and viewers.
The delineation of user use cases, encompassing essential functionalities such as registration, authorization, and project creation, as well as custom features like interactive video viewing, underlines the versatility and user-centricity of the platform. This approach allows users to seamlessly navigate through the various stages of creating, customizing, and experiencing interactive video content.
The technology stack employed for this platform displays a meticulous consideration of various factors, including front-end responsiveness and scalability. React, as the chosen front-end framework, implies a focus on creating dynamic, responsive, and visually engaging user interfaces. The incorporation of TypeScript further reinforces the dedication to producing robust and maintainable code, enhancing the overall quality of the platform's client-side components.
The decision to utilize Docker for containerization, mssql for the database, and C# for the back-end underscores a commitment to building a reliable, scalable, and performant infrastructure. These choices signal a strategic alignment with industry best practices, ensuring a solid foundation for the platform's operations and potential growth.
The inclusion of ESLint and Prettier in the development process highlights a steadfast commitment to code quality and style consistency. By enforcing a unified coding style and identifying potential issues early in the development cycle, these tools significantly contribute to the overall maintainability and collaboration potential of the codebase.
Embracing the KISS principle in designing the client-side application reflects an understanding of the importance of simplicity, clarity, and maintainability in software development. Prioritizing these aspects can lead to a more accessible learning curve for new team members, as well as make the platform more adaptable to future enhancements and modifications.
Opting for an LTS version of asp.net core for the back-end demonstrates a thoughtful consideration of stability, long-term support, and security. By leveraging a version known for its reliability and thorough testing, the platform aims to instill confidence in users and stakeholders regarding the security and consistency of the system.