Registrar progress

By early 1990 all of the teachers were typing their comments, many had computers at home, and most were using FirstClass. That alone was a huge culture shift.

What remained, however, was the printing and sorting and mailings of five to six thousand separate pieces of paper each marking period. It was still nearly impossible to know if all the comments were done, and the teachers still had to correctly separate and staple and hand in all the different colored copies. A lot of man-hours and huge areas for errors or omissions, even with the best of intentions.

I had been playing with FIleMakerPro for a year or more now since the adoption by the Admission office. It was an opportunity to try to again make a quantum leap in terms of productivity, efficiency and accuracy.

I created a multi-layout template with a page for each of the 6 marking periods. On each was a space for a grade and a comment. The teacher could just write their name once and it would be on every comment. The problem was that then I would have to show the teachers how to create a record for each student that they taught and have them enter that information.  Might there be a way to auto-fill a template for each teacher with all the correct students? Now THAT would change the game!

A lot of people had by now been experimenting with spreadsheets to organize things. A spreadsheet is basically digital graph paper with rows and columns. With a little skill one can make the numbers in a column add up or get their average. And with good skill one could make cells in one spreadsheet show up in a second one. This was very exciting but a spreadsheet is NOT a database. That fact remains unclear to many to this day.

With a database there can be may such tables and they can talk to one another using keys and as well as perform transformations of numbers and text on the fly. The data set or subsets can then be viewed on an infinite number of views either as list or with all the fields of one record. That completely changes the ability to work with the data and output the results.

What I realized was that to begin we needed a “sort of “ spreadsheet prepared by the Registrar’s office with a line for every student in every class. I created a FileMaker file and gave it to the Registrar’s office. They learned how to import most of the data from their primitive spreadsheet.

Each line was now a “record” and would show the teacher, the room, the student, the term, and the academic year. There also could be fields for the 7 grades—6 marking periods plus the year grade. Somehow if I could isolate the right records I might be able to import those into a pre-loaded template for each teacher.

At Loomis we were all learning together but it became clear that we all needed to learn about keys. To make this all work we needed a unique way to identify a number of things – students, teachers and rooms. Database 101 to the rescue. A key must have three things – exist, be unique, and never change. For most of us our “key” is our Social Security number. So together, we gave everyone a key.

I was not, by far, the only person working on this advancement at private schools. A number of people had created Access or FileMaker systems for their schools and even the big accounting system companies like Senior Systems and Blackbaud were introducing registrar systems.

The problem in many places was that the systems allowed for the users to create keys or IDs. So schools came up with ideas like – Last name, first initial and grade. So SmithH09. The systems often needed a user to type this ID in order to find a particular student’s info so it had to be easy and logical. But that quickly proved to be a nightmare. Families have divorces or get re-married, students repeat a grade, a name is very hard to spell, or there simply are two people with the same name. Using actual info in a key is a really bad idea. It is also a bad idea to use a database system that can only search by ID.

So the fourth unwritten rule about a key is that it is best to be simply random and auto-generated. So we then created S000001, S000002, etc, R0001, R0002, and T0001, T0002. With this, we could now create a list of all the students in courses and it did not depend on spelling the names right. We added a key for the line itself, called the Matrix ID.

The next great revelation was the Section. A section would be a course being taught in a room by a teacher in a given term. Section ID. So there might be 4 sections of freshman English, with a different teacher in a different rotation for each section. Students were only in one of the sections. This universal registrar list was essentially just a list of Student IDs and Section IDs! Amazing.

Because it was in a database and not a spreadsheet we could then create layouts where the registrar office could quickly print the classes that a student had, class lists for teachers sorted by section and alphabetized, or course schedules for a room. This alone gave that office power to check all the schedules and correct them in a way that was never before possible.

Numerous database registrar systems were becoming available in the early 1990s that were changing the efficiency of schools dramatically. The different technologies being used and the platforms made some of the options significantly easier to use and cheaper, but that was often not the main criteria for buying a system.

Loomis now had a way to better verify schedules and distribute the information to teachers and students, but I still had not generated individual templates for each teacher. But it was coming.