How we created the best online voting test

How we created the best online voting test
… and amazed ourselves

When the University of Antwerp in participation with Treecompany asked Wieni to develop the “Stemtest” (political online voting test) we instantly knew we didn’t want to build this in Drupal, like we do for most of our sites. At that time, we were experimenting with Backbone.js. This new project seemed like the perfect opportunity to gain some hands-on experience . We had to expect about six million submissions in one month, with peaks up to 15.000 users at the same time. This meant that we had to reevaluate the way we store data, and determine if we could minimize its retrieval or even avoid it altogether.

What is this test?

The “Stemtest” is an online test made for Belgian citizens to find out with which political party they share the most common ground by answering around 36 questions. This year we covered the European, national and regional elections. The latter consisting of the Flemish, Walloon and Brussels-capital region. Each of these regions were assigned a different set of questions which in turn were related to different political parties. To make matters worse it had to be implemented for different key partners, like the national radio, television and some national papers from the Flemish and Walloon region. You had 3 options to choose from when you were answering the questions: agree, disagree and no opinion (with a certain limit for the latter).

Make everybody happy

Today we have smartphones with high resolution screens, so a perfectly responsive website with high resolution images and assets was needed. We rallied our best and brightest JavaScript developer and our magical frontend developer into one room, which from then on would become better known as ‘the war room’ (yes, we added a cool logo on the door). The design and user interface had to be perfect. Especially the part where, after finishing the test, you could change some of your answers to see the effect on your result.

Gulp for president

We didn’t want to use any PHP in the front, so we used Gulp to create index.html files for all the different versions we needed. Gulp also added all the uglified JavaScript inline and compressed our 6 images. We do mean ALL the JavaScript, once you had the initial page load of 419kb you could finish the entire test. This included all the questions, all the logic to change and compare questions and to share your result. Please note that the lazy-loaded ‘Add This’ used for sharing on Facebook, Twitter and email took a whopping 48% (204kb) of our total filesize.

Share it!

The University of Antwerp wanted to store all the answers (anonymously) for research purposes. As you can see in an early schematic above, we did send all the data to a simple PHP script which in turn saved it in a table (one for each test/version). When a user altered his initial answer we concatenated any subsequent answers to the initial answer-string for that specific question. We didn’t want to wait for a response from the server. This had a nice upside: if the backend went down, nobody would notice (it didn’t go down by the way, kudos to Stone Internet Services). (More technical: this opened up the possibility of serving the static application from nginx servers which would remain unaffected by any load on the PHP script).

As stated earlier, we were trying to minimize any server-side load. Retrieving the raw user input from the server and recalculating the scores seemed overkill for a shared result page. Therefore we embedded the result into the share url.

The part after ‘resultaat’ (result) was a complicated obfuscation of your results. For example party 1: 10%, party 2: 34%, etcetera … No backend needed, neat!

Be prepared for everything

The biggest advantage of not using any server side code for the tests was of course the load Stone could handle with their CDN. Stone did an extensive load test to monitor everything in advance. When the national television did a piece about it in prime time we had our first real peak (damn what a night). Stone sent us an email: “they didn’t have any CPU load above 4%-5%”.

On a final note: be creative, from the start we did anticipate a huge load, so we designed everything around this. In the end, we did succeed, this is one of our best projects we did this year.

ps: some versions of Safari 6 don’t sort the object properties like Chrome V8 sorts them (according to the order they were inserted), We learned this the hard way.

This blog was originally posted on checkthis.

Published by

Hans Vanderstraeten

Technical director of Wieni. Also known as Mokit.