Blogs Media Lab Hardware

Multitouch Kiosks Highlight Collection

It’s difficult to blog about a collections-focused touch screen in a museum without drawing comparisons to the amazing Collections Wall at the Cleveland Museum of Art — and feeling entirely inadequate. We’re not (yet!) anywhere near that scale, but luckily for our egos we weren’t aiming there with this project. We wanted a simple, intuitive interface and […]

It’s difficult to blog about a collections-focused touch screen in a museum without drawing comparisons to the amazing Collections Wall at the Cleveland Museum of Art — and feeling entirely inadequate. We’re not (yet!) anywhere near that scale, but luckily for our egos we weren’t aiming there with this project. We wanted a simple, intuitive interface and something we could evolve in-house after watching and analyzing user behavior.

wall_2

AJ explores some of the garden artwork on the new screens.

We stayed true to the original idea of a “big swipe” interaction, creating what’s essentially an enormous photo-viewing application with zoomable images and some video mixed in. As another way to celebrate the 25th anniversary of the Minneapolis Sculpture Garden, we chose to launch the screens with highlights from the Garden.

Under the hood

The screen are running Google Chrome in Kiosk Mode and displaying a simple web page supported by a lot of custom Javascript. To keep things fast each screen is running a Squid web proxy to keep a local copy of the content, and the videos are also stored locally to avoid buffering issues. I thought Squid would manage to cache the videos, but due to the way they’re served using HTTP Range Requests I had to install a very vanilla Apache server locally to get them working. A bit of ugly overhead that keeps it from being a truly standalone solution, but something we were unable to solve on a deadline.

table_change

Design and New Media hanging paper representations of the screens to get a sense of scale and placement.

We’re also logging interactions using Google Analytics’ Track Event API (easy, since it’s just a web page!). Right now we’re tracking when the screen is “woken up” by a visitor’s interaction, when they open the textual “Info” button, and when they play a video. With video we also separately track if they watch all the way to the end, and if they don’t we log the timestamp they stopped watching.

The project is on our public Github account, so please have a look if you’re interested.

Content admin

The content is fed to the web page via a simple JSON file. AJ built an online editor that allows us to rearrange slides, import new collection objects and video, and edit or create the “Info text.” Very often our public-facing projects run into tight deadlines to launch and the admin / maintenance side of things never gets finished, so I’m quite excited to have this working.

Screen Shot 2013-06-06 at 1.31.58 PM

Lessons Learned

Gestures are different at this scale.

Sure, we know HTML5 and Javascript and have built some nice gestural interfaces before, but we weren’t prepared for the differences of a large-scale screen. Instead of tidy touch events using single fingers, we were seeing people swipe with their whole hand, or two fingers, or four. People tried to zoom using whole hands dragging in and out. Kids would “tickle” the screen and overwhelm our scripts, leaving the device crippled. While we gained many days by developing and designing in a familiar toolset, we lost almost as many days trying to rapidly mature our touch library. Midway through the project Ideum released Gestureworks Web Socket bindings for Javascript, which is absolutely the approach I’d take next time if we stick with HTML5. We learned the hard way that a true multi-touch vocabulary is not something you can just “whip up” from scratch…

Attract screen felt like a “home page”

Eric built a fantastic opening animation to attract visitors’ attention, which they would then dismiss to start interacting with the slides: “Tap to begin.” A number of our early testers mistook the animated gestural instructions for a menu, and were quite distressed when they couldn’t find a way back to the “menu.” We toyed with changing the intro and couldn’t solve it until finally we realized we just needed to change one word: “Swipe to begin.” By making the intro video actually be the first slide, users were able to discover the operation of using the screens (swipe) at the same time as they “dismissed” the intro. And the intro was always available by just swiping back. It’s a no-brainer now that we see it, but it’s one I’m glad we tested and re-tested.

Video is being watched until the end!

… about 10% of the time. That doesn’t sound like much, but it’s honestly higher than I expected (caveat: only a few days of stats). The space isn’t an especially inviting one for consuming media, but the content is compelling enough people are happy to stay and watch. We’re still collecting data to see if there are any trends around the timestamp when people stop watching — I hope this will inform the type of video content that is most appropriate for the medium and environment.

Position matters

So far the right-hand screen is used almost twice as often as the left-hand, which is a bit deeper in the space. So it may just be ease of access and people engaging with whatever they reach first, but we’re watching this closely for clues for future content: maybe one screen could be a long-running silent video? Maybe one screen never returns to the attract mode? Do we run something entirely different on each screen so there’s a reason to try both?

 Summary

A fun and challenging project that launched on-time and does pretty much what we set out to do. Can’t ask for more!

If you’re in the Twin Cities, please stop by and try out the new screens, and tweet us @walkerartcenter with feedback.

 

Digital Wayfinding in the Walker, Pt. 1

An ongoing conversation here at the Walker concerns the issue of systemic wayfinding within our spaces — certainly an important issue for an institution actively seeking attendance and public engagement, not to mention an institution whose building is literally a hybrid of the old and new (with our 2005 expansion). While not normally in New […]

An ongoing conversation here at the Walker concerns the issue of systemic wayfinding within our spaces — certainly an important issue for an institution actively seeking attendance and public engagement, not to mention an institution whose building is literally a hybrid of the old and new (with our 2005 expansion). While not normally in New Media’s purview, and only occasionally so for Design, a recent initiative to improve the flow and general satisfaction of visitors brought with it the idea of using digital displays, with their malleable content and powerful visual appeal, to guide and direct people throughout the Walker.

Our new static directional signage

Currently installed in one location of an eventual three, and with a simple “phase one” version of the content, the Bazinet Lobby monitor banks cycle through the title graphics for all the exhibitions currently on view, providing a mental checklist of sorts that allows the visitor to tally what he or she has or hasn’t yet seen that directly references the vinyl graphics at each gallery entrance. The corner conveniently works as an intersection for two hallways leading to a roughly equivalent number of galleries in either direction, one direction leading to our collection galleries in the Barnes tower, and the other our special exhibition galleries in the Herzog & de Meuron expansion. To this end, we’ve repurposed the “street sign” motif used on our new vinyl wall graphics to point either way (which also functions as a nice spacial divider). Each display tower cycles through it’s given exhibitions with a simple sliding transition, exposing the graphics one by one. An interesting side effect of this motion and the high-contrast LCDs has been the illusion of each tower being a ’70s-style mechanical lightbox; I’ve been tempted to supplement it with a soundtrack of quiet creaking.

The system, powered by Sedna Presenter and running on four headless, remotely-accessible Mac Minis directly behind the wall, affords us a lot of flexibility. While our normal exhibitions cycle is a looped After Effects composition, we’re also working on everything from decorative blasts of light and pattern (the screens are blindingly bright enough to bathe almost the entire lobby in color), to live-updating Twitter streams (during parties and special events), to severe weather and fire alerts (complete with a rather terrifying pulsating field of deep red). In fact, this same system is now even powering our pre-show cinema trailers. I’m particularly interested in connecting these to an Arduino’s environmental sensors that would allow us to dynamically change color, brightness, etc. based on everything from temperature to visitor count to time of day — look for more on that soon.

See it in action:

Behind the scenes / Severe weather alert:

 

Installation:

  

Building the Benches and Binoculars Touchscreen Kiosk

[flickrvideo]http://www.flickr.com/photos/vitaflo/4119139342/[/flickrvideo] 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 […]

[flickrvideo]http://www.flickr.com/photos/vitaflo/4119139342/[/flickrvideo]

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.

Walker Director Olga Viso using the Benches and Binoculars kiosk

Walker Director Olga Viso using the Benches and Binoculars kiosk

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?).

Using the Kiosk.

Using the Kiosk.

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:
http://www.flickr.com/photos/vitaflo/sets/72157622839288542/

Build a bridging firewall (cheap!)

New Media has a number of development servers located in-house where we get stuff done before releasing it out into the wild.  Until last week these were protected by an aging OpenBSD firewall running packet filter and all was well until midweek when the motherboard failed.  Not having a spare on hand, I was scrambling […]

New Media has a number of development servers located in-house where we get stuff done before releasing it out into the wild.  Until last week these were protected by an aging OpenBSD firewall running packet filter and all was well until midweek when the motherboard failed.  Not having a spare on hand, I was scrambling for a solution.

Linksys wireless router

Linksys wireless router

Being familiar with the dd-wrt project, I was pretty sure I could build a firewall out of a Linksys router.  We went with the WRT54GL, currently as cheap as $50 on Amazon.  (We bought local so we’d have it sooner, and it was a bit more).

The first step after flashing the firmware with the latest dd-wrt build (v24-sp2) was to take off the antennas and turn off the radio.  The last thing I want for the firewall is to be broadcasting an SSID and allow wireless associations.  This actually requires a startup script on the router, with a line to remove the wireless module so it won’t try to reenable itself:

wl radio off
wl down
rmmod wl

Good start.  Next I needed to bridge the WAN port with the LAN ports, which ended up being a struggle until I found the easy options in the dd-wrt GUI.  First, set the LAN to use a static IP and make sure you can connect via another machine to configure it.  You’ll also need to enable SSH access and remote configuration – but be sure to lock this down once the firewall is running!

Once you have the LAN configured, you need to set the WAN connection type to “disabled”.  This will give you a checkbox to bridge the LAN and WAN:  “Assign WAN port to switch”.  Lastly, under Advanced Routing set the Operating Mode to “Router” so it stops trying to do NAT.  Apply these settings, and you’ll basically have an expensive dumb switch – all traffic shows up on every port, and there’s no logic at all.  We’re halfway there.

Being unfamiliar with iptables (we use OpenBSD and pf for firewalls around here), I was under the impression that iptables rules would work in a bridging environment.  This is not the case: bridged packets don’t reach iptables at all!  The best I could do was block everything (manual restart needed), or otherwise blow up the configuration (manual restart needed) as I tried to mess with the bridge.  This was an incredibly frustrating learning curve as everything I could find made it sound like this was the way to configure a firewall in Linux, but it just wasn’t working.

Note to keep you sane: don’t do any of this testing in the startup scripts or you’ll brick your router, guaranteed.  Do it all from the command line with a known-good startup.  That way it’s a simple (but annoying) power cycle to get things back up.

The trick, it turns out, is a kernel module called ebtables.  Luckily, this is included in the dd-wrt build, but it’s not turned on by default!  Add this to your startup script:

insmod ebtables
insmod ebtable_filter
insmod ebt_ip.o

And, ta-da, all your iptables rules will start impacting packets!  Now it’s just a matter of configuring the firewall rules.  We’re using something like this:  (vlan0 represents the LAN ports, and vlan1 is the WAN port)

# drop everything by default:
iptables -P FORWARD DROP
# clear the old rules:
iptables -F FORWARD
# forward stuff that's established already
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# let connections out:
iptables -A FORWARD -i vlan0 -m state --state NEW -j ACCEPT

# firewall access rules
iptables -F INPUT
# WAC ips can get to fw:
iptables -A INPUT -p tcp -d 1.2.3.4 -s 4.3.2.1/24 -j ACCEPT
# drop everything else!
iptables -A INPUT -p tcp -d 1.2.3.4 -j DROP

# ... snipped all the actual access rules and packet flood protection ...

The only trick here is the last few lines which limit access to the firewall machine itself.  We can’t use the FORWARD rules since these packets are destined for the internal hardware and not forwarded, but we do need to limit access via the INPUT chain.  In this example the firewall has IP 1.2.3.4 and the network I want to access it from has 4.3.2.x.  That way I can leave the firewall’s remote access turned on and limit it to our network.  (because there’s no terminal access you can’t make it a truly transparent bridge or you’d never be able to change the config!)

I admit I’m a bit nervous posting some of this in case there’s a glaring security hole, but it seems good to me.  Anyone see anything they’d like to warn me about before we get hacked?

And there you have it!  For the cost of a cheap router and some time (not much, since you can just follow these notes!) you have a full-featured bridging firewall running on dedicated hardware.  With a little extra work it would be easy to get VPN running and much more…  I’m hoping for years of service from this little guy!

( Hat tip another DIY firewall solution that I’d really like to try someday. )

Installing a Lighttpd proxy

It had been a slow build, but an incident a few weeks ago made it finally clear: the Walker website was becoming a victim of its own success.  A post on the Teens site contained a picture of the Joker for the then-upcoming Batman movie, and as Halloween approached we found ourselves on the front […]

It had been a slow build, but an incident a few weeks ago made it finally clear: the Walker website was becoming a victim of its own success.  A post on the Teens site contained a picture of the Joker for the then-upcoming Batman movie, and as Halloween approached we found ourselves on the front page of Google image search as people began looking for costume ideas.  The exponential traffic was crippling our web server:

The biggest problem was simply that Apache is heavy.  It’s resource-intensive, especially when you are running several modules as we were – PHP, proxy, cache, etc.  The teens site is especially difficult since it runs as a combination of a blog (PHP on Apache 2) and .wac pages (mod_perl & Axkit).  Every hit to the Joker post – even if the page was cached – would tie up a number of Apache processes as it served the style sheets, images, and javascript to support the page.  We were reaching our MaxClients setting but unable to raise it without running out of memory for our other more intensive servers (mod_perl and postgres, I’m looking at you…).

As this diagram shows, it’s nothing but Apache servers, and it just wasn’t scaling to meet our current demand.

The approach was two-fold: some quick auditing and re-writing of the worst offending .wac pages’ SQL to speed up the slow pages, and yet another web server in front of everything.  It was a no brainer to pick Lighttpd, or “Lighty”.  It’s written to do one thing – serve static content – and do it extremely fast.  Fortunately it can also proxy requests, so it was a pretty simple matter to reassign some ports and write a few rules to route all requests through Lighty.

The end result is astonishing.  Our server hums along happily under even the most intense traffic we can throw at it (the email blast for the British Television Advertising Awards) and doesn’t even start to complain.  Moving the bulk of the requests to the extremely fast and resource-light server meant we could devote more resources to quickly processing the slow pages (mod_perl).  Between the SQL tuning and the extra resources, the bulk of these pages are now served between 2 and 10(!!!) times faster!

The lesson here, for anyone with an Apache server creaking and groaning under increased traffic, is to stop waiting and install Lighty.  If your site is PHP-based, you can run this as a fast CGI module from Lighty and do away with Apache altogether.  You can also use Lighty to stream (and “scrub”!) flv and mp4 video files.  (I’m using both of these techniques for the new ArtsConnectEd.)

The only caveat: be careful as you look for examples on the web.  Remarkably, it seems there are many confused webmasters who expect to see a performance boost by putting Lighty behind their struggling Apache.  This will not help at all, and in fact will probably make things worse.  Lighty has to be first in the chain to take the load off Apache.

Enjoy the speed!  I know our server is enjoying the breathing room!

Hacking the iPod Touch

Shelley Bernstein over at the Brooklyn Museum has posted some details on their recent hack of the iPod Touch to use in the gallery. Shelly hasn’t posted all the details on the blog, but if you contact her, she will be happy to link you up to the juice. If you’re looking to do something […]

Shelley Bernstein over at the Brooklyn Museum has posted some details on their recent hack of the iPod Touch to use in the gallery. Shelly hasn’t posted all the details on the blog, but if you contact her, she will be happy to link you up to the juice. If you’re looking to do something like this in a gallery, it’s a great head-start.

Photo by Shelly Bernstein

Photo by Shelly Bernstein

Using an iPod touch as a video display in a gallery is a really great idea for a number of reasons:

  • iPods are cheap (relatively).
  • The screens are offer a high resolution and an acceptable size.
  • They’re small and unobtrusive, so they have the potential to not irritate curators who dislike too much stuff near the art. 
  • The playback hardware is contained right in the unit, so no need for extra wires to a DVD player or other playback device.
  • They have WiFi, so there is potential for remote administration, updating, and connecting to content on the Net. 
  • If you get a first generation, they’re hackable. The second generation will probably be hackable soon. Thanks to things like Cydia, you can install SSH and all kinds of useful goodies.
  • The interface is simple. Though I’m not sure if my grandma would know how to interact with it. 

The only real downside to the IPod touch is the cord comes out a weird angle, making the mounting and display a little tricky.

Rock the Garden^h^h^h^h^h^h Webserver

The good news: about 8 million music lovers are simultaneously clicking on our email blast for information on Rock the Garden! The bad news: about 8 million music lovers are subsequently melting our server. I feel like I should drive out there and blow on it to help keep it from overheating, but I’m on […]

The good news: about 8 million music lovers are simultaneously clicking on our email blast for information on Rock the Garden!

The bad news: about 8 million music lovers are subsequently melting our server. I feel like I should drive out there and blow on it to help keep it from overheating, but I’m on my bike today and not up for the extra miles. So…

Dear music lovers,

I’m glad there’s so much interest in the show! I think it’s going to be great. But please, please, click slower!

Love,

Your frantic webmaster

Building a TV interface for YouTube using a mac and a browser

For the installation of Worlds Away, we needed to find a way to show the YouTube videos in the gallery. If you’ve visited the show, you’d see the videos installed in a Rec Room in the center of the gallery, complete with green shag carpeting, faux wood-gain paneling, low ceiling and bean bag chairs. It […]

YouTube on the TV

For the installation of Worlds Away, we needed to find a way to show the YouTube videos in the gallery. If you’ve visited the show, you’d see the videos installed in a Rec Room in the center of the gallery, complete with green shag carpeting, faux wood-gain paneling, low ceiling and bean bag chairs. It looks very much like my grandparent’s basement, minus the musty smell. The videos are viewable on a CRT television set on the floor in the corner of the room. I built a custom interface to allow people to control the TV, play the YouTube videos over the internet, at a decent quality, without violating the YouTube terms of service, and being mostly mischief-proof.

If you want to be spared the details, here’s a video:

[youtube]http://www.youtube.com/watch?v=6X7P9i9VMyE[/youtube]

Or, view it in a browser. This opens a pop-up window, Safari suggested, since that what it was built for. Use the left and right arrow keys, enter and escape to navigate.

When we started the project, we looked into ripping the flash video files from YouTube and creating a DVD. Testing showed the quality wasn’t great, but passable on a standard-def CRT television. The big hang-up about a DVD based approach was that it’s expressly forbidden in the YouTube terms of service:

You agree not to access User Submissions (defined below) or YouTube Content through any technology or means other than the video playback pages of the Website itself, the YouTube Embedable Player, or other explicitly authorized means YouTube may designate.

While it’s one thing to just avoid agreements like this with a wink and a nod for one-off or personal use, it didn’t seem like a good idea to blatantly violate the terms of service for an installation that would be in the gallery for months.

We also discussed setting up a computer in the gallery and simply putting a web page on it thin a custom player and view the videos. We weren’t too happy with that idea either, since it didn’t really fit within the Rec Room concept in the gallery — my grandparents don’t have a computer in the basement. We also discussed putting a big plasma TV on the wall, more like a modern TV, and using a remote or some sort of a pointing device to select videos using a custom YouTube player. Again, this option seemed costly (no spare plasma screens sitting around) and not within the theme of the room.

What we wanted was something kind of like the Apple TV, except limited to the 12 videos we selected for the exhibition. Quick research revealed no way to lock down an Apple TV or limit it to a particular YouTube playlist, so that was out. But what about making a web page that worked in a similar fashion?

It is possible to make Safari work in fullscreen mode using Saft. And there are applications that work with the Apple Remote to set up custom events and keystrokes. A computer with the right video card can also go out to a TV. And a little javascript magic in the browser could pull it all together with fancy fade and scroll effects.

jQuery and Safari fun

I started with the web page. I already knew I wanted to use jQuery for this project, if possible. I’ve been using MooTools for a while now and I wanted to expand my horizons to include a second Javascript library (half kidding). Using a TV screen for a display limits the usable resolution to 640×480, so there is not enough room to display all the entries on screen at once. Instead, I found the jCarousel plugin that I was able to use to scroll the video information across the screen. JCarousel has a lot of hooks for various events, so it made it quite easy to plug in to. The second thing I’d need was something to show the videos on screen once selected. The thickbox plugin is a lightbox clone, and seemed to do the trick. I tied it all together with some custom event hooks for keystrokes and a some logic to keep errant keystrokes from triggering multiple videos, excess scrolling, etc. In the end, I found that using the arrow keys and esc and enter are the best. In Safari, if you use any actual letter keys, it will default to type ahead find functionality and interfere with the scrolling offset.

The interface is designed explicitly for Safari. Since this is a single computer installation under our control, I don’t have to worry about whether or not it works in IE or Firefox. I have no idea if it works in IE (ignorance truly is bliss), but it only half-works in Firefox. Firefox doesn’t want to load the flash player in Thickbox. I’ve experienced problems with Firefox ignoring the z-index on Flash elements in the past, so this is not surprising.

Remote buddy

Remote BuddyNow that I had figured out how to deal with the browser, I had to figure out a way to have the remote interface with the browser by sending specific keystrokes for each button. After looking at several programs that do this with the Apple remote, I settled on Remote Buddy. It was the easiest to configure so that it would only work with specific applications. I configured it to send the left arrow key on left arrow press, right on right, enter on play and escape key on menu button press.

One problem with the remote was that our computer was an older mirror-door G4 tower, which does not have an infrared receiver. Thankfully, Remote Buddy supports third-party usb receivers, so I ordered one, and it worked like a charm. Microsoft does build good hardware.

Video out

Unfortunately, we weren’t able to track down a G4 that had S-video or composite out, so I also ordered a newer video card for that. We got an ATI Radeon 9200 which has an excellent control panel for TV-out settings, letting you manipulate all aspects of the size, stretch, overscan, etc.

Net connection

In this configuration, the videos stream in real time from YouTube’s servers. Our galleries have pretty good wireless saturation, and an airport card in this tower allows the machine to connect to the network. I spent some time looking into using Squid for caching the youtube videos, but it appears YouTube recently changed the way videos are embedded, using some sort of a time-based token in the URL, making caching difficult if not impossible. Another option would be to keep the videos loaded in the browser, but in a hidden element. However, since there’s no interface for controlling the YouTube embedded player with javascript, starting and stopping the player is not possible.

Putting it together

After connecting all these things, I cleaned up the interface a bit, changing the typeface to Avenir, choosing colors that worked better on the Television (don’t use white). I configured Safari to start in full-screen kiosk mode, which Saft enables. Safari and Remote Buddy were set to launch on login, and the machine is set to automatically log in. Additionally, I set up a simple shell script that checks each of them to make sure they’re running and if not, relaunches them. With relaunching the applications, it’s important to use the command-line version of Applescript, since that will cleanly deal with backgrounding the process and giving correct screen focus.

Doc Czypinski, who was the lead tech for installing the show, was able to figure out a way to glue a white plastic strip to the back of the remote. He was then able to cable the remotes to the gallery furniture so that they don’t walk away during the show.

Post-mortem

Now that the computer has been in the gallery for about a week, there are two things we’ve learned. First, visitors tend to expect things to be playing automatically on the TV, since that’s the way most media things are in galleries. When they do figure out they need to use the remote, they tend to click the big play button and not cycle through the videos to choose. I’ve attempted to help this by putting arrows on the screen to indicate left and right so that visitors know to use the arrows on the remote to scroll.

The second issue is that the wireless hasn’t been 100% reliable. As anyone who uses Wifi on a regular basis knows, it’s not always up 100% of the time, and the wifi in our gallery goes out once in a while. I’m looking at writing a script that will cycle the Airport card off and on if it looses connectivity, or displays a message on screen if there is extended connectivity loss. A wired connection would certainly be better, but the convenience of Wifi cannot be beaten.

Gallery photo by Cameron Wittig. Arm of Justin Heideman.

Building a Multiple iPod Charger

One of the cool things we’re doing for the Walker’s upcoming exhibition Picasso and American Art is significantly increasing our iPod audio tour capacity. For the exhibit we were able to get 25 iPod Video’s, and like our normal iPod audio tours, we will be letting visitors use them for free. The same content is […]

One of the cool things we’re doing for the Walker’s upcoming exhibition Picasso and American Art is significantly increasing our iPod audio tour capacity. For the exhibit we were able to get 25 iPod Video’s, and like our normal iPod audio tours, we will be letting visitors use them for free. The same content is also available on Art on Call.

This presents a bit of a challenge however. Up until now we’ve only had four iPod Nano’s to worry about, and plugging a few into a computer or two to charge isn’t that big a deal. Now however we have 25 of them to deal with, and there certainly aren’t enough USB ports to go around. The goal was to find a way to charge most of the iPods, do it in a limited space, and do it for as cheap as possible.

My solution was to buy three USB hubs and use them just for charging. We don’t really need to have them connected to the computer to sync with, we just want the power. This turned out to be harder than I thought. I went through a few USB hubs trying to get the iPods just to charge off the supplied AC adaptor. Each hub I tried didn’t allow this. It would only charge when the hub was connected to a computer via USB. I can’t fathom a reason why they limited it like this, as the power comes from AC on the hub, not from USB. Whether the hub was connected to a computer should not really dictate whether power could be supplied to the device or not. Alas, there was no cost efficient way around this.

So I had no choice, if I wanted to charge via any hub, I had to connect the hub to a computer. Thankfully we did have a computer near where our iPod storage is. Except it only has two open USB ports, not the three I needed. Another stumbling block. But then the thought occured to daisy chain the hubs. In essence, the USB cable that was supposed to go to the computer for each hub would plug into one of the other hubs instead. The last in the chain would then plug into the computer. Basically we could connect all of the iPods to a computer with one USB cord, regardless of how many hubs we had. And that’s what we did, as it worked perfectly:

One interesting feature of this is it allows us to mount all of these iPods at once, as you can see here. This actually makes adding and editing content on all of them a breeze. So in the end, perhaps all of the troubles were a blessing.

Total cost for this: $60. It may not look the prettiest, but sometimes when you’re trying to be frugal, getting something that just works is what counts.

Social networking for hardware

We Make Money Not Art has an interview with Burak Arikan up, who is the lead developer of OpenIO and Pinkie. Prior to reading the interview, I had no idea what either were, but they sound very cool, like most things that come out of the Media Lab: Pinkie is a network based electronics prototyping […]

We Make Money Not Art has an interview with Burak Arikan up, who is the lead developer of OpenIO and Pinkie. Prior to reading the interview, I had no idea what either were, but they sound very cool, like most things that come out of the Media Lab:

Pinkie is a network based electronics prototyping board. Pinkie has been designed to easily compose sensors and actuators that reside in different locations. Pinkies are inherently invisible, they hide behind the structures and only serve as facilitators to interface the physical world to the digital network.

Open I/O works like a peer-to-peer file sharing program, rather then sharing media files in your PC, you share data sensed from your physical environment. While Pinkies are organizing the low-level information (e.g., sensing the world), Open I/O is for higher concepts such as managing distributed devices, collaboration, and social networking.

This sounds to be a very interesting project. It seems like the floodgates are starting to open on small hardware devices that are open and easily programmable. Since there are so many of these devices, it seems only natural that they need social networking.

Next