LMS for the casino industry

Solution

Discovery phase

Itransition proposed starting the project with a discovery phase to achieve the following goals:

• Discussing the platform's business requirements and specifying the technology stack for the platform
• Creating functional and technical specifications
• Conducting a joint review of the list of features, involving Itransition’s business analyst and the customer’s product owner
• Defining an implementation plan

Drawing on discovery phase outcomes, together with the customer, we defined the following characteristics of the future LMS:

• A cloud-based responsive SaaS product with the capability to support up to 600,000 registered users according to the customer’s growth plans
• Creating and customizing courses and surveys (tests) for each client based on their needs SCORM-compliance
• Centralized update management with updates/upgrades synchronization across selected tenants
• Built-in reporting capabilities with the possibility to track course data such as online course completion and test pass/fail

The flexibility of the system to provide more customization options for end clients should be achieved due to:

• Multi-tenant architecture with the ability to create a tenant for each client (casino) with support of at least 500 tenants
• Support of white labeling, including dedicated instance URL for every tenant (subdomains), settings to customize the banner, header/footer, and the login page for every tenant

Additionally, the system was expected to support a number of automated processes, e.g., bulk uploading of users to assign courses, versioning of lessons, and report notifications for certain users, which would help reduce the time spent on them.

The customer was considering Moodle as a platform on which the new solution should be built, given that their legacy system was based on it. Their previous vendor failed to develop it as per customer needs because the platform required a lot of custom coding. However, the customer’s internal processes worked differently than those set in Moodle. After thoroughly discussing the project needs with our technical experts, it was decided to design the solution in Java to better meet the project’s requirements.

We suggested dividing the solution into two logical modules: the portal used by the customer’s admins and the learning portal for end clients. For the client-facing part of the platform, we suggested using the single-page application (SPA) approach. In an SPA, either all necessary code – HTML, JavaScript, and CSS – is retrieved with a single page load, or partial changes are performed by loading new code on demand from the web server, usually triggered by user actions. The page neither automatically reloads during user interaction with the application nor controls transfer to another page, resulting in faster transitions that make the website feel more like a native app.

LMS development

LMS structure

Our team has developed a new LMS from scratch and keeps adding new functionality and improving and increasing the solution’s performance. The end users of the solution are casino employees (learners) and administrators who curate the learning process. The solution consists of two modules:

• Central panel
  An administrative panel that the customer support staff uses to manage the entire system. It allows for managing users and tenants and enabling specific functionality for them – lessons and courses creation, enrollments (subscriptions to courses) management, report generation, etc. The admins on the customer’s side are able to control and execute any features of any tenants from the central panel without logging into the tenant’s account.

• Tenant portal
  A part of the system that is used directly by casinos and their employees, who are provided with a unique access URL. The tenant panel is divided into two parts: 1) administrative panel, where end client admins can create users (casino employees) individually or through bulk upload of XLS files/sending JSON files via public API calls, manage users, create/manage and assign lessons and courses, create surveys, and generate reports; 2) learner panel, where users take courses assigned by the admin. It includes a user dashboard allowing a learner to view the courses they are enrolled for; a course page to search for courses and view the list of all existing courses in the tenant; a calendar and a messenger.

Courses

Courses can be general, required by US legislation, or tenant-specific. The customer offers general courses to casinos on a paid basis by uploading them to the tenant panel and assigning them to a specific tenant or multiple tenants at the same time. Some examples of general courses are employee safety training, responsible gaming awareness training, cybersecurity awareness, conflict management for improved performance, bullying in the workplace, and counterfeit currency prevention. Any tenant can also create their own lessons and courses and assign them to learners.

Courses consist of several lessons, which can include video lessons with the possibility of attaching links to external learning materials, PDFs, presentations, and SCORM packages. SCORM packages represent ZIP archives with data (HTML, CSS, JS code) defined by the SCORM standard and launched by the integrated Rustici engine. The Rustici engine provides the communication method and data models that allow the learning content and the LMS to work together. Due to this, end clients can create or customize courses (e.g. add new languages) on their own and offer them to other users. Tenant-specific courses can be customized during their creation by defining necessary conditions and applying course dependencies. For example, a course can not be completed without passing a certain lesson or can not be started without completing another course.

Each course can contain a survey – a questionnaire with answering options (true/false, multiple choice, single response) with scores that should be completed in order for a course to be considered passed. Tenants can define the order of lessons or the passing score for each lesson and configure sending a certificate upon course completion.

Reporting

Reporting involves tracking system activities and/or modifications made. There are basic reports available by default with the possibility to create customized reports by users having corresponding permissions. The reporting functionality is flexible and adaptable for each specific user and provides a subscription option. While creating a report, users can select specific parameters and apply filtering options to display only the fields needed with the possibility to save the configuration. For example, reports can feature the students who passed a test or failed it, track assignments to specific courses, provide overview information on which courses are created, show course statuses, and so on. Reports can provide information on upcoming deadlines for passing certain courses by learners, who could be sorted out by departments and job titles, or show user activity in the system. For reports customization, we leveraged Criteria API for Java – queries, which are based on fields and filters that a user picks, are formed dynamically at runtime, selecting only the data that is needed. Such an approach helped optimize data processing by using less system RAM.

Course matrix

According to the customer’s requirements, it was necessary to provide great flexibility of settings for all functionality with multiple variations of use to fit end client needs. As a result, the solution has complex logic on the backend, processing a huge number of settings. To facilitate this process and exclude the possibility of errors, we created course matrix functionality.

Tenants can have thousands of employees, and the process of manually assigning courses to each of them and tracking their learning activities can be very time-consuming, especially given that employees might occasionally change their job titles and/or transition to other departments. Course matrix functionality enables the automation and systematization of course assignments to students within each tenant. It enables choosing specific departments and job titles to assign courses to employees quickly and easily. 

By adding courses to the course matrix, admins have the possibility to choose specific departments and job titles, view enrollments, add enrollment start, end, and due dates, and so on. Admins can also select exception settings for an enrollment to restrict certain users inheriting it (e.g. not allowed if the course was taken in the last 90 days). After assigning a course or a lesson to a new user, the system automatically verifies whether this lesson had already been passed by the user or assigned to them.

After any change, the system initiates a recalculation of all data by necessary criteria to exclude the possibility of errors. For example, there could be 800 enrollments with 5000 assigned users recalculated. We implemented a separate microservice responsible for recalculating all dependencies between course assignments. The most complex thing is the logic of recalculation, which occurs on the code level and cannot be realized by means of third-party utilities. It allows for customizing almost any functionality – user profiles, templates and report filtering, creating various types of lessons and courses with different conditions for their passing, automating the assignment of courses, etc. As a result, the logic represents highly connected components that depend on each other – changing one course’s setting options can cause thousands of assigned courses to be recalculated.

Over time, after adding new tenants with thousands of users, the number of dependencies of one component from another (or from itself) has grown significantly, slowing down the processing time. Sometimes the processing of such a matrix could take up to 12 hours. We managed to optimize the initial data recalculation time through code optimization and algorithms modification. Instead of full-cycle processing and checking all system components for updates, we enabled the system to automatically allocate processing areas with data updates and skip the areas it already checked, marking them correspondingly and moving to finding and fixing bottlenecks. Thanks to that, the data processing time of 800+ enrollments was reduced by about 200 times.

QA

To minimize the risk of missing defects, Itransition’s QA team carried out the following QA activities:

• Test design – writing test documentation, fully covering the functionality with tests
• New feature testing – functional and GUI testing of a new feature set
• Defect validation, carried out for all the defects with the NFT label or at the request of the customer for defects with other labels
• Regression testing – the testing of existing features that could be affected after changes were made to the system
• Smoke testing – acceptance testing, carried out on the pre-production environment after performing all the above steps

Based on the task, the following testing sequences can be distinguished:

• New functionality (no dependencies with the existing functionality): Test design – NFT – DV – Smoke testing
• New functionality (having dependencies with the existing functionality): Test design – NFT – Regression testing – DV – Smoke testing
• Existing feature update: Test design (if needed) – Regression testing – DV – Smoke testing

Integration and unit tests were written in Java and Kotlin. For manual tests, we utilized the following tools:

Results

The LMS delivered by Itransition helped Casino Essentials increase its client base more than two times in six years. A 200x performance increase in matrix data processing boosted customer satisfaction, while making it possible to further grow the number of clients without compromising user experience. 

Ultimately, Vector Solutions, an eLearning and performance support company, added the platform to its portfolio as a leading training and compliance solution for the gaming industry. The customer receives roughly $3.5m in annual contract value through the delivered solution.