Benefits: Academic Staff

Nick Jackson Surveys & Analysis

Total ReCal is aimed most directly at the students, there’s no denying it. However, universities are complex places with more special interest groups than you can shake a stick at. We affectionately refer to these people as “academics”, and this blog post is about how Total ReCal and My Calendar will help them.

One of the main activities of academics is often teaching, be it lectures, seminars or smaller groups. At the moment we have a staff timetable which can be used to see where teaching happens, but My Calendar provides a much smoother interface to the same data. Once we’re sure the basic functionality is in place we can then go a step further, giving the academic access to information such as attendee lists directly from within the application. It’s a small thing, but we think it’s helpful.

Another big thing that we’ve heard time and time again from academics is that they very easily forget to return library books. In an ideal world everybody would jot down due dates in their calendar, but when you’re trying to manage everything else it just isn’t practical. My Calendar will solve this by making book due dates seamlessly available from the same place, automatically taking into account renewals. We’ll even put a ‘renew it now’ button straight in the calendar for the times when you just can’t be bothered walking to the library to return a text.

“But wait,” I hear you cry. “Academics don’t have time to visit yet another website to see things, otherwise these problems wouldn’t exist.” Well, we’ve solved that as well. My Calendar also sports industry-standard iCalendar outputs for everything, making it a breeze to load information straight into the calendaring tool of your choice and keep it updated with zero effort. Almost all smartphones support it, and the vast majority of desktop calendaring applications do as well. We’ll be providing in-depth instructions on how to get yourself synchronised at launch time.

Benefits: The Student Side

Nick Jackson Surveys & Analysis , ,

As Total ReCal nears completion, we’re preparing to open the beta to our pilot group and I’m starting to throw together our promotional materials it’s time to start writing up bits and pieces of our analysis. Contrary to popular belief this isn’t an incredibly dry, boring process which will make you all want to cry but a chance to show you just how damn cool this is going to be, how it will make life easier, and how the work we’ve done can help other institutions up and down the country to drag themselves out of the mire of multiple calendaring systems. First in line: how Total ReCal will benefit students at the University of Lincoln.

In the past, students at Lincoln have used a wide variety of different systems to organise their lives. It’s not uncommon throughout the course of a year to have an induction/reinduction timetable, your academic timetable (which changes regularly), an exam timetable (or two), a list of assessment deadlines, a calendar of meetings with seminar groups or tutors, book due dates, club or society events you want to attend, guest lectures, skills training timetables, a list of gigs you want to see at the Engine Shed and a personal calendar on top of all that. With tens of different systems all trying to tell you when and where you need to be it’s far to easy to miss something or double book yourself. The consequences of mucking up your calendar can range from the mildly annoying through to putting your degree at risk.

Total ReCal (or, as we’re naming it for Lincoln, My Calendar) is the first step towards tidying up some of this mess by dragging as many of these systems as we can together into one. The benefits of this unification are readily apparent, when the University moved exam timetables from a single massive schedule into personal timetables the response was overwhelmingly positive. Even small reductions in the number of disparate systems which are required are welcomed with open arms by a student body who are increasingly overwhelmed by the sheer volume of information they are presented with. The reasoning why is simple – it’s a lot harder to miss something important if everything is kept in one place.

Continue reading →

This isn’t your grandmother’s API permissions control layer…

Nick Jackson Design & Planning, The Technology , , , , , , , , ,

I’m guessing your grandmother probably didn’t have an API permissions control layer, but if she did this wouldn’t be it.

This post is mostly about Nucleus, our name for the storage layer which drives the Total ReCal components. The only way to communicate with Nucleus is over our RESTful API. This comes as somewhat of a shock to some people who believe that the way to move data around is a batch script with direct database access, but I digress…

What I’m going to try to do here is summarise just how epically confusing our permissions handling system for Nucleus is, mostly for the benefit of Alex and myself who (over the next week or so) will be trying to implement this layer without breaking anything important. It’s really, really essential that we get this done before we start promoting the service because of a few simple reasons:

  • Data security is important, and we don’t want anybody being able to read everything without permission.
  • Data security is important, and we don’t want anybody being able to write all over the place without permission.
  • Changing this kind of thing on a live service is like trying to change the engine block on a Formula 1 car whilst it’s racing.
  • We need to be able to guarantee the system can hold up to DoS attacks or runaway processes hammering the APIs.
  • People are already asking for access to this data for important things, like their final year projects.

So, where to go from here? Let’s take a look at everything which will be going on in the finished version.

Server Rate Limiting

Even before the Nucleus code kicks in, the server is fine-tuned to avoid overloading from any IP address or hostname. Using a combination of the OS firewall and the web server configuration overall request rates and bandwidth usage is kept below thresholds to ensure that the server is never overloaded. Due to the RESTful nature of the API (in which each request must represent a complete transaction) we have no requirement to ensure server affinity, so if the load gets too heavy we can easily scale horizontally using pretty much any load balancer.

To keep the pipes clear for our ‘essential’ services we do maintain a whitelist of IPs which have higher (but still not uncapped) limits.

Key Based Access

The only way to access any data in Nucleus is with an access token, issued by our OAuth system. These come in two flavours, either a user token (which grants permission for a specific user), or an autonomous token (which is issued at an application level, and is ‘anonymous’). The very first thing that happens with any request is that the token it gives is validated. No token, no access. Invalid token, no access. Revoked token, no access. To keep things nice and fast we store the token lookup table in memory with a cache of a few minutes, since most requests occur in ‘bursts’.

Continue reading →

Update

Alex Bilbie Updates , , , , ,

This has been a big month for Total ReCal. We’ve now perfected our event importers for Blackboard assignments and academic timetables, and we’ve started working on the main web application (screenshots too). We’ve also launched a beta registration page for interested staff and students to sign up for early access. Finally, our Talis Keystone service that the University has recently purchased will be in place very soon meaning we can also start importing book return dates for staff and students.

After numerous code re-writes we’ve got a rock solid API for adding, updating and deleting events in our Nucleus data store. Our import code has also had many updates to support logging of changes to events which will be invaluable to students to keep them up to date. Once the main Total ReCal application has been developed we’re going to sit down and work out how we’re going to best make use of these logs.

When a lecturer calls in sick the central timetabling department isn’t informed (unless it will affect lecturers for a long period of time). Therefore based on our current nightly timetable imports we won’t find out about any changes. We’re going to develop a tool for faculty administration staff to make changes to events as they’re going to be more aware of what the situation is day to day. This means that we can then inform students of changes that day as soon as someone changes it.

In terms of the front end, I’ve forked our common web design, called it ‘common web design x’, made it fluid to adapt to browser size, made it completely semantic HTML5 based, and taken the concept of progressive enhancement to new levels. It will also make use of our new OAuth 2.0 based single sign on service that I’ve written and it will automatically adapt to mobile layouts.

Moving Forward

Alex Bilbie Design & Planning , , , , ,

Over the past week we’ve worked tirelessly to perfect our timetable import code and we’ve now got a system that is working with real data. A select few students have now been given access to iCal feeds for both their timetables and their Blackboard assignments and the Library is hoping to have their Talis Keystone system in place very soon meaning we can start producing feeds of people’s book return dates.

Our next big job is to move away from bulk imports of data and instead start developing code that will go through and validate and verify events. So this could be looking for changes in the time of events or verifying that the right students are seeing the right events (in the event of a student changing course for example). With these changes logged we can then tackle one of the top requests that students have of the University and that is to be better informed of changes to their timetables.

The main timetables are produced by the Registry department however they aren’t informed if a lecturer is ill on a particular day, and in any case timetables aren’t updated currently until the following morning, so we’re planning on developing a tool for faculty offices to use so that they can make individual amendments to timetables when rooms need changing or lectures have been cancelled so that students can be informed sooner.

The logging of these changes will be important for Blackboard too. Certain schools and faculties like the idea of personalised assignment calendars however their own internal policies don’t allow staff to set deadlines inside Blackboard because deadlines may be changed by lecturers and senior staff aren’t informed. This is why the Computing School for example release a huge Excel spreadsheet of deadlines because it means only two people have access to change deadlines. We don’t want to be in a situation where we have to create individual departments their own tools to manage assignment deadlines, we’d prefer everyone used Blackboard and so with the ability to log changes to events what we could do is delay the update of the deadline in the student calendars for 24 or 48 hours giving senior staff a period in which to change it back to the original date or leave it (i.e. approve the change).

Our plan over the next few weeks is to perfect our API for querying events, give more students access to the their iCal feeds and also start developing the front end calendar application.