Building an Open-Source Learning Management System from Scratch

Reach LMS — Background

All we had was one month and a skeleton of a product spec with this description: “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.” Our Labs team spent the past month green-fielding this project with our stakeholder, Frank Fusco, who just so happened to be our Labs Manager as well. A resident Lambda staff member, Frank was the bridge of communication between our team and Lambda School.

Walking into Labs, I had very low expectations for how the team would function together. Thankfully, my expectations were surpassed within the first day alone. My team was full of individuals who came ready to work, motivated to ship a tight product with a clean codebase. Everybody pitched in while brainstorming how this product could look, what we needed to clarify with Mr. Fusco, and the various ways we could go about implementing each piece of it. A collaborative effort through and through, I’m pretty proud of what our team accomplished over the past few weeks.

Main Contributions and Challenges

My main focus for this application was crafting the forms for users to create and update Programs, Courses, and Modules. This task was ultimately rather complicated because of how all three of those entities (programs, courses, and modules) are intricately intertwined. Our group had decided to make a flexible user-flow where a user wouldn’t need to open up several pages to edit everything at once; we wanted administrators to be able to edit an existing program and in the same flow have the ability to create new courses inside of that program or edit existing courses. But at the same time, teachers aren’t permitted to edit a program… so that course form needs to be able to act independently of the program form if need be. And so on and so forth.

Here’s a demo to visualize:

Now, there was one overarching technical challenge in building these forms. Each form component manages its own state, but one form (such as the Program Form) will nest a Course Form beneath it and requires that form to behave differently based on various circumstances. I won’t bore you with fully inclusive list of all the edge cases, but let’s consider adding a Course to a Program:

• In this case, we know that an administrator has clicked the “Add Course” button in our ProgramForm; this pops open the CourseForm modal. The user fills out the course form and clicks “OK” to submit that course to our program… so what happens at that point?
• If we’re editing an existing program, we want to POST that course (because our program exists in the backend so we can do this right away!)
• If we’re in the process of creating a brand new program, we can’t POST that course yet because our program does not exist in the database! If we posted our course at this point, it would be floating out in space unattached to any program. So in that case, we’ll add our created course to our Program State and let the user Submit the Program Form and POST the Program. When they POST the program, we will send along the list of courses attached to the program and let the backend create any brand new courses.

Current Features

Our application currently has the following features:

• Users can log in through Okta (*note: users must have an existing Okta account at present)
• Users can have roles of an Administrator, Teacher, or Student and interact with content based on the privileges associated with their role.
• Users can view and edit their profile information.
• Once signed into the app, users will arrive at a dashboard with a view of all programs they are associated with, the courses within that program, and the modules within any course. Additionally, they will find additional options with what to do with those programs.
• Administrators can create, edit, delete, and view programs that they have created.
• Administrators can create, edit, delete, and view courses within programs that they have created.
• Administrators can create, edit, delete, and view modules within courses within programs that they have created.
• Teachers can only view programs as a whole but they have the ability to create, edit, and view courses and modules within programs that they are associated with.
• Students can only view programs, courses, and modules they are associated with.

Demos

Logging in and viewing a program from dashboard

Editing an existing program, adding courses & modules

Next Steps

Future iterations will build upon our foundation and add several pieces of very exciting functionality:

• Users will hopefully be able to sign up without having an existing Okta account.
• Administrators will be able to create and edit Teacher and Student accounts and attach said users to various programs/courses/modules!
• Allow users to upload various file-types for module content.
• Allow users to upload CSV files for student rosters
• Allow Administrators to freely customize granular permissions on an account-to-account basis.
• Potential for server-side rendering.

Some of the technical challenges I foresee is bundling this web app to be fast enough for cell-phone use in remote villages. In its current state, this app is ginormous. Ant Design was used as the main UI library and it is extraordinarily dense in its current implementation. Server-side rendering would fix a lot of issues on this front — a full-stack Java Spring application would be a really nice path for this application.