Category: Labs

Data-driven. Iterative. Awesome.

Nick Jackson / / DIrectory, Labs, Open Data, User Experience

If you’re a member of staff at the University you will soon be hearing loads more about the Directory, the planned replacement for the University’s phone search system and staff profiles.

Whilst the Directory itself is rather cool, how it’s been built is of somewhat more interest. First of all, it’s driven entirely by data from other sources. The Directory itself doesn’t store any data at all, save for a search index. This means that unlike the old staff profiles on the corporate website it helps to expose bad data where it exists — since we soft-launched the Directory we’ve been barraged by requests from people to ‘fix their profile’, when in fact the thing that needs ‘fixing’ often lies at a far higher level. In some cases it’s literally been a case of people having misspelt job titles in the University’s HR system for years, data which is now corrected. This whole cycle of exposing bad data and not attempting to automatically or manually patch it up at the Directory end helps lead the University to have better data as a whole, making lives easier and people happier.

Secondly, the Directory is a perfect example of why iterative development rocks. The very first version of the Directory arrived over a year ago, and since then has been improved to include semantic markup, a new look, faster searching, staff profiles, more data sources, open data output formats and more. Over the last couple of weeks as it’s started to be integrated with the corporate website it’s been subject to even more refining, fixing formatting, typos, incorrect data and more. These changes happen quickly – a new version is released with minor changes almost daily – and are driven almost exclusively by real users getting in touch and telling us what they think needs doing.

The upshot of doing things this way, harnessing data that already exists and letting people feed back as quickly as possible, leads to products and services which reach a usable state far faster, are a closer match to user requirements, and help to improve other systems which are connected or exist in the same data ecosystem.

Told you it was awesome.

T-t-t-t-t-t-touch me!

Nick Jackson / / Labs

Today, as a little bit of an indulgence, I had a play around with my RFID reader (from the excellent Touchatag starter pack), an old computer we had kicking around, and the Foursquare API. Why? I now have a reader on my desk which, upon me swiping my ID badge over it when I arrive at work, will check me in to the Main Admin Building. I’m planning to expand it to do other interesting things at a later date, such as letting me swipe my mug (I really need a SMUG) over it to turn on the kettle.

The reader, placed next to my phone.

So now, to the interesting bits. The reader is a ACS 122U Tag Reader, plumbed into a bog standard PC running Ubuntu 11.04. On this PC I’m also running the latest version of Ruby and Tender Lovemaking’s NFC wrapper. I should point out at this point that the prerequisite of libnfc can be a bit exciting to install along with all its dependencies, including an awesome bit where you need to compile a load of stuff, package it and then unpackage it all on your local machine. Fortunately instructions do exist to help.

Once that’s all done the Ruby script itself is quite simple to get going. I based mine on something that was previously cobbled together to let us play Harder, Better, Faster, Stronger using OS X’s ‘say’ command, which was based on something that Julian Cheal had come up with, which was based on something that Tender Lovemaking (again) had come up with. Your mileage may vary, as when I tried to do something similar on my laptop (OS X) it transpired that I’d somehow got 3 different versions of Ruby, all working with different gem installations.

Getting the NFC wrapper to read the tags is quite easy, it turned out that I ran into far greater problems talking to APIs to make it do something interesting. I’m using two APIs, one the excellent Boxcar to let me know that things have worked properly (or not) on the headless system, and the other to actually perform the checking in on Foursquare.

A quick swipe, and the world knows I'm here.

Boxcar is a convenient HTTP POST API, which I was able to find some code snippets to steal from with a quick search. Foursquare, on the other hand, is HTTPS. This causes all manner of problems and an awful lot of cursing as I scoured Google for a reliable method of making it work. Once I’d mastered HTTPS, all was good and I was able to effortlessly check in.

The only problem at the moment is caused by the NFC library occasionally seeming to suspend itself for a bit, meaning that it won’t read tags until it comes back. I’m going to experiment a bit on Friday (I’m off to London tomorrow for a chat about SOA) with this to see if swapping thread priorities or using a different polling method will solve it.

Information Everywhere

Nick Jackson / / Labs, Service 2.0, User Experience

In the past few weeks I’ve been dabbling (in between my ‘real’ projects of Jerome and Linking You) with the concept of ‘dashboard’ displays and information radiators. For those of you unfamiliar with the concept they are fundamentally a place which presents information in an easy to digest format. Some are pinboards, some are whiteboards, some are clothes lines with bits of paper pegged to them and some are displays or projectors.

What I’ve opted for is the display method, in no small way inspired by the guys at Panic. However, since between ICT we have what is generally referred to as a metric shedload of information that we want to get hold of I decided that instead of crafting a display for each individual group’s specific needs I would instead come up with a sexy looking framework for rapidly building dashboards. These are designed to live on large screens dotted around the office, visible all day to anybody who happens to look at them.

There’s already an example in use at the Service Desk, where a trusty old iMac is proudly displaying various stats from Zendesk (our ticket manager) to the support team. Initial feedback is that people really like being able to get an overview of what’s going on in one place, as well as any urgent jobs and their feedback averages.

Down in the depths of OST, on the other hand, we’re not massively bothered about our ticket stats in such an immediate manner. Instead we’re far more interested in things like our server availability, response time and load. This means that the modules on our dashboard currently pull data from our Nagios monitoring tool, informing us with the red alert klaxon from Star Trek if things go horribly wrong (causing much turning of heads towards the board to see what’s happened, and everyone else in ICT looking at us in confusion).

Hopefully as time goes on more people will find data which can be represented using these boards, meaning that they will start popping up in more places and exposing data which lets us make faster, smarter decisions about what we’re doing. I’ve already started working on a dashboard for getting the data from the agile development tracker that Alex and I use into a really easily digested format, and I’ll be talking to the Projects team to find out exactly what they want to see with regards to more overarching project management.

Easier? I think so.

Build a Better Search

Nick Jackson / / Labs

Hot on the heels of my Staff Directory Search, I decided this lunchtime to make it even more awesome. “But wait Nick!” I hear you cry. “How can you make it even more awesome than it already is?”

Well, how about avatars for everybody (using the awesome Gravatar system), adding tel: links to phone numbers so users with compatible software can dial with one click, kitting out everything with semantic markup using the microdata spec and adding OpenSearch descriptions?

How Staff Directory Search Works

Nick Jackson / / Labs, Open Data, Projects

I’ve had a couple of people ask how my lunchtime project today actually works behind the scenes, so here’s the lowdown in easily-digestible speak. I should point out that I am relying heavily on two frameworks which we’ve already built at Lincoln. These are Nucleus – our heavy-lifting data platform – and the Common Web Design – our web design and application framework. These two gave me a massive head-start by already doing all of the hard work such as extracting data from our directory and making the whole thing look great. Now, on with technology.

Continue reading “How Staff Directory Search Works”

The Dashboards Are Coming!

Nick Jackson / / Labs, Service 2.0, User Experience

Hot on the heels of my ability to extract key information from Zendesk, I’m pleased to announce that we now have two new bits of data available for people to digest. The first one is a set of numbers from our current service desk software, which will (hopefully) be appearing in the ICT service desk sometime in the next week whilst we try hammer through some old tickets.

The next, more usefully for everyone on the academic side, is a summary display of PC availability in the GCW. There’s a bit of worry that the numbers may not be 100% accurate, but we’ve got a hardware audit planned so hopefully by the 24/5 opening these stats will be shockingly accurate, and possibly arranged into zones so you can find a free seat even easier.

Enjoy!

A Universal University Search

Nick Jackson / / Labs, Open Data, Web 2.0

During my time as a student I was faced with a great many challenges which involved some form of searching. Lots of it was academic, relying on the Library, Google Scholar and (gasp, horror, revoke his grades) Wikipedia. However, a lot of it was about more mundane stuff. Where exactly is AR1101? Who is John Smith, and what’s his phone number? What’s for lunch today?

The problem was that to find this information, you already had to know where to find it. Maps of the University are available on the Portal… if you know where to look. Phone numbers can be looked up… if you know the address for the service. The weekly menu is on the Portal… if you know where to look.

We’re left with a simply astonishing number of things which people may want to know about, but which is locked away as an image of a screenshot embedded in a Word document stored 14 levels down in Portal behind a page which nobody has access to, unless you happen to have asked for it. Rooms, events, books, journals, the Repository, blogs, people, news posts, lecture notes, the weekly menu and more are all available somewhere within the depths of a system. So, in traditional Nick fashion, I spent a few minutes in the shower this morning working out how to fix it whilst being refreshed by some particularly minty shower gel.

Continue reading “A Universal University Search”

Really Fast Rooms

Nick Jackson / / Labs, Open Data

Here’s yet another bit of Labs which we’re just kicking off – this time a big one (as in people who love data will love it). We’ve called it Nucleus, as in the centre of something, because it’s a little scheme of ours which aims to draw all the information which drives the heart of the University into one set of APIs.

The first very early look at our aim is the Locations API, or at least part of it. This is a RESTful interface (for those of you who know your types of API) to our database backend which runs on the frankly amazing MongoDB. The result is a really, really fast and flexible search of rooms.

To start with it’s been loaded with a small subset of the Spaces Database maintained by Estates, but in future this database will contain just about everything there is to know about a room. How many seats it has, which direction the windows face, if it’s air conditioned, if it has beanbags, when was it last carpeted and more could all (potentially) become available.

We’ll be adding application authentication to the Nucleus APIs soon (don’t worry, we aim to be pretty flexible about handing out keys) but for now the GET method to take a look at our rooms is open access. We know some bits of it are a bit flaky (floors) and some are just missing altogether (features, which worked with our 6-room test set but which we haven’t filled out data for the extended one) but we hope to improve those as soon as possible. Take a look at the documentation and see what you can make it do.

Continue reading “Really Fast Rooms”

Location Aware Lincoln

Nick Jackson / / Labs, Open Data, Web 2.0

One of the cooler things we’re working on at the moment is location awareness for our web applications. This lets us do useful things, like adjust page content based on where you are. The new Room Bookings system, for example, will detect your campus and automatically set your default location accordingly. Even things like the new Library service (“Jerome”) will be able to intelligently change things like library contact details and opening times based on where you are.

Give it a go. Visit http://location.ll.tn-uk.net/ from anywhere on campus (either wired or wirelessly) and it should tell you where you are. Sorry that it doesn’t look too pretty, but it’s basically a testing front-end to an API service we’re cooking up.

The Roadmap

Nick Jackson / / CWD, Get Satisfaction, Labs, lncn.eu, LUNA, Open Data, Posters, Print From My PC

Just to keep you up to date, here’s what’s planned to be happening on a few projects we’ve got kicking around over the summer. This is in addition to some other big ones we’re working on like Project Jerome (a brand new way of interfacing with the Library systems) and online postgraduate applications.

Authentication

  • Completion of our OAuth 2.0 interface for login.
  • Application Directory to handle issuing of API keys, secrets and tokens.
  • Taking a closer look at seamless SSO.
  • Adding the ability to use University usernames and passwords at Get Satisfaction.

Linking You

  • Administration interface.
  • Even faster.
  • Improved statistics.
  • Link checker (monitors for broken links and notifies accordingly).
  • Support for custom minified keywords.
  • Support for alterable destinations using 307 redirects instead of 301.
  • Improved metadata & thumbnail gathering.
  • Warnings for potentially unsafe or unsuitable destinations (to stop link masking).
  • Support for web hooks.
  • Membership of 301Works.

A-Z

  • Admin interface.
  • Link checker (monitors for broken links and alters lists accordingly).
  • Highlighting of links requiring login.
  • Support for even more export formats (CSV, XBEL and XML) on top of JSON.

LUNA (Network Access for Student Village & Riseholme Park)

  • Updating the design to the CWD.
  • Faster.
  • Removing dependence on JavaScript.

Posters

  • Going live on the production network, ready for its shakedown in the public eye over the summer.

Common Web Design

  • Even more blisteringly fast.
  • Lots of behind-the-scenes goodness to get it looking even better on older browsers and Internet Explorer.
  • Unicorns.
  • Various tweaks and fixes.
  • Custom styling for even more elements of the page so you don’t have to.
  • Moving to a new domain name and production server so we can roll it out to even more sites.

Printing

  • Better compatibility with more operating systems (hopefully).
  • Colour printing support.
  • Integration of Pay For Print, so everything is in one place.