When we began the project to build a new Student Information System (SIS) one of the first questions we asked ourselves is whether to write something for internal use or whether to try and engage with other schools to see if there was scope for building something together as a collaborative effort.
The latter approach carried a number of burdens and risks. We chose the most widely available technology platforms (PHP and MySQL) in order to appeal to the widest possible pool of developers while trying to at least avoid the mess that many PHP projects can become by using the CodeIgniter MVC framework, I built a website here at nextsis.org and started an open source Github project, and spent a lot of time talking to people around the world about what we were setting out to do.
I strongly believe in the idea of schools coming together to create their own educational software solutions because we have had really poor experiences with software companies with their commercial agendas and design inflexibilities, and I know this is not uncommon with my counterparts within the school community. However, we do face an inherent disadvantage in such endeavours, namely that we have day jobs which only afford us so much time to engage in longer term projects such as this one.
At the beginning of this academic year we thought we were in a more fortunate position than most because we believed we had the time and resources to build the new system we envisaged, which is why we stepped up with our nextSIS proposal. Two things happened. We didn’t succeed in building the small network of developers we had hoped to despite our efforts, and I was called upon to write a complete grading and reporting solution for my school when the external vendor that we believed was going to provide this didn’t do so. This latter development is an extremely long and sorry story, which is not likely to be told in the foreseeable future for legal reasons.
The grading module within our existing open source SIS was not remotely suitable for our needs, so I replaced it with our own for first quarter reports in November. For this I integrated Twitter Bootstrap into the aforementioned SIS, and used FPDF to generate the reports. But it was the full Semester 1 reports which quickly became the focus once this was done, as it culminated in the production – visually at least – of 50 separate data entry screens and 8 PDF documents comprising a total of 53 pages in our Elementary School alone and an additional – but thankfully smaller effort for our Middle and High School. Once the grading exercise is complete, the student report PDFs are to be automatically emailed to parents – from a Windows server, which turns out to be much more difficult.
Having to work on our existing student information system at the expense of investing in the future by building its replacement has been frustrating, but it is not a wasted effort for nextSIS because it has provided valuable insights into user acceptance of new interface designs in addition to technology I am likely to integrate into it. However, it also carries with it some hard lessons about the fractured nature of student reporting – even within our school which now has three significantly different report formats. How can we rise to the challenge of providing something which can meet such diverse needs in one system?
We are certainly behind schedule because of these unforeseen circumstances, and going forward we will always find ourselves beholden to the difficulties of working within a school where sudden demands to solve more immediate problems can take our focus away from building a better software future. But while we are far behind where we wanted to be, and I would have to concede that our hopes of launching a first version in August appear increasingly remote, we have to get where we are going, so our goals are unchanged and we will continue to do the best that we can – both for ourselves and for the wider community who have expressed interest in this project.