I’ve been a student at the KU Leuven for almost three years now. My university delivers
various online services on our online “interactive” “learning” environment called Toledo.
These services include our daily schedule, exams, email, course documents, information, discussion groups. A lot of students (including this one) moan a lot about how Toledo is slow and user-unfriendly.  If Toledo is ever to be redesigned, I have some suggestions.

Recently during a debate (rector election candidates) the issue of Toledo was mentioned. Every candidate agreed that from a technological point of view, Toledo is really outdated. So the usual proposal is a simple redesign: Improving performance, reliability and user-friendliness. But in my opinion that won’t be enough.

If eventually the choice is made to create a new Toledo (do we really want this (the same in another packing) though?) I have a suggestion for people re-engineering it.

Please – oh really please – create a public API. I’m not going into security issues right now because that would lead us too far, but there is no reason why these issues would be unresolvable.

Why an API? Because Toledo will always be outdated or insufficient, even immediately after a complete redesign.  Because there will always be people thinking of something great that isn’t possible, and probably won’t ever be.

This includes things like (some things I just made up today)
– “I want my schedule in my Google calendar”
– “I want to receive email updates when someone answers my question on a discussion board. And I want to be able to reply just by sending a reply via
– “I want to be able to discuss via Facebook (I can imagine people wanting this)”
– “I want to receive an SMS when a lecture is cancelled”
– “I want to sync course documents offline on my computer so I don’t have to login every time or download everything manually”

All this – as far as I know – is *not* supported by default. Why? Because nobody thought of it, or because of the cost to hire people to develop this. (Or maybe because some people think that toledo should be boring and not have any
fancy feature at all!).
Lets say that somehow all this features got implemented in the next version. Hurray!? No! Because new lists of features will be made and probably never get implemented.

How can we solve this (partially)? Well I gave it away already didn’t I? A KU Leuven API.

(From here on I assume an authenticated user has a secure, encrypted connection)
Some things that would make my list from above possible would be to have access to:

– daily schedule
– discussion boards
– course documents and news feeds

Now every time someone (lets say a creative student) has a luminous idea that involves using this type of information
they can actually go and implement it.
A wonderful example is the story of recent KULApp. They (some freshmen!) created an application that provides you with a very neat way of accessing you daily schedule (apart from other cool stuff).
How did they achieve this without an API? Most probably hacked around, parsing the schedule webpage source code (That’s what I and many others would do). Then they got critiqued by the system administrators that they were generating way too much traffic.

Well here is another thing, if you provide an API (and applications must register with a main system and be accepted by system administrators in order to keep things under control (if necessary). However the approval process should really be optimized and simple.

But if you can control access to the API you can also regulate traffic right? Problem solved!

So lets recapitulate. The problem of Toledo is not the lack of services it provides, it is *how* they are provided to students.
Making easy and external access to information a feature of Toledo allows for limitless (but controlled) extendibility. This is fantastic. Mostly because students are the *only* persons who really know how they feel about using Toledo. So if given the freedom, Toledo (+ API) would never be out of date again (or wouldn’t it?)
Remember that in the beginning I mentioned that that an API would only *partially* solve the “outdated problem”. Obviously an API can be outdated as well. But then again, if my list of API features would be supported there are already a lot of things you could do with it.

Oh wait, one more thing: if you don’t make an API we’ll hack our way around it, just wait and see.