Happy Holidays and Happy New Year!
Hope this year is better, although it doesn't look to be. I'll be continuing this project since it gives me quite a bit of joy. Although, truth be told, developing for DiCMS and Blogger is starting to wear on me. This is my main passion project. Anyways, lets go over the updates!
Build School Classes that will run for the year and Class Sessions that will run for the Term
Done! This is the main culmination of the foundation of the LMS. Class Sessions (or its parent, School Classes) will be the main focus point where 80% of the system will revolve around. There will be other sub-systems that will link to other parts of the foundation, such as the request system linking primary to people, but the bilk of all the information will be related to the School Classes object. So what does the Class Session/School Classes look like? Like so:
Holy crap that's complicated! And that's just a big-picture overview. For the nitty gritty, you'd have to run some code analyzer tools, which I don't really want to do right now, but I will when I have more tables.
As can be seen above, the Class Session is linked to a Semester (actually, I think they're called Terms, but they're really semesters to me), while SchoolClasses is linked to the year. The idea behind this is that a class usually lasts for a year, but the actual class is usually broken up into terms. In the case of semesters, the Class Session would be linked to a Fall and Spring Semester. But it could be a quarter system with an all-year-round school with terms of Spring, Summer, Fall and Winter. A Class Session is where a learning unit takes place, with an assessment expected at the end. The assessment part is where most of what I would consider the “novel” part of this tool will happen, but the important part is that the Class Session is where the Formal Assessment takes place and the student receives a Summative Assessment at the completion of the Term.
Allow assigning teachers to the class sessions
There are some basic connections in the Class Sessions that are not detailed above. Mainly because of room in the diagram and the added complexity, but they make up the basis of the Class Session (and to a degree, School Classes) object. The first one is teachers. All classes require at least one teacher or instructor to lead the class. I call them teachers or faculty, but you can customize this in the lang folder.
Teachers are assigned to Class Sessions as a many-to-many relationship. This is an important distinction. Very few things are assigned directly to the School Classes, since the important learning takes place in the class sessions. In most cases, the class will be headed by a single teacher that will be there throughout the year. However, the devil is in the details and the law of big numbers apply, so there will be times where there will be more than one teacher (this is especially true with Teacher Assistants) and where a Teacher might have to take a leave of absence and the second term is being taught by a different teacher. In both these cases the need of multiple teachers that are assigned at the Class Session level become obvious.
There is one detail in my original system that I left out, which is the “teaching style”. I defined this as a choice between Single Teaching, in which there is a Single Teacher assigned to the class, Primary/Secondary Teaching, in which one teacher is assigned to the class as the primary and multiple are assigned as secondary teachers, with secondary teachers having less rights than primary teachers. Finally, there was Shared Teaching, in which there were multiple teachers ad they could all do the same thing. Of course, this system was tailored to our institution, so the Primary/Secondary teaching style was very specific to us.
I debated whether I wanted to include this and decided against it. Instead, the user may assign as many teachers as they want to the class. For now, all permissions are the same; mainly because there is nothing built to give permissions to. However I plan on building special teacher-only roles that can be assigned to give different permissions to each teacher in the class, the default being full teacher.
Build a schedule system that will have periods and blocks
Done! I loved this system from my original LMS the most, especially after working with a lot of the scheduling systems. The reason that I loved this was because of the simplicity. In pretty much all the systems that I've worked with, scheduling is done with real, actual dates. This means that in order to define the schedule for a class, you define the start and end term and then figure out a rotation, which is applied to dates, which is then applied to calendars. I've seen a lot of iterations of this, but they mainly revolve around using dates as the main calculation.
My approach instead is to abstract it farther into a week. A week is pretty much universal, with the idea of weekdays and weekends also being universal. So for my first try at this I built in a system where a Period is defined in the context of a day of the week (1 is a Monday, 7 is a Sunday) and a block of time during that day. The class schedule is then defined by the user using this control:
An you can see it makes it easy to build a schedule by simply picking the periods that the class takes place. You can also choose whether you will assign a single room to the class (which, again, will happen in most cases), or assign a room per period, for those weird cases. There is also an option for blocks. What are blocks? They're a way to group Periods together. Once again it depends on the school, but as a general rule school have traditional set times in which classes happen. In some cases students will have Math on the first period of the day, Science on the second, etc. In other schools, a rotation might be case, where students take math on the first period on the first day, second period on the second day, etc. You can then group these periods into “blocks” and give those blocks a name. For example in the first case, you may want to group all the 1st periods into a “Math” block, and then assign all the math classes that block.
Allow the class to have multiple rooms to meet based on the schedule
Done! As seen above, rooms can be scheduled as a single room or multiple depending on the periods.
Build the class enrollment to enroll students into classes
Done! Well, at least half of it is. I consider two ways to enroll students into classes: General Class Enrollment and Student Class Enrollment.
General Class Enrollment is where you take a large number of student that are selected through course filters and mass-enroll them into a Class Session. There is no subtlety to this but it is very useful. For example, all Kindergartens will be enrolled into Homeroom. So there is a Course called Homeroom, which has a School Class attached to the current year (2024-2025) and you would like to enroll all Kindergarten students into all the sessions of that class. This is done through this tool.
Student Class Enrollment is the schedule builder for an individual student. This is to specifically work with a single student schedule. It has tools that determine whether a student has overlapping classes or how many students are in the class. It's made when differentiated learning is a must and students in the same grade must be spread out through multiple classes in the same subject. It also needs to be responsive, so that it immediately updates when the classes are changed.
I currently have a rough version of the General Class Enrollment system working. It looks like this:
As you can see, classes (and sessions) can be selected through the main filter and so can students. The filters are pretty course, where classes are selected by course and subject and students are selected by grade and a simple toggle. Student can be selected (shift-select and ctrl-select work here great) and then you click where you want the students enrolled.
Yes! There is even some fake data that gets generated trough the seeder!
What is still lacking is real-time updates and the complete Student Class Enrollment system. Also, there is an “in-between” system. This is a special system built to be used by large school which lots of requirements. The idea is to set up a “blueprint” for the schedule, where students are pre-sorted into the courses that they must/want to attend. Once this blueprint is generated, one can clearly see how many classes a certain course will need (if you have 100 students and the max class size is 20, you will need 4 classes), and give you a rough idea of where each student should go. As an extra, admin should be able to give certain parameters, such as “Johnny should not be in the same classes as Billy” and the system itself should be able to generate a rough map of where each student should go. I call this system the Schedule Builder, more information later.
Bonus: Rebuild the viewable fields permissions system to be simpler and use the new role fields
In my last blog post I said:
The second thing that I realized is that the field viewing permissions are utter crap that need to be fixed. This one is going to be a bit harder I think. I have a few ideas, but nothing concrete. I know that this new system will have to include all the fields that I can define in the JSON fields, so it needs to be extendible and as easy as my current system.
And it was crap. So that is now rebuilt!
I used some of the ideas from the previous system but threw away quite a bit of it. First off it builds on the previous upgrade that I had to fields, where I removed all my CRUD tables that were used as fields for the Person object and replaced them with Role Fields that are special fields attached to roles that all people in that role have as an option. Now I went further and assigned permissions to both, the inherent fields (such as first name, last name, etc.) and the extended fields that are defined through the roles.
The scope of the permissions has changed though. Whereas before the system allowed you to define whether a field could be seen or not seen or set by users, the ability to be set by users is removed. Why? Two reasons: it was too complex to determine who had access to what and, in the end, there were very few fields for the users to determine. So we're now left with the school making the determination of whether a field can be seen or not, and whether it can be editable by the user or not. Furthermore, I don't worry about the role viewing the field, only whether they're an Employee, Parent or Student. The permissions are permissive, meaning that as long as it is allowed in one place, it will be shown. This makes loading the permissions super simple, as they're loaded into the system all at once as a collection. I haven't yet enabled the caching system yet, but it's still done through a single query and the rest is through collection manipulation.
If a user needs full access, then they should be given the people.edit or people.view permission.
The House is Next
Once the foundation is built, it's time to build the actual house. In our case the actual house will be the system that is used to run the school. The plan for this system is to build a complete LMS with all the features needed to run a school. The largest part of this system will the assessment piece, which will have a gradebook and communication mechanisms to creative a formative approach to assessment. But the system also needs to have a way to provide summative assessment and to create official records (transcripts) of all the work done. The system needs a way for the teacher to manage their classes, even if it's through a separate website, like Google Classroom. There also needs to be features and systems that are independent of classes and assessments, but deal with other work that must go into running a school.
This is what I call “building the house”; We will be using the existing foundation and building the LMS on top of it. Every piece of it will be interacting, in some way, with People, Campuses, Years, Terms, Class Sessions and School Classes in some way or another. Furthermore, as of right now, there's nothing for users to see. A new home page needs to be built that displays a lot of information: classes for students and teachers, student info for parents, etc. With all that in mind, I give here a list of all the things that I would like to see in my LMS before I can think of a 1.0 release. Note that this list is not the final list, just something that needs to happen before I can start thinking about official “releases”.
Homepages with customizable information at the role level
The assessment System
The Gradebook System
The Class Management System
The Scheduling System
The Progress Report System
The Transcript System
The Requests System
The ID System
The Check-in System
The Substitute System
The Room Reservation System
The Events System
The Rollover System
There's more that I'm forgetting, but I'm saving official list for a longer post or something more official. Until then though I would like to continue building slow, with simple achievable goals. I think I will also make a push to complete DiCMS and Blogger so I can concentrate on this fully.
But what to work on next? Well there are a few things that I would like to work on.
Fill In Information
There is a lot of information that needs to be put out there, possibly given permissions. For example, students should be able to see their schedule of classes; teachers too, but for the classes they teach. Rooms have schedules too that needs to be filled out too.
There are a lot of missing spots of information in the person profile. There are links that are left with placeholders on that should be linking to certain things, like current class or their schedule. The schedule should be publishable through iCal as well, so that students can subscribe to their calendar of classes.
Student Class Enrollment and the Class Scheduler
I've described what the Student Class Enrollment, which is something I will probably build ASAP. Along with this, I will be adding live-updates to the existing general class enrollment system though web sockets, but the Class Scheduler is another beast.
First off the Class Scheduler system needs to come with a way to “sort” students into courses and well as offer students the ability to select classes that are offered for the next year. Once that is done, then some restrains need to go in, such as “this student needs these many classes”, or “these two students should not be together”, etc. Then, classes and sessions are created based on need/availability and a schedule that works is given to the classes.
The last part of this system is to enroll the students into the appropriate classes. This is an NP-Complete problem. This means it's pretty much an unsolvable problem if you're brute forcing it. I ran into this problem back in the day when trying to determine a solution for the enrollment issue and that's when I found out about the fact that this is an NP-Complete problem that I couldn't just solve. So I turned to a tool that was in development at the time called OptaPlanner, which allowed me to use their tools to create a JAVA program that would resolve this for me. I would like to re-visit this, but I would have to do a lot of pre-work first, which I'm not yet ready for.
Homepages
I this this will be the most important and impactful update yet, as it will actually start showing information about your place in the school. For Students it should show their schedule and a list of classes. Similar to teachers, except for the classes they're teaching. Parents should see information about their students.
Regardless, something should be showing for each type of loggable-user.
Class Management
Teachers need to post things in classes, Students need to interact with those things in classes and parents need to be aware of the things, but not interact. This “communication” can include things like events, announcements, syllabi, etc. The interesting part is that there are now a LOT of different website that will do this for you, but lack on many other features that I will try to build on. But the power of these external sites simply cannot be understated. This is specially true of things like Google Classrooms, which is amazing at distributing information, but sucks at parent communication and assessment.
The compromise is a system that can do the basics but can also be linked to external class management system through some sort of API. I would like to start building some of the basics, like Announcements, Class Conversations, Links, etc. while doing research on how to link to other LMS's.
These four issues will be my main concentration for the next release. I will also like to start talking a bit about how my system will be using Formative Assement as the basis fr the assessment. Will update when I'm done.