Computers in Libraries 2014 - Day 1 - Moving Ideas Forward

Unfortunately I missed the first 15 minutes or so of this presentation as I got back from lunch a little late (I am going to note in my conference evaluation this time around that 1 hour is a little tight for lunch when it's common to walk a half-mile to the place you're going to eat and that you might strike up an interesting conversation with someone else attending the conference).

The presentation I missed much of was from James Liebhardt of NCI Information Services who was describing a process of developing services for patrons.  The part I caught made the sensible points that it's important to get products you are developing into your patrons hands early and that waiting for a perfect product is not a good strategy.  It is best to see how people use the product that you are developing and use some tests to evaluate it.

A couple specific kinds of tests that he mentioned for patron testing were:

• The smoke test - put a link to a product that really isn't quite there (more the promise of a product) on the website to gauge interest.  If no one clicks on the link, then maybe you don't need to develop this product.  If the link becomes the most popular thing on the website focus all of your energies there.
• The A/B test - Show half of the people looking for a kind of thing a beta product while you direct the other half to whatever you would have done before.  Find out if the people who use the beta product fare better.

When this presentation was complete there was a second presentation that I did get to see all of.  James Stephens from the University of Maryland Baltimore County described his experiences with an experimental product.  This was actually a pretty interesting presentation as a lot went wrong with this experimental product, although it wasn't a complete disaster by any means.  The stakes were low (failure meant the status quo) so it seems to have been a great learning experience.

 

In his instance the university has a lot of study rooms that need to be reserved on a website.  Students frequently don't know this and there's no easy way to figure this out without going to the website which you can't do easily (or know to do if you can) if you are standing in front of the door to the study room.

 

So James thought (my paraphrase), "What if we buy a bunch of Raspberry Pis, hook them up to touch screens and put them at the entrance of each study room?  That way the schedule for the room could be shown on the screen and if someone wanted to reserve the room on the spot they could using the Raspberry Pi." It is important to note here that there was a real problem that James was trying to solve and he had come up with an innovative way to try and fix it.  James observed himself in his presentation that it is critically important to approach things in this way, i.e. "I have this problem, how can I solve it" rather than "I have this cool gadget, what problem might I be able to solve with it."

 

This idea (which has progressed to a kind of functional product at this date) hit a host of obstacles.  First the people above him, who didn't want to look like they were just being cheap, wanted to know why they were using these $35 computers rather than just buying a regular computer and putting it there.  James' answer, which he hadn't really developed initially because he hadn't anticipated this line of questioning, was that this wasn't being cheap to be cheap, but rather being cheap because the product was adequate to the task and by being cheap they could do more (put the things all over the place).

 

After that initial hurdle came a number of other hurdles. 

• The security enclosure for the device, which was necessary to keep it kind of neat and difficult to walk off with or tamper with, was more expensive than all of the other parts combined (about $200 for the enclosure). 
• The enclosures were designed for iPads and the screens, although iPad sized (roughly) rubbed against the enclosure causing them to falsely read touch activity. 
• The first touch screen they got was defective and had to be shipped back to China adding a huge delay, so the first draft of the device had to be done with a non-touch screen which meant the product had to be temporarily changed to a display of the room's status rather than an actual station where the room could be reserved. 
• The Raspberry Pi does not have built-in wireless and its wireless implementation is a little flakey, so it would randomly drop off the network and code had to be written for it to make sure that it was connected to the network and to reboot itself if it wasn't.
• People would unplug the thing at night so it wouldn't properly shut down.  After that happened a few times the SD card running the OS would get corrupted and it couldn't boot anymore and a new SD card with the image would have to be put in to replace it.

There were a few other issues as well.  These have mostly been sorted out, but it sounds like it was quite the learning experience.

James mentioned that there was also a project that they worked on there using a Raspberry Pi for digital signage, but he didn't have time to go into the details on what worked and what went wrong with that.

I personally have had a lot of experience with the kinds of things James described here (I haven't used a Raspberry Pi, but I have used several other small, flash-memory based, Linux computers) and I empathize entirely with his goals and with the obstacles he encountered. They are the kinds of things I would anticipate in such a project.  There is little that gives you the same level of satisfaction when you've completed such a project and have things working, although I could only imagine trying to work out those issues in a production environment of the type James was working in (so far, at least).