Vineland Kiosks

We’re working on creating two web kiosks for the Vineland Lobby in the new building, and Nate and I have been creating these for the last couple days. We’ll be using two iMac G5’s as our kiosk stations, and the kiosk software we’ve chosen is wKiosk. We’ve also decided to run a proxy server on the machines, to cache content and make the machines faster. For that we’re using the open source software SquidMan. It works very well.

The initial setup was very quick and wKiosk is fairly simple to use, and it really does lock down the machine well. Testing turned up a few issues however. We’re giving the user featured links on the left hand side of the screen. To do this I’ve made a frameset that we can modify, that allows the user to click and view any pages we decide to feature. The problem was that there are many parts of our website (both old and new) that use hrefs with target=”_top”, which of course breaks you out of a frameset. Clicking on said links when browsing these sites gets rid of this featured link nav I set up for the kiosk. Not good.

We simply can’t change the live sites, but we can’t live with thier current implimentation for the kiosks either. Nate had the idea of dyanmically rewriting the HTML as it was requested, changing all targets to target our main content frameset instead of _top. He found another open source app named Privoxy that does just this, and it works great! Now we can happily surf around on the kiosk without the fear of busting out of our kiosk frameset.

As we poked around some more, we found issue with our Walker Channel. Most media on the channel is Real Media. We normally require users to load video into the Real Player to view it. wKiosk does not allow this as it takes over the entire OS, rendering other apps inopperable (which is great as a security feature, but not for usability of the Channel). Privoxy to came to the rescue again, changing every link of a .ram file into a link to a dynamic page I created to embed the Real file into, thus allowing it to play on the kiosk. But we weren’t quite done yet.

The videos were taking forever to load up, and it wasn’t the buffering that was the problem, it was connecting initially to the file. We figured this was a result of using a 801.11b wireless access point, and that the bandwidth just wasn’t there, but the videos played fine once they started, it just took forever to start. After many hours of trying to figure this out, Nate noticed that he had the firewall on blocking all the ports that Real Player was trying. It would go down its list trying a port to connect on, be refused, then try the next one. It took a long time for it to find the port it needed to get the video, thus the delay before the start of playback in the Channel. That’s now fixed and it works great!

Testing still needs to be done, but right now most everything is working as planned. It looks like this will be a pretty nice kiosk when it’s all said and done. Museum patrons should have a good time with it.