Posts tagged RFID

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.

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.

There’s been an article recently on Bullet Online about the new self service machines in the library, and how some students find them difficult to use. This, I feel, is a fair point given that it took me a couple of minutes to get to grips with them and I’m pretty darn technology savvy.

What annoys me however is not that the Library didn’t make fixing the problem its number 1 priority (which it should – the system should have been overhauled for usability within days, not 2 months later and nothing done), but what one of the comments on the blog says. I’m not even annoyed at the contents of the comment, but what a subject librarian said when a student rep brought up the issue in a subject committee:

The subject librarin told us that the machines are state of the art and that the library has recived national regonision for this.

How to issue books using the self service machines.

Step back, and think about that. “It’s not a problem, these machines are state of the art”. So was the baggage handling system at Heathrow Terminal 5, and look what happened there. “It’s not our fault that your bags are lost somewhere because we didn’t test and train properly, the machine is state of the art”. That subject librarian should be hauled over the coals. It’s a problem because the student rep has told you it is, so what you need to do is acknowledge it and say what you’re going to do to fix it.

It has taken me a few minutes to put together this poster which explains (very clearly) how to take books out in 8 steps, and what to do if things go wrong. In my personal opinion this is about three steps too long, but these things can be improved on later. It is something like this which the Library should have done as soon as they realised there was a usability issue, not form a subcommittee (yes, there really is one) to discuss how they can improve usability and consider writing some help documentation.