The Power of Open Policy

One of the outcomes from the Orbital project that I’m part of is a set of new policies on the subject of research data management. Early on it was decided that this would – in the spirit of open research – be made available under an open licence along with the rest of our resources on the subject (such as training and support materials).

Being the technically minded folk that we are, we wanted to make sure that several of us could work on documentation at the same time without running the risk of overwiting each others changes. We also wanted a comprehensive versioning system to be in place from us putting the first words into the keyboard so that we could see every single change and who made it, something that we think is a big part of making a resource truly open. Finally, we also wanted a mechanism which could allow other people indirectly connected to the project to propose changes. Given our history of using similar systems to manage code there was an obvious choice – the Git source control system.

Git is a system which primarily relies on tracking line-by-line changes, meaning that when we wrote stuff we’d want to use a file format which behaved on a line-by-line basis. This made compiled binary formats such as Microsoft Word or even PDF a bit unsuitable, since a small change could result in a huge set of changes spanning hundreds (or more) of lines. We also wanted to use an open standard which didn’t have prohibitive licence restrictions and which was simple enough to be read and understood by anybody with a basic text editor. There are quite a few standards out there which meet this requirement, but again based on past experience we’re using Markdown for our RDM Policy.

Finally, inspired in no small way by the efforts of the Bundestag to convert their entire body of law to Git we wanted to store policy on a platform which not just allowed community involvement, but which positively encouraged it. GitHub is the world’s largest repository of open development, covering every language under the sun and projects ranging from hardcore low level programming through writing documentation through to communal story writing. Even better, they provide free hosting space for open projects. We already had a University of Lincoln user kicking around from past work, so it was a logical place to stick our Git repository. If you’re interested you can take a look at what we’ve got.

What’s interesting about using open text-based standards to write policy, Git for managing revisions and GitHub as a storage provider is that we’ve inadvertently made it very easy for people to do things that they couldn’t do before.

Continue reading “The Power of Open Policy”

Data-driven. Iterative. Awesome.

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.

All About You

As you’ll know if you follow the adventures of Alex and myself we’ve been playing around with our new-look staff directory (give the beta a whirl). We’ve rebuilt it from the ground up to be stupidly fast, using bleeding-edge search technology all wrapped in Web 2.0 goodness to deliver your search results as quickly as possible. After all, why would you want to hang around waiting for half a second when we can have the number you’re looking for in a quarter of that time?

Directory search is awesome, but we thought we could do more with this information. We could take a person’s staff directory entry and make it a little bit more epic, as well as a bit more useful on the internet as a whole. So we did, and we’re happy to introduce the (beta) of staff profile pages – for examples see mine, Alex’s, Joss’s and Paul’s.

Continue reading “All About You”

Why RFID? Why Not?

I’ve recently had a small ponder on the subject of the University’s ID cards and ways to make them more useful, since user experience is something I care strongly about and how we identify people is a big part of that.

Something I’d really like to see is the University have a proper unified access system, after recently talking to a student who carries their ID card and three other completely blank white cards to allow them access to various rooms and buildings. One other staff member sports two white cards (completely blank) and a keyfob on top of their ID card. At one point I carried my student ID card, staff ID card and no fewer than four mysterious blank white cards all issued by various University departments.

Asking someone to carry multiple additional credit card sized pieces of plastic and potentially clip other things to their keyring is over the top when people are already carting around driving licences, debit cards, store loyalty cards and lord knows what else. On top of the sheer quantity of plastic is the inherent flaw in having blank cards – yes they provide no information on which doors they open which is great if they’re lost, but equally they provide no information on which doors they open which is really annoying if you have more than one of them.

I propose that to solve this problem the University replaces all staff ID cards with RFID enabled ones (Mifare 1K cards for preference, the exact same ones as the current mysterious blank white cards). As soon as this is done they issue all new students and card replacements with RFID cards.

A blank white Mifare 1k card, bought in a pack of 100, will cost around 70p. Yes this is more than the current blank cardstock, but the extra expenditure is virtually nothing in the grand scheme of things (you could easily spend 50-60p on giveaway pens). The card externally looks and feels exactly the same, so all of the University’s current information and security features will work, including the barcode to retain perfect backwards compatibility. In short there is no risk whatsoever to existing ID card processes and systems in moving from ‘dumb’ cardstock to RFID cardstock.

Since the new cards follow the exact same standards as the current mysterious blank white cards a person’s ID card can now be treated as a security card. There is absolutely no requirement at all for multiple cards, since in the past I’ve had my blank white cards merged into one. Keep a note of which person each ID card belongs to and should they lose a card or leave you simply look up their name in the system and revoke the card access, then as soon as they get a new ID card you restore their access.

In theory such as system (should our building security sport half-decent interfaces to anything) could even be tied into HR and student information systems, which is where what I do comes in. Imagine that when a student enrolls their card is printed as usual and automatically programmed to let them into the rooms which are appropriate for their course. When a member of staff is issued with their ID card there’s no subsequent waiting for a departmental administrator to fish a mysterious blank white card from a filing cabinet somewhere, they’re simply instantly granted access to their building and office. Finally, when someone moves or leaves their security access is seamlessly updated.

Yes, RFID will cost more (pennies per card), but as far as I can see all we’re going to do is maintain compatibility with barcode based systems, streamline and simplify the building access systems, and since Mifare 1k is a fairly de-facto standard for RFID applications (cashless systems, security, you name it) then we’ve put in part a major part of infrastructure for future developments.

So what do you think? Arguments for and against are more than welcome.

Unlocking Gateway

My most recent project (following on from Jerome, slotting in around the rest of the Summer’s “oh God, students are coming back, fix everything” mayhem has been to look at Gateway, more specifically to take Gateway and give it some extra awesome based around exploratory work we did with MPath. Here’s a quick breakdown of what you can expect when it’s turned on.

Very pretty. Very fast.

We’ve moved from a CWD 2.3 based design to our brand new CWD 3.0. This gives us a huge number of improvements in just about every area; layout, typography, readability, accessibility, compatibility, mobile readiness, new JavaScript frameworks, massively improved speed optimisations and more. We’ve compressed files and shaved off unnecessary bytes from almost the entire framework, making it load astonishingly quickly even over mobiles.

CWD 3.0 is also served over a blazingly fast content delivery network. Specifically we’re using Rackspace Cloud Files, who pipe their content to end users over the Akamai network. Put simply, this means that content such as the styling and images is delivered to your browser from a point much closer in internet space, regardless of where you are. If you want to access the Gateway from Bhutan then instead of serving all the content from a box in Lincoln some of it will come from whichever one of Akamai’s 84,000 servers happens to be closest. The result is a blisteringly fast experience, and since a lot of the Akamai servers are hooked straight into providers’ networks then it’ll still be quick even on mobile devices.

As mobile as your mobile.

We’ve made sure that Gateway optimises itself on the fly for most modern mobiles, and since it uses the CWD for its underlying design it’ll instantly take advantage of future improvements as we deploy them. We’ve sat down with our desks full of phones and tablets and tested things to make sure they’re easily read and are simple enough to use with just one finger.

Smarter.

Gateway now runs on a brand new system, meaning we can give it some extra smarts. If you visit Gateway and we’ve noticed there’s a problem with Blackboard then you’ll be told about it, meaning less clicking a link and waiting whilst it doesn’t load. It can tell you the local weather forecast, show you which trains are running late and even give you notices specific to your location, all in one place.

It’s all about you.

Sign in to the Gateway or use any of the services using Single Sign-In and it’ll gather all kinds of information you might find useful and display it for you. Your next lecture, assessment deadlines, how many library books you’ve got out and more is right at your fingertips.

Rock solid.

Gateway has moved from one very resilient platform to another even more resilient platform. Located off-campus on a world-class hosting platform Gateway can survive snow, flood and even builders cutting through power lines to provide you with updates even if everything else is going wrong.

Is Blackboard down? Now you can find out.

Today I’ve been looking over some of our stats for service uptime, and realised it would be handy if we could let you (the staff and students using them) know when things were broken.

Now you can, as I’ve just added another three of our core services (Portal, Email and Library Catalogue) and one non-core but useful service (Blogs) to our Pingdom monitoring system. They now join Blackboard on a brand new public status page. Even better, because we like being open with things like this, you can see the history of our monitoring as far back as it goes. For the new ones this means you can look over history back to today, but for Blackboard this goes all the way back to February.

Pingdom’s monitoring is from a variety of locations around the world, meaning it reflects ‘real’ availability and not just what we can see from our own internal network.

See what’s up and what’s down, any time, at stats.lncn.eu.

So, what’s going on?

Good question. It’s been a while since I’ve blogged, so here’s a really quick overview of what I’m currently working on, pretending to work on, worked on but haven’t done anything with, or planning to work on.

  1. Linking You, our current JISC project on institutional identifiers. Finishing up next week, and currently causing Alex and myself epic amounts of beating our heads against the desks.
  2. Jerome, our other JISC project on making libraries slightly more awesome.
  3. Zendesk Phase 2, including bits and pieces of integration work to make it smoothly flow through everything else we’re doing.
  4. Nucleus (and assorted fluff), our epic store of everything, being brushed up, pinned down and fully documented.
  5. Authentication being made even cooler, and more reliable, along with support for more stuff like SAML.
  6. GAME, our application management environment, being made more awesome.
  7. Room Bookings will be coming over the summer, allowing people to find and book rooms faster than ever before.
  8. Lots of QR Code goodness all over the place, including on room labels (this hooks up to room bookings for added goodness).
  9. Possibly a bit of hardware hacking in the Library with RFID stuff.
  10. CWD updates to version 3. Faster, lighter, more accessible and generally good.
  11. Total ReCal rollout to replace our legacy Timetable system (we hope).
  12. Replacing the legacy phone book with the new one (we hope).
  13. Data, data, data.
  14. A bit of mucking around with telephony, just for kicks.
  15. Taking another look at our Student Communications project to try and address a few annoyances.

There’s not an app for that.

Recently there’s been a lot of noise made about mobile applications for universities and colleges. Apparently what students want to see is a dedicated app for their institution, providing them with bits and pieces of information on just about everything. There are plenty of examples, a quick search of the iTunes App Store reveals several universities which are keen for you to download their slice of application goodness. Entire products have sprung up to address this market, and some places have even gone all out and written their own.

All this is good. After all, who wouldn’t want to be able to check things like their timetable, their library fees and the state of the university’s IT services from their phone? What could be cooler than tapping a button and being told where your nearest free PC or copy of a book is? We like the concept so we’re having a look at mobile stuff, especially given that according to our analytics an appreciable fraction of our users are now trying to access services from their mobile.

However, we’re not entirely convinced about the route of apps. Sure they let you hook straight into things like geolocation and local storage, but with HTML5 so can a website. Apps also need to be made for the whole range of devices out there. iOS and Android are the big players, but you’re then cutting out Blackberry, Windows Phone 7, WebOS and Symbian devices. Apps also have an approval process to go through, or if not then they have a slightly complex installation route. There’s also a requirement either to pay someone a lot of money to make an app, or to spend a lot of money on in-house development.

All this means that we’re steering away from apps as much as possible, but we still want to make sure we provide kick-ass mobile services. “How?” I hear you cry. The answer is amazingly simple – we’re going back to mobile-optimised websites.

Continue reading “There’s not an app for that.”