Timetables

Here at Middleware Towers, we were asked to look into providing students with access to their timetable, in a variety of methods. We have already blogged about inputting the data into google calendars, but for a variety of other applications we wanted a method that was lightweight and portable. We wanted to avoid being too heavily tied into the University’s systems, so we could give the methodology away without having to worry about bespoke parts.

JSON

Readers of our blog (you must be out there somewhere) will know we like JSON, we like it a lot, here’s why:

(JavaScript Object Notation) is a lightweight format based on the ECMA-262 standard. It is easy for humans to read and write. It is easy for machines to parse and generate and uses conventions that programmers using the “C” family of languages will be comfortable with. These properties combined with its universal data structures. make it an ideal data-interchange language.

Taking the module calendars we are already creating for our students google calendars, it was relatively trivial to also create JSON files of the same data (one per module, created by a script, controlled via Cron). These files would be in the following format:

[
   {
      "ROOMID_STR" : Harry Palmer 101,
      "MODULEID_STR" : "ABC001",
      "MODULENAME_STR" : "Advanced Converter Cars",
      "SLOTID" : "721",
      "STARTTIME" : "11:00",
      "ENDTIME" : "13:00",
      "LECTURER_STR" : "Professor Pat Pending",
      "DATECHANGED" : "201402140944",
      "MAPDATE" : "20-MAR-15"
   }
]

A further file per module would also be created, which would list those students registered on it. It takes the following format:

   {
      "j.bloggs@student." : [
      "ABC001",
      "ABC001 (B)"
   ]
}

The (B) indicates a cohort of the module, this is common practice if the module membership is large, it splits the students into smaller groups for such things as tutorials. We wanted our timetables to be fully personalised, so we also created JSON files for any cohorts a module may have.

Now we had the data in a format we could access and manipulate, we needed to find something which could present it to our students in a manner they were familiar with.

Fullcalendar

Fullcalendar is a jQuery plugin from MIT (who seem to produce an almost unending supply of these sorts of thing), It provides a well documented, AJAX based google calendar like environment. Its API is rich and it is easy to personalise the output. Some simple jQuery settings will allow you to control the default view and the type and position of controls and information:

header: {
        left: 'prev,next today',
	center: 'title',
	right: 'month,agendaWeek,agendaDay'
	},
editable: false,
firstDay: '1',
defaultView: 'agendaWeek',

This places the “<”, “>” and “today” buttons on the left, the month week and day button on the right and the title in the middle. It also makes it read only, sets the first day to monday and by default shows a week view (see fig 1)

fullcalendar
fig 1: Fullcalendar configured as above.

Provide the plugin with correctly formatted JSON, as below and you will get google calendar like output as seen in fig 2.

[
   {
      "title":"ABC001 Advanced Converter Cars with Prof Pat Pending in Harry Palmer 101",
      "end":"2015-03-20 13:00:00",
      "start":"2015-03-20 11:00:00”
   }
]

event

fig 2: Event output from JSON in Fullcalendar

Keen eyed readers will notice that the JSON required by Fullcalendar, doesn’t match the JSON we have in our module files. This would require some, on the fly, programatic manipulation via Perl (the one true language), to stitch together the lecturer, room, id and module name to form the “title” element. The datetime elements are formatted using perl’s localtime, split and join functions.

Putting it all together gives us a students personalised timetable in a portable format, that could be used for any of our applications (VLE, portal, student support systems etc) without any bespoke tie in to other systems.

A special thanks go to our IT support assistants (both past and present), for being willing guinea pigs and especially to Tom for remaining positive and optimistic, whilst we were destroying his google calendar setup on an almost daily basis.

New frontend for Booking System

One of the summer tasks we have been dealing with has been to bring the frontend of our Web User Booking System (WUBS) up to date.  The original user interface dates back to when it was first developed (2005) and, while still more than adequate for the task, was starting to show it’s age.

Sample booking screen

After a short discussion in the team it was decided to follow a similar method to that which had been used for LORLS, specifically separating the front and back ends via a set of APIs.  The majority of the development effort was spent on the frontend as the core work on the APIs had already taken place to enable our mobile webApp to review, make and cancel bookings.

The key technologies behind the new frontend are HTML5 and JQuery.  Additional JQuery plugins used are DropKick, to provide the nice looking drop down lists, and Datepicker, for selecting dates from a calendar.

Lab Availability

As part of the development of a student web information portal at Loughborough University a traffic light style widget, showing the usage of our computer labs, was posited. This would offer a number of advantages with students being able to chose the lab they would head towards by seeing those which were currently, or soon to be, booked and of the available ones which were busy.

Mash

The Active Directory (AD) was the first port of call for this. Each of our labs has their own organisational unit (OU), which contains all of the machines currently in the lab. The LDAP libraries of php could then be used to scoop up the AD computer object for each machine. An AD extension attribute on each managed computer was assigned and would contain binary data. 0 would indicate that the machine was not logged into and 1 would mean the machine was busy. Attribute control is handled by LDAP Modify commands that are run as part of the log on and off processes of the PC’s. By counting the number of zeros we could tell how many of a labs machines were currently free.

More mash

first_go

First attempt at the traffic light system

For those labs that are open access, the AD attribute control method offered all of the monitoring that was required. More work was required, however, on those labs that could be booked.

Therefore the second stage, was to question the University’s central timetabling system to see the status of the labs themselves. For this a database view was created, showing the status of the bookable labs throughout the day. SQL queries could now be sent to the view and the current and future status of the lab interpreted.

Mash with gravy

The Library uses a separate booking system (WUBS) for its seminar rooms and CAD lab. As these are not controlled from the central timetabling system, more mashup was required to connect to its API and once again poll for the daily booking data. Once this was achieved, it was simply a case of converting the WUBS API data into the same format as the central timetable data and output it all. This data could then be taken and combined with HTML5, to produce a unified traffic light display of availability throughout the campus (See our Digital Signage blog for the details).

pcAvailability

Pi and Mash. Raspberry Pi powered HTML5 mashup