Home Services Projects Our Team The Lab Blog Contact Jobs

The Challenge

To work on a project with partners like the National Portrait Gallery, Mozilla and the Speakers Art Fund is a fantastic honour. But to create a digital art project for artist Jon Adams to be used as part of Parliament’s celebrations of the 800th anniversary of the sealing of the Magna Carta was just phenomenal.

Read on to see how we built a mobile web application, merged a number of disparate data sources and created an interactive mapping system to help create a digital art project for Parliament.

The Brief

We were approached by local Artist Jon Adams to work alongside the Houses of Parliament and Arts Council England to design and build an interactive map-based application.

The app would allow anyone in the UK to discover the history of the people behind the names of their local streets, and how those people contributed to democracy. Discovered streets were saved to a database and displayed in real time on a map of the UK. The idea is that Jon will draw inspiration from patterns in the data being formed to produce a final offline piece of artwork to be hung in Parliament to celebrate the 800th anniversary of the sealing of the Magna Carta.

democracy street mobile website

Out and about with Democracy Street discovering important figures in our political history and contributing this to the digital arts project.

Making sense of the data

We knew we could get street names from the wonderful community-driven mapping project OpenStreetMap, but how would we tie these to the names behind the streets? The Houses of Parliament provided us with different databases of potential people of interest. These were in various formats and structures and the first task was to write code to parse these files, find similarities and create a unified database of “people of interest”. We could then use this new database to match people to streets.

Why a web app?

The final digital medium for this project was open ended, it could be a desktop app, a website, a native mobile app, whichever allowed the most amount of people to interact with the project.

The most important thing was to create as few barriers in the user experience as possible. We wanted as many people to access the app and interact with it in a meaningful way. It is after all a community-driven digital arts project.

“We build once and it works across multiple platforms, no significant additional costs or development time.”

The decision for us was easy. If we built a mobile web app we could open the doors to everyone with any brand of smart device; Windows, Android, iPhone, iPad, Desktop, Laptop or even their TV. With a single step to visit a web address they could begin interacting, no visiting of individual app stores, typing in passwords, waiting for download and then finally launching. We build once and it works across multiple platforms, no significant additional costs or development time. The other big advantage of web apps is the ability to immediately push updates to the app without waiting weeks for the App Store controllers to approve the update before it’s available to download.

A project focused around user experience

Over the course of the project we undertook a collection of UX practices. As the idea and concept was original, we didn’t have to deal with any legacy site architecture. Therefore, we were able to define this when working closely with the team at the Houses of Parliament. During the discovery phase, user flows were defined to help determine the various journeys and interactions the mobile version would contain. This encouraged thought around the gamification element and how the end user would easily access information about the important key figures of political history.

Interactive prototypes were created during both the wireframing and visual design stage to help distinguish any breaks in flow or general sticking points. These prototypes were then used in demonstrations with everyday users to gain initial feedback. Towards the end of the project, full Alpha and Beta test periods were conducted with experience surveys completed each time the product was tested. This provided further insight from the end user, allowing an iterative approach during the project cycle.

wireframes and user flows

User Flows created to replicate the journey users would take when using the mobile web app.

Why a separate desktop and mobile version?

The desktop and mobile version are very different. The mobile version allows people to find streets around them, earn badges, and upload photos to help contribute to the final art piece. The desktop site allows people without a smart device to watch mobile users perform these actions in real time, whilst still being able to read about the people of interest from any discovered street so far.

“Think of the mobile app as the pencil, and the desktop as the paper”
Jon Adams

The real time connection between the mobile and desktop versions adds a great dynamic knowing that your contributions can be seen by others, and that your experience is shared with thousands watching on their desktops at that very moment.

The desktop version is a great feature that continues to expand on the idea of allowing as many people as possible to interact with this digital arts project.

democracy street desktop website

Badges and maximising contribution

In order to give Jon as much data as possible to help patterns emerge on the map we’d have to create incentives to keep users interacting with the app and discovering as many streets as possible. In a world with so many distractions vying for the user’s attention, we knew we needed to bring some gamification to the project to keep people discovering those last few streets on their list! Nine foursquare-esque badges were created, each with varying difficulty to achieve and after you had collected them all you would be able claim a Mozilla Open Badge accredited by the Arts Council of England.

After discovering a street, users are encouraged to take and upload a photo which will be available for desktop users to see.

The tech

The entire project from the front-end to the back-end is built with Javascript. The back-end is powered by Nodejs and Socketio allowing real time websocket connections with the user’s browser. This real time connection allows us to keep the flow of the data almost instant between all mobile and desktop users creating a fluid and collaborative experience.

Keeping with the open and community-driven ethos of Democracy Street we chose OpenStreetMap and Leafletjs for our mapping solution instead of turning to Google Maps as we normally would. All of OpenStreetMap’s data is free to contribute to, download and use as you please. It’s a fantastic project and will no doubt power future mapping applications we build.

Load balancing and real time connections

This was a very high profile project, with articles in the Guardian and Wired before we’d launched we had to prepare for a huge amount of visitors over the next few months.

We are used to handling large amounts of traffic, hosting websites for large companies such as The Cooperative, Hastings, AA, and even our own internal lab project Sid. Our normal web servers are all load balanced meaning we distribute the load across multiple servers rather than overloading a single machine with all the traffic.

Despite this, Democracy Street was a real time application, and very different from a normal website. The way traffic is sent in most websites is like a polite conversation, your browser asks the server for some data, the server responds with what you asked for. In a real time (websocket) environment, the browser and the server are both shouting over each other at the same time, and neither waits for a response from the other before continuing.

This is a chaotic type of communication that requires a special way of handling the traffic; the server which first started the conversation with the user must continue to talk to that same user. This is called sticky sessions and provides some order to the chaos. We first looked to Amazon web services which provide a load balancer that can distribute TCP connections, unfortunately they don’t support sticky sessions for this type of traffic yet so we were forced to create our own using HAProxy. We created several Node.js servers that sit behind this load balancer, each ready to handle the potential onslaught of traffic.

In Summary

It’s not often you get to build a real-time mapping app to form part of a digital arts project with partners like the National Portrait Gallery and Parliament. We are fantastically proud of being able to work on a such an amazing project. You can read some of the press coverage on the project in the fine publications above.