Our students have an ID card with an RFID chip used for various applications throughout the University. The Med School has two pcProx card readers from RF Ideas. (I don’t have custody of any now, so I can’t tell you the exact part number, but it’s pretty much this kind of thing: http://www.rfideas.com/products/pcprox_readers/). The readers act as a USB keyboard. You put one into any computer, swipe your card, and the reader “types” the card number into whatever has focus on the computer screen.

RF Ideas supplies a free Windows exe you can use to program the reader. (http://www.rfideas.com/Software/) It’s pretty straightforward, with settings for word length and such. At some point, Duke’s card office changed the word length such that old cards scanned fine in Swiper but new ones did not. We used the config utility to increase the word length and now all cards scan successfully. I needed a real PC to get the config utility to work. When using a Windows vm on my Mac, the utility could not see the reader.

This project started as a way to track visits to our computer lab. The first thought was to create an Excel sheet with macros to handle the input from the cards. Excel seemed like overkill, so I wrote a tiny shell program in Python to take the input and write lines out to a CSV file. Swiper was born.

Word spread and someone had the idea to use Swiper to track class attendance. I oppose taking class attendance at all. Our students are adults, paying big bucks to be here. If they don’t care, it’s their money to waste. Also, we have an honor code. I prefer to treat them as adults and expect them to follow the honor code by attending required classes. If an honor code violation occurs, then we could take action. That said, it still fell to us to adapt Swiper to take class attendance.

I updated Swiper to be a stand-alone, special purpose web server. It’s still Python. So the basic drill is you install it on a laptop, start the Swiper web server, point a browser to localhost, plug in the card reader, and start swiping. Swiper writes each swipe to a local CSV file. After class, it’s up to the class coordinator to get the CSV file off of the laptop and do with it whatever he wants.

Here are some general points about how Swiper works now:

We use MacBooks because we had a couple extras and because it comes with Python installed.

Each laptop is a stand-alone Swiper station. They do not network. That reduces complexity while swiping and lets you run one out in the woods if you need to. If you have multiple entrances to the venue, Swiper lets you designate an entry number for each station. This number becomes part of the CSV output file name, allowing you to put the output from multiple stations in a single folder and merge them or whatever.

Since they are stand-alone and not networked, when the code changes, we have to update each laptop.

From the students, we collect names and card numbers and load them into Swiper. This lets Swiper display the more engaging “Welcome, Paul”, rather than “Welcome, 123456789”.

With each swipe, Swiper displays a goofy little message, like, “Welcome, Paul! Jack Bauer can find you now!” That provides a bit of user engagement to make the dull process of swiping in a little more entertaining. The messages rotate through a pool. We’ve seen students hanging out a bit just to see what other messages come up next, so yeah, probably worth it to humanize the process a little.

To encourage less technical class coordinators, I take everything off of the desktop except for Swiper icons. “Me first” starts the web server. “Me second” is a web link to localhost. “Output” is a shortcut to the folder containing the Swiper output file. And I put a PDF of documentation on the desktop just so people will have something to ignore. I hide the OS X Dock so it’s not a distraction.

I do some simple length checking on each swipe. Occasionally we get an incomplete number. If a scan looks good, I display a success message in green. If a scan looks bad, I display a “Please try again” message in red.

I display a count of the total number of swipes. This is not a completely accurate count of the students in the room. The class coordinator may swipe his own card as a demo. A student may swipe in/out/in. But the count offers some sense of how many people are in the class. At the start of the class, it’s a useful ballpark number.

The output file contains one line for each swipe. Each line contains a date/time stamp, the card number, and the cardholder’s name if Swiper has it. If a student gets a replacement card, the card has a different number. So, we sometimes do small updates during a year to refresh the name/number cross-reference.

If a student swipes in/out/in, that’s three lines. It’s up to the entity interpreting the Swiper data to decide what that means.

I think that’s about it. In summary, the card read acts like a keyboard. The little programming we had to do on it was easily accomplished with the vendor supplied config utility. We’ve prettied up the app a bit over time, but it’s still basically just writing a simple line to a CSV file with every swipe.