In my previous article I covered the setup of the Duckbox — our latest project, a digital jukebox at the recently opened Duck and Rice in Soho, London. This time I’m going to talk specifically about the screen showing what’s currently playing on the Duckbox. It’s a HTML5 based Google Chrome app, running on a display just behind the bar of The Duck and Rice.

The idea goes back to two themes often found in British pubs — the clock on the wall and the three flying ducks. Our goal was to interpret these creatively in the final display and create the first version of hopefully many more different to come.

Besides these creative constraints, we outlined the technical requirements of the application:

Display animation and the current track information

Run fullscreen

Launch automatically on startup

Access audio-input to allow animations to be sound-reactive

Works offline in case of loss of Internet connectivity

Easy to update

What are the Options?

Media installations like this are often built using so called toolkits for creative coding. Among the most common ones are Cinder, OpenFrameworks and Processing. Aimed at visual arts, prototyping as well as teaching how to program they look to reduce the coding and let you focus on the creative instead. They can be very powerful and many excellent projects have been created using them. During the past few years my work involved every single one of the above at some point, usually in collaboration with specialised developers.

However, it’s left me with mixed feelings. Too often the results suffered from memory leaks, crashes and good old freezing. More importantly, it’s been incredibly hard to find good developers.

Luckily, over the past few years, we’ve seen a great evolution of both capabilities and software development standards in web development. Furthermore there’s a great pool of developers to choose from when it comes to web technologies.

This matters for the Duckbox display not only for the development process. Once launched, these kind of projects usually don’t receive much further support. Going for web technologies is the best way to make it relatively easy for somebody else to pick it up if need be.

There’re still good reasons to use Cinder, OpenFrameworks et al as they make great use of GPU acceleration and can outperform web depending on what you’re trying to create.

That One!

Settled on HTML5 there was still the question how to distribute the app without rolling out our own deployment system. Running the app off a web server would not go well with connection drop outs. So it quickly boiled down to a packaged web app running locally. This left us with two options.

Both share similar ideas, essentially allowing to install and run web apps in a native environment. This gives them the option to get special permissions to access data and hardware a normal web app wouldn’t be allowed to touch.

Since these permissions requests are specified in a so-called manifest file they only have to be granted once. This is great in our case for using the audio input as it won’t need any further user attention, unlike a typical website which would request permission every time a user visits it.