It's 2015 and we still can't reliably run screens

Barely a day goes by when I don’t spot a broken screen somewhere in London. I find it incredible that this still happens so much. We can deploy and operate infrastructure better than ever before, but we still struggle to keep a screen displaying a slideshow or a dashboard up and running.

A short while ago, Matt Webb and I spent some time looking at this problem within the context of government. The GDS office has tons of screens, and central government must have thousands, displaying performance data, meeting room bookings, or promotional material. Across wider government, there must be tens of thousands: in job centres, driving test centres, at the border, and elsewhere.

Usually, each screen is run by a standalone computer at best - or expensive specialist hardware at worst - and we only know if it goes down if someone spots the screen is off (and knows how to fix it). Even if the screen’s on, we can’t be sure that there isn’t a software update dialog blocking the screen, if the screen saver’s kicked in, or whether the device is still connected to the internet at all.

Displaying screens feels like something that should be provided by commodity technology already. Given your dashboard or display is hosted somewhere on the internet, it should be really damn easy to get a device which boots up out-of-the-box into a web browser, discovers what it should show, and pings a monitoring service to let it know its online.

In lieu of such a thing appearing to exist, we decided to prototype one. Matt’s been doing a broader piece of work into how IoT concepts could be used in government, and it appeared a good fit. We used some Raspberry Pis and a clever online service called Resin, which allows you to easily deploy containerised applications across a fleet of small devices. I built an online service for the devices to talk to, and a web-based control panel where you can configure each screen and see which ones are online.

Given an SD card with the Resin base image, a new Raspberry Pi will start up, install our custom client application, run Chromium and then appear in the control panel ready to be configured (pictured above). A user can then choose where they want to point the screen to, and it will update automatically.

We had a bunch of problems with wifi, and some performance issues when we tried some of our more-animated performance dashboards, but it feels like there’s definitely potential here to be explored.

I’ve posted the source code for our client app and web service prototypes on GitHub. I’m not sure what’s happening next with the idea, but there’s a few people at GDS interested in taking it forward. I’d also love to find out where others have tried to solve this problem.