Cleaning up after activists occupy Tate Modern’s Turbine Hall. June 2015.

Graphical Integrity in Data Visualisations

This infographic, highlighting quirks of the UK voting system, recently popped up in my Twitter feed. Whilst the accompanying article makes some valid points, the graphic is rather inaccurate.

Infographic of forecast votes-to-seats for Ukip, Lib Dems, Greens, and SNP

Firstly, it uses circles (of two dimensions) to represent one-dimensional data. Edward Tufte discusses this in The Visual Display of Quantitative Information:

There are considerable ambiguities in how people perceive a two-dimensional surface and then convert that perception into a one-dimensional number. Changes in physical area on the surface of a graphic do not reliably produce appropriately proportional changes in perceived areas.

In this instance, the designer has varied the radius/diameter of the circles, which results in a surface area that exaggerates the data. For example, compare the circles for the Green Party and the SNP. If the Green Party circle represents 1 unit-squared, then you’d expect the SNP’s circle to be 56 units-squared. Instead, it is 3136 units-squared—56-times greater than it should be.

Secondly, it encourages comparisons between values on different scales: percentage of votes, and number of seats.

The graphic gives the impression that the Lib Dems gain considerably from the voting system: 8% votes → 26 seats. 26 seats actually represents just 4% of the total seats (650), so their votes are effectively halved! This distortion is also observed when comparing the Lib Dems’ “votes” circle to the SNP’s “seats” circle. The SNP’s 56 seats (8.61%) should be comparable to the Lib Dems votes (8%). It isn’t.

Infographic of forecast votes-to-seats for Ukip, Lib Dems, Greens, and SNP, highlighting inaccuracies
Annotated graphic highlighting distortions. The dark blue circle shows how big the SNP’s circle would be if areas were proportionate.

What’s more, there is a second graphic (not re-published here), making the same votes-to-seats comparisons but with the Labour, Conservative, and Ukip parties. However, this is on a different scale to the previous one, making any further comparisons impossible.

It would be more accurate to make comparisons based on percentages of seats, and include all the data in a single graphic. Perhaps a simple table would suffice?

The following table attempts to convey how much each party is set to gain/lose because of the voting system based on the forecast. A ratio greater than 1 indicates that a party gains from the system; ratio less than 1 indicates that a party loses from the system.

Party % of Votes % of Seats Ratio
% Seats / % Votes
Labour 33 42.31 1.28
Conservatives 31 40.92 1.32
Ukip 15 0.62 0.04
Lib Dems 8 4.00 0.50
Green 7 0.15 0.02
SNP 4 8.62 2.15

Ratios can be transformed into “Advantages” by taking logarithms: positive values indicate gain, negative values indicate loss.

Party % of Votes % of Seats Advantage
log2(% Seats / % Votes)
Labour 33 42.31 0.36
Conservatives 31 40.92 0.40
Ukip 15 0.62 -4.61
Lib Dems 8 4.00 -1.00
Green 7 0.15 -5.51
SNP 4 8.62 1.11

From these tables we can deduce that:

  • Labour and the Conservatives are set to gain a little from the voting system
  • The SNP would gain as much proportionally as the Lib Dems lose: the voting system effectively doubles the SNP’s seats, and halves the Lib Dems’
  • Ukip and the Greens are set to lose out the most, significantly more than any other loses or gains

Got feedback? Email me: christiedom@gmail.com

Emergency Use Only


London, August 2014

David Heinemeier Hansson on Ambition

It might sound funny, but I’m not a very ambitious person. When it comes to software and products, I have a very low bar in terms of ambition level. I feel like there is so much stuff that is so poor, where the things you have to do to improve, just have to be just a little bit better.

David Heinemeier Hansson Jellyvision Q&A with DHH & Jason Fried


The gift of attention is perhaps the most valuable. Attention may seem like an easy gift to give, but it is not; it is the scarcest resource available because its quantities are limited and nonrenewable. We can’t produce more attention, and there are ever more things vying for it each day.

Frank Chimero The Shape of Design

The Not-So-Straight & The Not-So-Perfect

The not-so-straight and the not-so-perfect is the lovely thing of life. And there’s somebody out there trying to make the world straight and perfect…When the world will be straight and perfect in their eyes, will that be straight and perfect, or will it be worse?

Analogue People in a Digital Age Twopair Films

Aphex Twin on Smartphones

I don’t have any phones. They’re just not good for anything. They’re handy for loads of stuff, but I can’t think of anything that’s better because you’ve got them. I think there’s a risk of people becoming zombies with Facebook and social media. It’s really awful, that side of things.

Aphex Twin ‘Syro’

Barcelona 2014

14-08_2117_lomo-lca_kodak-colorplus-200_13.jpg 14-08_2117_lomo-lca_kodak-colorplus-200_05.jpg 14-08_2117_lomo-lca_kodak-colorplus-200_35.jpg 14-08_2116_olympus-mju-ii_kodak-gold-200_20.jpg 14-08_2117_lomo-lca_kodak-colorplus-200_09.jpg 14-08_2117_lomo-lca_kodak-colorplus-200_32.jpg

More photos in the Barcelona 2014 set.

Preferences in User Interface Design

Jef Raskin on “Modes, User-Preference Settings, and Temporary Modes”, in The Humane Interface:

Facilities for setting user preferences constitute an example of modes and are a major source of frustration. Ironically, these features are usually touted as a benefit. Present user interfaces are often so difficult to use that a user may feel an urge to rearrange them. Microsoft specifically recommends that such facilities be provided: “Users, because of their widely varying skills and preferences, must be able to personalize aspects of their interface … such as color, fonts, or other options.” [from Microsoft’s Windows Interface Guidelines, 1995]

… By providing preferences, we burden users with a task extraneous to their job function. … Time spent in learning and operating the personalization features is time mostly wasted from the task at hand.

… Customization sounds nice, democratic, open-ended, and full of freedom and joy for the user, but I am unaware of any studies that show that it increases productivity or improves objective measures of usability or learnability. Adding customization certainly makes a system more complex and more difficult to learn. I suspect that if you were to take a user survey, more people than not would be in favor of lots of personalizable features … [but as] has been observed in a number of experiments, an interface that optimizes productivity is not necessarily an interface that optimises subjective ratings.”

See also: Avoid Preferences from Getting Real.

(I’m looking at you, Slack)

Array Controllers in Ember.js

An array controller is a wrapper for a collection of objects, and provides convenient methods for dealing with its contents.

An array controller’s model is typically set in a route, for example:

App.IndexRoute = Ember.Route.extend({
  model: function() {
    return [
      {name: 'red'},
      {name: 'yellow'},
      {name: 'blue'}
// (The Index ArrayController is setup implicitly)

Setting an array controller’s model sets up its content property, which forms the basis for other properties and methods.


arrangedContent is an important property, defined as “the array that the [array controller] pretends to be”. It provides a way for sorted/filtered content to be stored separately from the original content. In this way, sorting/filtering is not destructive, and the content (in its original form) can still be retrieved.

By default, when an array controller has no sortProperties, arrangedContent and content are the same. When sortProperties are added, the sorted content is stored in arrangedContent whilst the original content remains untouched.

It’s important to note that an array controller should be treated just like an array, with its items referencing those in arrangedContent. Accessing items on an array controller itself, is effectively the same as accessing items in arrangedContent (an important difference is discussed in below).

This is best illustrated with some examples. Given the route above, the following #each loops all result in the same output:

index template:

{{#each}} {{name}} {{/each}}

{{#each content}} {{name}} {{/each}}

{{#each arrangedContent}} {{name}} {{/each}}

Setting sortProperties results in sorted output from arrangedProperty and therefore from the array controller instance itself:

App.IndexController = Ember.ArrayController.extend({
  sortProperties: ['name']

index template:

{{!-- Sorted by name --}}
{{#each}} …

{{!-- Not Sorted --}}
{{#each content}} …

{{!-- Sorted by name --}}
{{#each arrangedContent}} …

Item Controllers

Adding an itemController property to an array controller wraps each item in an instance of the referenced controller. However, this only applies when accessing items through the array controller instance itself. Items accessed via arrangedContent or content remain unwrapped. This is the key difference when accessing items via arrangedContent versus accessing them via the array controller instance itself.

The following example demonstrates this concept:

App.IndexController = Ember.ArrayController.extend({
  itemController: 'color'

App.ColorController = Ember.ObjectController.extend({
  isActive: true

index template:

{{!-- Names rendered --}}
  {{#if isActive}} {{name}} {{/if}}

{{!-- Nothing rendered --}}
{{#each content}}
  {{#if isActive}} {{name}} {{/if}}

{{!-- Nothing rendered --}}
{{#each arrangedContent}}
  {{#if isActive}} {{name}} {{/if}}

Nothing is rendered in the loops that iterate over content or arrangedContent because the items are not wrapped in an item controller and therefore isActive is inaccessible.

{{#each itemController='…'}}

{{#each}} helpers, when supplied with an itemController property, wrap each item in a new instance of the referenced controller. This operates entirely independently from the itemController property on an array controller: an array controller will not have access to any item controller created via an {{#each}} helper.

This becomes particularly important when implementing a computed property on an array controller that depends on properties on an item controller. See the example.

For more information:

View more posts in the archive