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.
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.
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”
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.
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.
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.