Slate as a Student Information System (Part 1)

I asked a friend, who works as a Slate consultant, the following:

“How often have clients thrown out the idea of actually using Slate as a SIS?”

“Almost never lol”

From a business standpoint, this makes total sense. Slate is a CRM which is typically viewed as a whole separate product from student information systems. Institutions usually have well established SIS’s with experienced vendors and changing systems can take YEARS of planning and developing.

…but what would that actually look like in Slate? Is it even possible? I intend on finding out by mocking it up in the clean Slate environment.

Why?

Well, there’s no actual tangible incentive for me to do this. However, I do think there is value in trying to push the system to see what’s possible. I don’t anticipate my institution wanting to do this but the hope is that we can use some pieces of this in the future. I also think it would give me a more comprehensive understanding of institutional data structures. If I can solve a problem here, maybe I can solve it in another system? I don’t know for sure…but why not try anyways.

There are MANY topics to cover when talking about student information systems so I’ll just try focusing on one at a time. To start, I’m diving off into the deep end with…COURSE REGISTRATION

If you ever worked with or for your institution’s registrar, you probably have a good idea of how wide this scope is. I don’t want to get ahead of myself too quickly so let’s just use this week to see if I can even build a functioning registration tool. Here are the requirements I set for myself:

1. Establishing the course data structure

2. Build a portal that will allow for student registrations and reflect the student’s current enrollment in real time

3. Reflect the course registration count

Let’s get started.

Course Data Structure

After a long brain-storming session, I decided the best course of action was to create two custom datasets: one for the course catalog and the other for the actual ‘active classes’. This will store the various courses that are scheduled, along with their location.

Course Catalog

• Title
• Code (Key)
• Category*
• Credits
• Prerequisites*

Active Classes

• Unique ID (Key)
• Course (related dataset row)
• Days
• Timeslot
• Max Capacity
• Instructor*
• Classroom*

Note: Starred bullet points are fields I will talk about in a later post

The Active Classes dataset will also be connected to an entity that will keep track of the enrolled students. This entity will just host a field that is a related dataset row that is linked to a custom student dataset.

That can be sort of hard to visualize so let’s see how it looks in practice. Here is a sample of one of the courses in our Course Catalog dataset:

Through a subquery export merge field, we can display the active classes that are linked to the course in our Course Catalog dataset.

When we drill down and look into the Active Classes dataset, we see the scheduling information as well as a list of the currently enrolled student, which is stored in the Enrolled Students entity.

Now that the back-end is set up, let’s put together the actual student course registration tool in a portal.

Registration Tool (Portal)

My priority here is simplicity. I want the student to be able to easily find their desired course, see the availability and basically hit a button to instantly register.

To achieve this, I landed on a page design that has two sections, one for the currently enrolled courses and the other for the course availability.

The ‘Register’ link is actually a pop-up form that is scoped to the Active Course. The portal pulls in the proper active class key and the GUID of the student that is logged in, so all the student has to do is submit the form to register.

You may have noticed Slate telling me to wait 3 seconds before submitting the form. This is due to the form submission rate limit that I suppose I was reaching when testing this. I’ll probably need to address this in a future post since students will most likely be accessing this through the same campus IP address.

As you can see, after the form submission goes through, the portal page updates to reflect the newly enrolled course as well as the course capacity counter. This is done with some minimal JavaScript that tells the portal to reload the views when the ‘Close’ button is clicked.

Note: Those form fields should be hidden in practice but I left them in there for reference.

So this seems like a pretty solid start! We’ve determined that we can, indeed, host the actual act of registering for a course in a Slate portal. Looking ahead, there’s much more that needs to be built out before I can consider this actually usable. Some things that come to mind:

• Course restrictions (i.e. Determining if prerequisite courses are completed, limiting total units, avoiding overlapping time slots etc.)
• Classroom and faculty/instructor datasets
• Discussion sections
• Search/Filter functions
• Classroom booking tool

The list probably goes on from here…so I am already regretting this decision, but I will continue to push ahead! (When I can)