Recently we’ve been looking at SchoolTool and it raises a couple of interesting questions, namely (a) why can’t we use it, and (b) what can we learn from its design and data model? OK, maybe that’s three questions depending on your view of AND statements.
SchoolTool version 2 is very good, and all other things being equal we think you should probably be using it (version 1 is a whole other story but that’s history now). It lacks features we need, such as admissions functionality, and that’s a sticking point for us, but it is open source so in principle we could amend it – and this is the crux of our problem: viable extensibility.
SchoolTool is built on Python which is OK, it uses Zope which moves us a little off the reservation, and in turn for its database it uses ZODB, which is not really OK for us, because what these three things represent are a progressively steeper learning curve and consequently more dangerous subsequent production environment. Even if we went through the learning curve, given what some people think about ZODB, MySQL seems like a case of it being better the devil you know, than the devil you don’t.
What this highlights is the question of what is ‘normal’. The SchoolTool has gone down a route of tying their software into Ubuntu – which is not surprising because it’s developed by the Shuttleworth Foundation, as in Mark Shuttleworth, as in Ubuntu. And it really is ridiculously easy to install – if you have Ubuntu. You’re on your own with anything else though because it’s doubtful whether it can even run on a Windows server, and it’s certainly not supported. Running it remotely becomes a little more complicated as well because it uses its own server.
We really need something running at our school that another programmer and system administrator could seamlessly take over the development and maintenance of, and that’s not going to happen with ZODB, especially in South Korea. What that means for the nextSIS project is that we’ve made a conscious decision to ignore the tools the cool kids are using this year, and stick to PHP and MySQL, which are not sexy, but you can run it on basically anything, and you can find people with the skill set relatively easily. We’re aiming at the mainstream – and at normality – such as it currently is.
It pains me to not be able to just use SchoolTool because of its technology platform, especially as I’m writing this at home on my desktop running Ubuntu, but if I set up an Ubuntu server at my school and have all their data on it, and then something happens to me, they are potentially left with a server they can’t support (I’m the only Linux person there) – in a country where IT companies are considered adventurous if they know how to run a browser other than Internet Explorer on Windows. The choice of technologies is a real problem to us.
Database technology aside, SchoolTool’s data model is interesting in that at the interface level SchoolTool it appears to present a very transparent view of it. Essentially you have People, Groups, Courses, Sections (actual class periods), Terms and Timetables – and People are an entity. This differs from the preconceived idea that your entities in a student information system are actually Students, Teachers, Parents and so on, but it highlights the fact that database normalisation is an inexact science – sometimes you have to be a little pragmatic in trading off normal forms and efficiency, and sometimes it’s a matter of perspective in the first place.
The data model decisions made for nextSIS at this stage will likely define the system permanently and we’re having a serious rethink about our preconceived notions of what our entities are, because while SchoolTool uses an object rather than relational database, insofar as you can still model the former as the latter it does highlight an alternative approach which can carry significant implications.
For example, a number of our teachers have students at our school and are therefore also parents, but if teachers and parents are separate entities in the data model, at the design stage you’re left with one person being two very different things in the system – perhaps to the point of not being able to associate a student with a parent because they that parent in is your system as a teacher. In fact, this is how things are with namelessSIS, where the only solution appears to be for a teacher to have a separate user name as a parent in order to associate them with their children. Whereas, of course, if people were just people, then the logic is that one person (a student) can be designated as the child of another person (either a parent or teacher or anyone else), and a person has a one-to-many role, which can mean them being both a teacher and a parent.
The example where you have to create separate logins for teachers who are parents is actually easy enough to overcome in principle within the logic of a program, but it does perhaps set the program somewhat at odds with the data model, which is why the data model question is occupying a lot of time here at the moment.