This spring and summer, I’ve taken on a full-blown re-write of our PD registration and management system. Our current system is a collection of centralized Google Apps Script projects which create, share, and manage all event folders, documents, and records. It’s worked well over the last two years but there’s been a single point of contact for everything: me.
Now that we’re getting more people involved in professional development, it’s time to have a more robust, user-based system for creating and managing events as well as teacher signups and recordkeeping. This post is going to explore the first role: Staff Users. These are teachers or staff who are registering for and tracking participation in events.
The home page shows logged-in users all district events. Their own state is shown on course badge as either Attended or Registered. Clicking on a course shows specifics (presenters, location, etc) in a sidebar. If a user registers for an event, their course badge updates dynamically which prevents multiple registrations by the same person.
- Google calendar invitation to events
- Only show upcoming events
- Disable registration on events with no remaining space
This is essentially a filtered view of workshops or events the staff member has signed up for. Each event’s status is shown and details are displayed in the sidebar when the event is clicked.
- Custom date filtering
- Expand view to remove a click for details
We’ve had a digital sign-up tool in place for several years. The biggest improvement I’m excited about is the documentation processing. Any registration is put into a database which can be queried and filtered by a bunch of parameters. This allows me to build out a nice spot for teachers to find their documents on demand and print whatever they needed rather than waiting on us to generate a PDF from a spreadsheet and send it off.
This page shows the which events have their participation or completion confirmed by the facilitator. The reason this confirmation step is so important is that we need to move away from being trained and move toward showing competency. So, a workshop might be a part of a program, but it does not guarantee that the staff member has actually improved.
This is a big shift for us. In the past, we used a standard feedback form. But, given the variety of presenters working with us, we wanted to give people more freedom in how they collected feedback. Also, since we were generating all the feedback forms centrally, we found presenters were less likely to actually read the feedback because the questions may not have been relevant to their own goals. At worst, participants were filling out multiple forms at events – one for us, and one for the presenter. Taking the form out of the documentation flow simplifies for everyone.
Without showing the presenter interface now, this view is any confirmed event for the user. They are also given a couple snapshots at the top: total registrations (how much am I signing up for) and Professional Growth Points (PGPs) earned for completing requirements.
From here, they can either print a summary of all activity on record or print individual documents as needed. All of these details are generated by the database. The record is also validated by the server and database rather than taking input directly. There’s no more wondering when an event was or how many PGPs it was worth because it’s all driven from a single source of truth.
That’s a quick view of a portion of this site that’s just about finished. But there’s a lot happening in the background to make that work and to allow different people to manage. In future posts, I’ll detail Presenters and SuperAdmins and their roles on the site for creating and managing events. I’ll also get a technical post published on the technology used to build this as well as deploying.