So far we have a working playback system and a functional hook switch mounted to a plastic box I've used a million times. You pick up in the receiver, the audio starts to play, you hang it up, it stops.

The plan is to mount this hook on the side of our library and anchor the cable to one of the steel posts. Nice thing about the payphone receiver is that it's very tough, and the cable has a braided steel anchor so I'm fairly confident that it will remain connected and intact even under moderate abuse.

The hook is less durable, but that's part of why I wanted to go with a printed part. If it gets broken, or succumbs to the elements, we can just print a new one. I considered using a commercial payphone part for the hook as well, but I didn't know that they were available when we started the project, and they are a bit pricey. Also the ones I've seen would require more substantial modifications to the library (vs. just screwing the hook to the side) so for our application the custom design is better. That said you could save a lot of time with an off-the-shelf hook, and it would probably withstand more abuse, and if you don't have access to a 3D printer, that's probably the way to go.

There's a couple of possible directions to go from here. We need to come up with a means of mounting and protecting the electronics when the system is attached to the library. The current box won't do for several reasons, but I'm not sure if we want to go with an off-the-shelf box or something custom. Custom gives us the most flexibility (and is more fun) but it's probably easier to get the durability and weather-resistance needed with an off-the-shelf part.

The other area to explore is the "management" interface. Right now the software plays a hard-coded audio file included in the sourcecode repository when the handset is picked up. This works, but it would be cooler to have a way to easily change the file, or potentially upload several different audio files. What I'm thinking right now is having a simple web interface to list and upload files, and organize them so that one is designated as the "greeting" that will be played before every track, and then a directory containing the actual story recordings which will be cycled through each time the handset is picked up.

The barrier with this for me is that I haven't done much webserver development in Python, and I'd prefer to stick with Python since it ships with Raspbian and performs well on the hardware. I plan to write most of the interface as an HTML5 application, but I'll need a couple of API endpoints served from the device to interact with the filesystem, etc.

The obvious thing to do is to expose this interface via our regular WiFi network, but I'm considering configuring the Raspberry Pi as an access point instead. This would allow the library to function stand-alone, and would let Storyphone work and be managed even on libraries that don't have nearby Internet access. This opens the door for providing other library services via this "hotspot" like Ebooks, etc.; not unlike a Piratebox.