Skip to content

Home

Jump to bottom
chaz-kiker edited this page Apr 4, 2021 · 7 revisions

Understanding Reach LMS as a Product

Introduction

Reach LMS is an open-source learning management system designed for the developing world. Reach lets organizations offer education and training to anyone—whether they're working from a laptop in a city center or a solar-charged flip phone in a remote village.

This repository contains the source code for the RESTful Java Spring Boot backend application that drives the creation, storage, and access of data that drive this product.

Big Picture

Reach LMS is intended to serve as a general-purpose, open-source Learning Management Systems for various educational circumstances. Our goal is to provide users with an infrastructure wherein they can design curriculum however they see fit and serve that curriculum to any sort of student body. Whether it be an online school for coders across the US or a training program aimed to enable women in rural Africa to trade legally, safely, and profitably... Reach LMS aims to provide the backbone for any organization to create, manage, and distribute educational curricula of every shape and size.

Long-term, we hope to provide users with the following:

  1. Complete agency over how their content is organized, formatted, and shipped; this would hopefully include large-scale control over the hierarchy of various resources
  2. Flexible control over groups of users all the way down to granular permissions for what each user specifically can and cannot do to any content in the system
  3. Support for Assignments, Grades, and Graduation life-cycles
  4. Support for User Management & user life-cycles from user on-boarding to editing user's roles or outright blocking user access
  5. Incredibly fast response times of all media from the Database to the End-User, whether that user is on a desktop or solar-charged mobile phone.

Current Development

This product has spent the last two months building up, breaking down, and refining an incredible foundation for future developers to build upon.

The last two months have focused on developing a powerful foundation for the following broad-strokes features:

  • Building a base-level hierarchy for educational content
  • User Authentication: Sign-Up, Log-In, Deletion, Profile-Updates; integration with Okta
  • Designing role-based interaction with educational content that grants various operations and resources to users based on their role. This includes the creation, editing, deleting, or viewing of any content in the curriculum hierarchy.
  • Coherent and flexible relationships between any users and any entities in the curriculum hierarchy.

Curriculum Hierarchy

We have designed the following hierarchy to define what educational curriculum should look like to start out:

Programs

Programs should contain the following fields:

  • programname — The name of the program
  • programtype — K-12, Higher Education, Training, etc.
  • programdescription — A description of this program's focus; what does it teach?, who is it for?, etc.
  • user — An ADMIN who claims "ownership" over this program.
  • courses — A collection of courses that belong to this program
  • tags — A collection of ADMIN-defined tags that represent the possible sub-categories for courses in this program.

Courses

Courses should contain the following fields:

  • coursename — The name of the course
  • coursecode — A natural identifier — a unique text field that allows creators to control how a course is identified
  • coursedescription — A description of this course—what does it teach? who does it teach?
  • program — The program to which this course belongs
  • users — A collection of users "enrolled" in this course. This set will include both TEACHER and STUDENT users
    • TEACHER and STUDENT users are differentiated by their role, not a separate join table
  • modules — A collection of modules that belong to this course
  • tag — A tag selected from the list defined of available tags set by the ADMIN when creating the Program to which this course belongs.

Modules

Each Module should contain the following fields:

  • modulename — The name of the module
  • moduledescription — A description that gives an overview of what this module focuses on
  • modulecontent — Markdown content that contains all the learning content in this module
  • course — The course to which this module belongs

Tags

The first step towards user-defined hierarchies... an ADMIN has the ability to define a group of Tags for a program. Each Tag will have a simple title and hexCode to represent the name of this tag and the associated color.

For example, if I were to go create a program called "Web Development," I might opt to keep my number of tags slimmer:

  • Frontend
  • Backend
  • Computer Science

Or, maybe I'd prefer to have a BUNCH of different tags, like so:

  • Frontend
  • Backend
  • Computer Science
  • React
  • State Management
  • Java
  • Spring Boot
  • NodeJS

Either way I prefer it as the admin, I can make all these tags. Then, each course that belongs to this program could specify a tag with which it should be associated.

Types of Users and their Permissions

ADMIN

TEACHER

STUDENT

Clone this wiki locally