Skip to content

LMS Engine

Aneesh Rao edited this page Dec 11, 2024 · 1 revision

Table of Contents

  1. Introduction
  2. User Roles and Permissions
  3. Courses Architecture
  4. Content Types and Structure
  5. Course Instances and Access Levels
  6. Video and Assessment Processing Pipelines
  7. Institute and Registration Flow
  8. Development Notes
  9. Fine-Grained Proctoring Features for Students

Introduction

CAL LMS is a MOOC-like architecture designed to facilitate learning across multiple institutes. It enables:

  • Institutes to create and manage courses.
  • Students, instructors, and staff to access content and functionalities based on their roles.

This documentation outlines the structure, hierarchy, and workflows within the LMS to aid developers in understanding its design.


User Roles and Permissions

1. Instructors

  • Create and manage courses and modules.
  • Add, update, and remove content (videos, articles, assessments).

2. Students

  • Enroll in courses and access course content.
  • Complete assessments.

3. Staff

  • Administrative support for courses and students.
  • Manage student enrollments and grading (if delegated).

4. Moderator

  • Manage courses and course related content for assigned institutions.
  • Allow CREATE, READ and UPDATE operations on courses associated with assigned institutions.

5. Admin

  • Manage courses and course related content for all institutions.
  • Allow CREATE, READ and UPDATE operations on any course.

6. Super Admin

  • Manage courses and course related content for all institutions.
  • Allow CREATE, READ, UPDATE and DELETE operations on any course.

Courses Architecture

1. Course Hierarchy

  • Institute(s): A course can be launched by one or more institutes.
  • Course: The top-level container for learning content.
    • Module: Represents a week or unit of content.
      • Section: Divides a module into smaller, logical parts.
        • Section Item: Individual learning components (e.g., articles, videos, assessments).

2. Section Item Types

  • Article: A Markdown file with customizations.
  • Video: An MP4 file or a YouTube link, with optional start and end times.
  • Assessment: A quiz or assignment to evaluate understanding.

3. Content Flow

  1. Articles or videos are followed by assessments.
  2. Assessments can also stand alone without being attached to a video/article.
  3. Videos cannot stand alone without an associated assessment.

Content Types and Structure

1. Articles

  • Format: Markdown files.
  • Usage: Rich textual content with optional customization.

2. Videos

  • Source: MP4 file links or YouTube links.
  • Options: Customizable start and end times for playback.

3. Assessments

  • Stand-alone or tied to videos/articles.
  • Automatically generated questions or manually created by instructors.

Course Instances and Access Levels

1. Course Instances

  • A course is offered to students through its instances.
  • Multiple instances of the same course can exist.

2. Access Levels

  • Public: Any student can register.
  • Unlisted: Registration is restricted to specific students chosen by the instructor.
  • Private: Only students from the associated institute can register.

Video and Assessment Processing Pipelines

1. General Video and Assessment Pipeline

Backend

  1. Video content is processed.
  2. Transcript is generated.
  3. Questions are auto-generated from the transcript.
  4. Questions are registered in the database.
  5. An assessment is created using all questions.

Frontend Request

  1. After a video/segment ends, a random subset of generated questions is presented as an assessment.
  2. On submission:
    • Submission data is stored for grading.
    • A grader evaluates the assessment and updates results.

2. Long Video Processing

  1. If a video has defined segments:
    • Process start timestamps in ascending order.
    • Create separate video objects for each segment.
    • Follow the general processing pipeline for each segment.

Institute and Registration Flow

1. Registration Process

  1. Institutes are registered in the system.
  2. Instructors are associated with their respective institutes.
  3. Instructors create courses, and course instances are launched.
  4. Students register for course instances based on the instance's access level.

2. Role Hierarchy

  • Institutes → Instructors → Courses → Course Instances → Students

Development Notes

Key Considerations

  • All courses must include assessments for their videos and articles.
  • A course instance's access level determines its visibility and registration flow.
  • Ensure all pipelines (video, assessment, etc.) are well-tested for edge cases (e.g., undefined segments, large datasets).
  • Modularize the code to separate concerns for institute management, course content, and user interactions.(Already done, need to improvize)

Suggested Practices

  • Use consistent naming conventions across modules.
  • Write reusable and scalable components for pipelines (e.g., video processing).
  • Maintain strict validation for content input (e.g., video URLs, timestamps).

Fine-Grained Proctoring Features for Students

This feature introduces configurable proctoring options for enhanced exam monitoring:

  1. Student Level Proctoring

    • Default: The proctoring level will follow the course-level setting.
    • No: Proctoring is completely disabled for the student.
    • Strict: The student is subjected to strict proctoring, overriding the course-level setting.
  2. Course Level Proctoring

    • Enabled: Proctoring is activated for the course.
    • Disabled: Proctoring is turned off for the course.

The final proctoring behavior will depend on a combination of the student’s setting and the course’s setting:

  • Student: No → No proctoring, regardless of course setting.
  • Student: Strict → Strict proctoring, regardless of course setting.
  • Student: Default → Proctoring follows the course-level setting.