As you probably know we, at Moodstocks, are fond of hackathons could it be as a sponsor (fresh beers or whatever!), platform provider or participants! That is why we could not have missed this Hack The Elections Paris-based hackathon organized by Voxe -World’s Platform for Politics, last week-end at Le Camping!
Participants – made of developers, designers and citizens, were asked to leverage the Voxe data API and build a smart app aiming at helping people choose their candidate the clever way for the French presidential election, 2012.
On my own I had no predefined idea at pitch time. Keeping in mind the smartphone explosion I started brainstorming around 2 simple facts:
- • there is a huge amount of political propositions among the set of candidates: at the time of writing Voxe references 1500+ propositions. This makes it hard for many of us to take time to read, understand and get an opinion on them,
- • on a daily basis, until the election D-day, we will go through the candidate official posters as we will commute to work – and this could really act as a kind of daily reminder.
So I thought it would be great if I could be provided with a random proposition each time I encounter the poster of a candidate – think of it as a kind of one proposition a day. And it would be cool too if I could record at that time if I agree or disagree with this precise proposition: from day to day, cumulating these small votes would lead to a good evaluation of what is my real favorite candidate!
Such a concept was an ideal use case to leverage both Voxe and Moodstocks plaftorms since:
- • Voxe provides all the required data via its API from candidates’ propositions (of course) to topics and avatars,
- • the Moodstocks SDK is able to identify any candidate poster via the smartphone camera and makes it possible to display related content (here a random proposition) and actions (here vote buttons) directly in overlay of the video capture.
I then found a name for the app – Voxometre, a few fords to depict it – my very own citizen remote control, and started the technical design & implementation focusing on the iOS platform.
To me such an application had to follow the serverless programming principle (i.e. full client-side app) since:
- • the app has no sharing or social features: each small vote made on the random propositions is personal and has to be stored directly on the client. There is no need to centralize this data on the server-side,
- • it is a mashup app that consumes all its data from external APIs,
- • it is important that the app keeps its data available locally to maximize the user experience via real-time interactions at scanning time (i.e. zero network latency to fetch the data).
So the main topics I had to focus on were:
- • generating the pre-defined data and assets: I have written some scripts to pre-fetch the data that will not change from Voxe API (candidacy IDs, candidate names, avatars, main tags, etc) and embed these PNG-s and custom JSON directly within the app,
- • designing the data synchronization phase: the goal was to trigger at cold start the Moodstocks sync (to retrieve the image signatures) and write some logic to fetch and store the whole set of propositions by calling the search propositions by candidacyID HTTP API provided by Voxe,
- • choosing an embedded database and defining the data model: since we need to store and persist the set of propositions plus the votes made by the end user on the client, I had to use an embedded database. To make sure things were fun enough (!) I decided to use Redisk – the not-so-stable-nor-production-ready Redis-API-compatible embedded database written in C I had co-created with Pierre at the former Hack Day Paris hackathon last november,
- • implementing the overlay made of the proposition & related tag (as info) plus the votes up / down buttons (as actions).
Being able to use a Redis-like API on the client-side was pretty handy since it offers simple and convenient data structures to achieve our job. Below is an overview of the (very) simple data model:
Propositions values are stored in raw JSON even if we could have used Redis hashes to store them unserialized. The key format allows to easily find a random proposition by filtering the set of propositions for a candidate via key forward matching.
A set is used to record every proposition that has been voted.
At last the INCR command is used to bump the votes counters per candidate.
Then it was time to style the app! I worked with Aymeric that did a great job at choosing a color theme, designing a logo, creating styled buttons and producing a keynote for the final presentation (feel free to browse these slides for some more details and screenshots).
Stay tuned until the next April, 3rd since we will present the project for this Mash Up Birthday event!
[UPDATE] We have now a landing page!