The Big Decision: What Happened
As everything began to die down over the weekend, I was told by lots of people that I should “post the graphs somewhere” so I could “show them off”. I wasn’t in the mood to be showing off what I’d perceived as a catastrophic failure, but given a little time and state-sanctioned university vacation period, here I am. Welcome to how not to run an election night.
Before
The Graphs
Those who know me will have known my enthusiasm for this project long in advance. This was in part fuelled by last year’s results (“Ben and Larissa…tied!”) and the graphs produced there, and also by my IM921 Visualisation module this year where I was studying data visualisation and creating effective graphics.
During the first few weeks of term 2, I drew up concepts and researched graph styles. Bars, doughnuts, parliaments, arc diagrams, circular bars, animated graphs, you name it, I probably looked at it and discounted it for some reason.
After various meetings with lecturers, a lot of coding and decisions later, I arrived at the final code for the graphs, written in R, and the final format. I explained this in the less-technical video here and article here. The idea was to create two graphs that combine the ease of understanding of the bar graph with the huge amount of information I could convey in a Sankey diagram, explained in pretty much the same way as I’d done the year before. Around this time too, The Economist published an article with an excellent Sankey that I’d recommend if you’re looking for something slightly more polished.
The code itself worked perfectly, for a number of reasons:
- The .csv files we receive from the SU are standardised, which made importing the data into R very easy.
- There was a clear process of import the code, create the bar graph, test for a majority, create the Sankey if needed.
- A number of parameters used to make the graphs easier to read were clearly marked and separated
- Changing the code for each race only involved changing one parameter
However, one key obstacle remained that I couldn’t code out.
The bar graph was made in ggplot2, a simple package that I could write all of the code out for beforehand, and the code could be run quickly and easily. The same applied to the majority test.
The Sankey diagram, on the other hand, was significantly more difficult. The diagram itself could be coded beforehand, however the source data could not. It requires two dataframes - tables - Nodes and Flows.
Nodes identifies each point in the diagram, so in our case there is a node for each candidate in each round they’re included in, along with the non-transferable differences (NTD). The code for the diagram is written in Javascript, so each node has a zero-indexed id number.
Flows is the most difficult frame to put together. This details every single flow of votes, for candidates progressing to the next round and eliminated candidates seeing their votes redistributed. The correct numbers of votes have to go to the correct nodes for the diagram to make sense.
The group columns indicate the colours for each flow and node.
Both had to be inputted manually. I had to look at the result sheet, type in each vote count in each round, and work out who it was going from and to, in the knowledge that if anything was incorrect it’d be obvious on the diagrams. This was frantic, and also difficult to explain. It would take up the majority of my time on the night.
The Exit Poll
This was another idea I’d had- run an exit poll through a Google Form, try to analyse the data and see if we could call any races. It was designed so we’d only collect first preferences and thus only project obvious winners. I’d been looking at the data all week, but also knew about obvious biases in who might be filling it out (we caught at least one targeted campaign attempting to submit numerous identical votes). On the night, I decided we were calling four of the races- Sports, Societies, Education, and President. Three were correct, the fourth the narrowest race of the entire evening. It was an experiment, and I’d love to see it integrated further in future events.
The Presenting
When I’ve presented the results on stage each of these past two years, I’ve had the trusty RAW News iPad with me. In 2019 I’d written out what to say myself (so to the person who asked me if I knew who’d won, yes I did), but this year I didn’t have the time since I’d be making the graphs. So we had other members of the team writing out what I’d say, with all of us having access to a secure drive with the results on once we’d received them. Additionally, we were asked to provide analysis for the part-time races this year- Lucy & Johnny were given cards with the results on for this purpose.
During
6:00pm: Have dinner at the duck, tidy myself up, prepare for everything. Have a look at the exit poll data and see what we might be able to project.
6:30pm: Final discussions with everyone involved with graphing and presenting, drafting a statement of who we were prepared to project as winners based on the exit poll.
7:00pm: Polls close, exit poll result published. Waiting for results to be processed begins.
7:10pm: Waiting.
7:20pm: Decide to get a pint of diet coke in.
7:30pm: Still waiting.
7:35pm: Results files arrive. I put the files on our secure drive so we can all access them, then look at the full-time races to see how many Sankey networks I have to make.
7:36pm: Pro: I only have 4 to make. Con: I have about 30 minutes in which to make them. Begin frantically making the nodes and flows dataframes on the fire escape stairs.
7:40pm: I am a ball of stress. Near enough screaming to find the presenters and tell them the results.
8:00pm: The event starts.
8:05pm: The event actually starts. The part-time officer roles go without a hitch. Astonishingly, one of the team has finished nearly all the bar graphs already.
8:25pm: I’m done. Each graph is finished and uploaded to its correct place on the drive. I throw my laptop onto the sofa in the green room and pick up the news department tablet, finding that the results have all been typed out for me- all I need to do is present them.
8:30pm (ish): I go up on stage to present the first analysis. It’s the Sports Officer race and Charlotte’s won it in the first round. There’s one graph and it couldn’t be simpler. I begin to speak. Something seems a little off, I turn around to look at my graph…
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
The Incident
A lot of the evening was then defined by The Incident.
I had completed and labelled every graph correctly, and put them in the correct folders on our secure drive. A technical fault in the gallery meant that the incorrect graph, the first-round DDO bar graph, had been displayed behind me. This is pretty atrocious, for a number of reasons:
- It spoils the DDO result, even if a winner wasn’t clear it is obvious who’s ahead and who’s not
- It makes the room unsettled and unable to focus on any later results
- It jeopardises the wellbeing of the candidates- they are all taken elsewhere to be told the result just before it is announced in the Duck
- It overshadows the election that’s just been won, and the candidate that won it
- It makes us look awfully incompetent
8:31pm: I continue to stare at the graph, watching as nearly 2 months’ worth of work is going to be remembered for one fault. The crowd are cheering. I’m unable to communicate with the gallery thanks to last-minute staging changes leaving me on the wrong side of the stage to my talkback equipment.
I’m snapped out of it by a member of SU staff shouting “Do something!” across the stage. It’s a fair comment. Despite the fact nobody can see the numbers behind what I’m saying, I wrap up and hand over to Lucy, before racing into the green room to work out what on earth just happened.
8:35pm: Unsurprisingly, chaos. I’m told rumours that SU staff want to remove all the graphs from the broadcast (and effectively, me), simply announce the results and end early, or abandon the event altogether. These don’t help.
8:40pm: We complete the Societies race without a hitch, before we are told to pause the broadcast and event by the SU. They are not happy.
8:50pm: We resume, and with extra checks and balances in the gallery, switch up the running order so the DDO race is next. It’s an absolute mess to try and present, for two reasons- to speed up the process I didn’t colour the Sankey diagram in properly since for the number of candidates it would have been much more difficult, and secondly the number of candidates makes the diagram so difficult to read anyway. It’s no surprise that when it appears cries of “What?” go up from the crowd, and once I muddle through I end up mispronouncing the winner’s name (I’m still sorry Akosua) too. I walk off and don’t really want to continue at this point.
9:00pm: I get told to continue and the remaining races pass without too much of a problem.
10:00pm: It ends. Heavy drinking (of more diet coke). Pretty much gone silent, sat on the sofa in the green room, and assuming I’ve been cancelled at this point.
10:35pm: Get on a U1, go back to Leam.
After
The Graphs
Here are my favourites.
Looking critically at these graphs;
The Bars
- The names take up too much of the plot area, making the actual graph less useful.
- The numbers, while large, simply make you perform the kind of processing that would be achieved by a table.
- There’s no distinction between the candidates- to know who’s in the lead, you have to read.
The Sankeys
- The layout is confusing on all of them, not least the DDO race where nothing’s coloured in
- The names could easily be larger
- The order makes little sense and the flows are difficult to notice
- If you’ve never seen one of these before, odds are you’ve no idea what’s going on. In visualisation, I’d call this a complete lack of “pre-attentive processing”, where it’s impossible to tell what the visualisation is showing before you actually begin to read it.
In response;
- Displaying names is a difficult one. First names probably work, but this would involve coding them manually, which adds time and a (proven) error-prone human, whereas here we just import the names directly from the results sheet. (Time)
- It’s a consequence of the small plot area that I decided to add the numbers. In essence this was one problem (names) that led to another problem (plot area) that led to another (big numbers). The order can still be easily inferred. (Design)
- Colour schemes are a tricky one. Previously the bars have all been the same, and I didn’t want to change that, it would have required more code. However for the Sankey diagrams colours were unavoidable- the default setting is used for speed. (Design)
- I will admit the layout of the diagrams is heavily confusing. I tried to mitigate against this with the video we put out here, but nowhere near enough people had seen it. You have to read to work out who each colour refers to. (Design)
- The order makes no sense because I simply didn’t have time to manually arrange the nodes. The nice ones arranged in this article were tailored by me in plenty of time. While I attempted to correctly order the flows so the code would naturally output what I wanted it to, in the heat of the moment this didn’t happen. (Time)
Moving forwards
There are two main responses I’ve used- time and design. Time is exogenous to us, since we’ve no control over when we get the results. It is, however, an incredibly small window in which we’re expected to produce broadcast-quality graphics that can also be understood by the audience in the Duck.
I’m going to argue that Design is endogenous, in that it was influenced by the timescale. My evidence is this;
This visualisation of the results is perfect. A clear brand identity supports an animated graph that adjusts for each round of voting, introducing a threshold that changes with each round. The non-transferable votes aren’t mentioned, but maybe that’s a good thing. I adore this.
In York, voting closes at 12pm on the Friday, before the Results Night on Saturday. That’s over 24 hours to work with the results to create a visualisation, test it, and make sure it works.
I had 25 minutes.
The two graph system conveys as much information as it can while taking as little time as possible to process between receiving the results and presenting them. For the situation presented to me, where last-minute changes can completely upset the flow of a broadcast, it was the perfect compromise of a solution.
Would I use it again? Absolutely not. I’d spend a year making what YSTV used instead.
