For our exhibition Benches and Binoculars, I was asked to create a touchscreen kiosk. The artwork in Benches and Binoculars is hung salon-style, making it impractical to use wall labels on works that are hanging 20 feet up in the air. Many get around this by having a gallery “map” (and our Design dept did create these as well for the exhibit), but much like the exhibition itself, we thought it was a good time to “re-imagine” the gallery map.
I had never worked on a touchscreen app before. Sure, I’ve created kiosks here at the Walker but a touchscreen brings some new challenges, as well as some new opportunities. Input is both easier, and more difficult. You just use your hands, but people aren’t always sure how they are supposed to use their hands to perform actions, or even that they can.
As such my main goal when making the kiosk was to keep it simple. Don’t let the interface get in the way of the information. The interface should help facilitate finding the content you want easily. Too many times I’ve seen these types of devices be more about the technology than about the content on them. This meant making the kiosk less “flashy”, but in turn also made it more useful.
In the end the layout was rather simple. The screen has an exact (to the pixel) representation of the artwork hanging on the walls. Moving your hand right and left on the kiosk moved the walls on it left and right. Tapping on an artwork brought up a modal window with a high res image of the object as well as the label text. There is nothing particularly fancy or new about this idea, and there really shouldn’t have been. Much more would have taken away the experience you were there for, namely viewing the artworks on the walls.
As for the technology involved, we decided to use the HP Touchsmart PC for this particular kiosk. It uses an infrared field above the screen to track “touch”. As such you don’t actually have to make physical contact with the screen to activate a touch event, you just have to break the infrared plane.
We decided on the 22″ version because we wanted the machine to be single use. With the way the computer is set up, it’s not all that great at multi-touch as it is. And wanting to keep the device as simple as possible led to wanting to keep usable by one person at a time. There is a larger version of the Touchsmart but any larger than the 22″ and it felt like you were supposed to have more than one person use it at a time, which we wanted to stay away from.
Since we didn’t have to worry about multi use, we had a few more options on what to build the interface with. Most people would probably go the Flash route but for us Flash is usually the choice of last resort. This is for various reasons, not the least of which for me is lack of experience with Flash. But most of what you can do in Flash these days can also be done in the browser, and given that front end interfaces are my forte, that’s where I went.
The interface is just a simple HTML page that dynamically calls ArtsConnectEd for its data. Thankfully, Nate was able to leverage a lot of the work he did on ACE for this which sped up development drastically. Interaction is just built with some jQuery scripts I wrote. All in all it wasn’t all that difficult to get together except for a few snags (isn’t there always some?).
One was that I found very early on that interacting with a touchscreen is a lot different from using a mouse. Hit areas are much different since when you press on a screen your finger tends to “roll”. On the first mousedown event, the tip of your finger is in one spot, but as you press, the mouse position shifts lower on the screen as your finger flattens out from pressing into the screen. This means the mouseup event is in a totally different spot, which can cause issues with trying to register a proper click. A problem exists when trying to register a drag event for the same reason. As such I had to program in some “slush” room to compensate for this.
The second issue I had was that of the computer and browser itself. The Touchsmarts, while having a decent CPU were really slow and sluggish in general. I had from the beginning targeted Firefox for the development platform. Mainly because it has many fullscreen kiosk implementations as add ons. But once I loaded up 98 images with all of the CSS drop shadows, transparencies, etc, the entire browser was very sluggish and choppy.
I had read recently that Google Chrome was pushing v4 to be a lot faster and their new beta had just been released for it. Testing it I found that it was about 3 times faster than Firefox. The issue was it had no true kiosk mode. I was in a bind. I had a nice fullscreen kiosk in Firefox that was choppy, and a decent speed browser in Chrome that had no kiosk mode.
After much searching I found that a kiosk patch was in development on the browser. The only issue was patching it into a build. Unfortunately Google’s requirements for building Chrome on Windows is not trivial and I couldn’t find anyone to do it for me. In desperation, I emailed the creator of the patch, Mohamed Mansour, to see if he could build me a binary with his patch in it. Thankfully he came through and was able to offer up a custom build of Chrome with the kiosk mode built in that I could use for the exhibition. It’s worked wonderfully (note, this patch has since been checked into the Google Chrome nightlies).
In the end it turned out better than I thought it would. Chrome was fast enough for me to go back and add in new features like proper acceleration when “throwing” the walls. And the guys in the Walker carpentry shop, especially David Dick, made a beautiful pedestal to install the kiosk in, complete with a very nice black aluminum bezel. I couldn’t be more happy and from the looks of it our visitors are as well. It goes a long way to my (and New Media’s) goal of taking complex technology and making it simple for users, as well as the Walker’s mission of the active engagement of audiences.
You can see more photos in my Flickr set: