Educational Software Systems: What are our requirements?

My recent evaluation of strategic IT issues in my faculty brought one thing very clearly to my attention. If we assume that the content that I (or a student or any other academic) creates should continue to be available to me, unless I assign my rights to someone else, then we have a problem if the storage mechanism used is closed and fee-based. If it’s closed (proprietary formats possibly with deliberate obfuscation or encryption, or remote storage with access controls) then I can’t easily get it out of the system unless the software provider lets me. If this whole arrangement (licensing or access) is based on a fee, the the worst possible situation is that, in order to access old materials/data/whatever, I have to continue to pay largish sums on money to keep using something that I created. So that got me thinking – what else do I expect (naively or not) of the systems that we use for education? I’m talking mostly about Learning Management Systems (LMS) here because that’s my current focus. Here are some cut down versions of my current thoughts.

1. Modular: Not all schools, even in the same college, are the same. Some are big, some are small. Some need essays checked for plagiarism when submitted. Some just need a place to drop the assignments. Some need interactive quizzes! Some just need web pages. If we have a system that’s built out of modules then I can get the modules that I need and (if money is involved) match investment to requirement. Even in the open source community, there are issues of performance, management burden and complexity in the modules that you choose so customisation here is useful. Modularity also isolates the impact of faults. Well-designed modules are like water-tight doors on a ship – one module failing doesn’t sink the ship.
2. Extensible: There are always going to be requirements particular to your school or college. If your system can be extended then you can adjust the system to meet your specific needs. If not, then you have to work around it. (You could also call this mutable but I prefer the improvement implicit in extensible). Now I’m not saying who should be doing these changes because that’s a whole other argument – the fact that it can be done is what’s important here.
3. Open Storage: Whatever I create, I should be able to get to, export, import it back from other systems and hang onto – especially if we migrate to a different system and shut the old one down. I’m a great believer in keeping formats open and then, if your product is excellent, I’ll happily use it. If, at the start of our relationship, you say “Well, you give me your data and you’re going to have to pay us if you want to get it out, and pay us every year you want access to it.” then you are pretty much going to have to be the only game in town because I have no power or control in that relationship – and I’m the one who should be in control here. (Most people are getting really good about this now, which is good to see, but there are far too many examples of software where the same producer couldn’t maintain compatibility across two versions.)
4. Efficient: Using these kinds of systems should save you time. Something I’ve created should be able to be re-used easily, live or die as quickly as I want and survive between upgrades. There should be a definite advantage to doing this – if not, why are we using this system?
5. Robust: It should be strong. Students attack in waves and I have beautiful graphs to show that the day before an assignment is due it’s “STOP, Hammer time”, and weak or delicate systems will fail under this kind of load. Any system designer who has assumed an average and hardened the system up to 70% concurrent usage had better step back and add about 40% to that number to count for multiple accesses, dangling connections, staff use… Even more importantly, if I make a change to something (add an assignment, undertake an assignment, change a mark) it needs to stay CHANGED. Finally, I need to be able to undo things when and if they go wrong. Because things go wrong.
6. Invisible: Ultimately, I shouldn’t notice the system, and nor should my students. I use it to create things but I focus on creation, not your system. My students use it to access things and perform actions but they should never notice the system itself. If you look out a window, you should never notice cracked panes, dirty glass, rotting wood or the accidental sandwiching of a bird between the double-glazed panes.

I realise that there is a lot of debate on Open versus Proprietary systems in the community and I have no wish to open that can of worms – for myself, I use a Mac (mostly on the FreeBSD side) and do my analysis work in R, not S, but then I use Illustrator, not the Gimp, for final touch-ups. I’m the poster boy for using stuff that works so I have no wish to force people to choose open or closed, or ‘whatever is in between’. But I’d be really interested to see what else belongs (or what doesn’t belong) on this list – what do you think?