Cut To The Chase – the prototype, trials, taxis, and tapas

Not only did we each get a nice warm hoodie for winning the Glasgow #newsHACK #EditorsLab hackathon event in May 2014, the FT team was offered a paid trip to the Global Editors Network #EditorsLab hackathon final in June, in Barcelona, along with the winners of all the other GEN #EditorsLab regional hackathons. So we went, and this is how we did and how we did it.

If the following is tl;dr, you can skip to the hack itself, or the slides of the presentation.

The theme for the hackathon final

announced a week before the start,

Making the Most of Video

From live streaming to video aggregation, short news clips to documentary storytelling… the options for digital news videos are rapidly growing as are the opportunities.

  • Video, audio, images, and text are difficult to harmonize. How can we reconcile them to create new forms of storytelling?
  • Digital videos are more and more consumed on mobile devices. How can Newsrooms optimize their video content for a more engaged user experience?
  • User-generated video content is booming. How can Newsrooms take advantage of it, in particular around real-time events and breaking news situations?

We had a couple of mostly inconclusive throw-ideas-around chats, considering games, tools for the creation of videos, MOOC-like educational extras, fretting about passive viewers, etc, before sort-of settling on a means for showing time-poor viewers where the ‘action’ was in a video.

layer over the video

  • which talking head is winning
  • when is the important point (UGC hit spacebar)
  • show timeline of key activity
  • thumbs up/down in each corner
  • fast clip mode
    • just show me the interesting bits

We also established early on that Cardiff Garcia gave good video.

Day 0

The event rules limited teams to three bodies/roles, comprising Journalist, Designer, and (if we must) Developer. So, three of the original four-strong Glasgow team flew out:

Amie Tsang, Chris Gathercole, Rik Still

We took the bus rather than the taxi from Barcelona airport because of the international anti-Uber strike.

At the venue, we speed-geeked (awkward but worthwhile, a quick-fire face-to-face with all the other teams). We hit the tapas. We retired late for an early start.

Day 1

The day began with blank sheets of paper, 3 colours of Sharpies, and a mournful look at the glorious weather outside. Thoughts turned to finishing by lunch and hitting the beach.

The day also began with plugging in a 3-way UK plug adaptor and so had no running-out-of-UK-power-sockets worries at all, unlike the team behind us <smug mode=”on”/>.

Since no-one had had a better idea in the meanwhile, we were still on for the “show me where the action is” idea.

We discussed which types of FT videos we might use, considering the main types to be:

talking heads, talking charts, roving reporter.

Developer started working on creating a layer over a youtube video, hard-coding in some made-up stats, deciding on D3 as the graphing tool. Init’ing a local git repo, and pushing updates to an offisite remote repo (always assume the laptop and/or wifi could fail at the worst moment).

Journalist looked for good videos on the FT site.

Designer wielded the Sharpies, and fretted about having no scarf.

The first ‘big’ decision: what kind of chart/display to show the users’ voting pattern? After much arguing, we decided it best to implement something simple, doesn’t really matter what, and a basic bar chart would be it. Even so, having to calculate how many pixels per bar per second of video took Developer far outside their comfort zone.

In parallel, Journalist and Designer argued back and forth about the best way of displaying the two pieces of time-based data, how many yes’ and how many no’s.  A simple two-line graph showed each one clearly, sharing the same axes, but did not highlight when there lots of both at the same time. Colouring in the overlap looked nice, but didn’t help. There was an “over my dead body” reaction to the idea of a stacked area chart from Journalist. More on this later.

We have an in-house tool, Bertha, which makes it very easy to quickly knock up some editable configs for an app: put some values into a google spreadsheet, publish  it, and you have a cached JSON feed. The spreadsheet gives us very basic CMS-esque functionality: access control, change log, edit screen. All in all, ideal for a hackathon.

Journalist settled on a video, a talking chart, with Cardiff Garcia giving it some hands.

In studying the video, looking for the main point(s) of interest, some made-up opinions around points in the video:

  • High point of contention:  1:36 rising college costs are a big deal and mean young people put off being “adults”, along til  2:02
  • Another point of contention: Around 3:25 – you wouldn’t have done anything differently if you were in the same position.

Journalist described how the video was easily broken down into logical sections, and that process in fact already happens during the creation of the video, so we could consider having access to the logical sections when we displayed the video. This fit very well with the activity chart idea, and was in fact one of the ideas raised during the ‘mostly inconclusive throw-ideas-around chats’ from a few days ago. Instant, unanimous agreement.

We decided on tabs, lined up beneath the chart of voting activity. Minutes later, another JSON feed, and now the pressure was fully on Developer.

So, inevitably, “why not add more content to the tabs?” (result: a new column, panelblurb), then a big designer-y question, “what colour should the tabs be?”

We have an in-house initiative, called Origami, an under-construction registry of front end modules, services, fonts, colours, icons, etc, for the FT site.  Designer picked a few colours from the palette, seemingly at random, but surely there were years of experience behind this carefree selection? The spreadsheet and thus JSON feed updated accordingly with new columns, segmentcolorhash and segmentcolorname.

The day continued with frustrations about

  • how to config/control the youtube video via its API
    • increasingly resorting to horrendous hackery, transparent layers blocking access to controls and the like
  • how to build a particular chart using D3
  • syncing the tabs with the progress of the video

Assorted decisions/assumptions which emerged during the day

  • the stacked bar chart idea gained traction, as we began to conclude that (a) the sum of the votes was more important than whether there were more yes than no, and (b) the side-by-side bar chart lines were too thin and would not be very visible when projected during the presentation.
    • at some point, we switched from blue and red to green and red
  • we stick with two voting options, yes/no, or good/bad, and then fret about their semantics
  • the placement of the user voting buttons was tricky, a design challenge in fact!, and needed to go over the video itself
  • we need to disable all default youtube controls, but retain the progress bar (otherwise we’d have to build our own)
  • voting is aggregated to the second, ditto tabs start/stop times are in seconds
  • working title for the hack was “The Money Shot”. Initially bullish about it, and with enthusiasm from neighbouring teams, confidence in the wisdom of this choice began to wane.

Our first major “where are we and what is left?” session.

Next steps

  • read dynamically from Bertha JSON
    • create a 2 spreadsheets per video
    • only later do we create a video → spreadsheet map sheet
  • different presentation of bar chart
    • adding dual barsmaybe later moving averages?
    • maybe going withD3 stacked bar chart: http://bl.ocks.org/mbostock/3886208
    • perhaps https://gist.github.com/anotherjavadude/2940908
  • cartoonified for demo
    • “hell yeah/no” icon when user makes a choice
      • thumbs up: http://registry.origami.ft.com/components/o-ft-icons@1.2.2 recommended-reads
      • thumbs down: flip image?
    • buttons styley
  • panels basics
  • brand the page
    • buttons (play , stop)
  • deploy to heroku
    • and then betafeature. For Later
  • interact directly with youtube buttons
  • handle 2+ videos. For Later.
  • panels extra stuff
    • comments. Romulans
    • contextual reading.
  • tidy ups
    • fix buttons
    • fix the colors
    • fix the auto-open panel
    • fix the title

We had high hopes of

  • making the hackathon app apply-able to all FT youtube videos
    • and therefore create a separate backend service to serve the video configs and collate the user voting
  • integrating the live commenting platform into each tab
  • integrating the app as a live site-wide betafeature

More dev. More prepping of the presentation.

The first proper deployment to heroku. Yay. Tangible progress. It turns out that Developer has in fact been doing something awesome.

We can now all see the hack in action: http://ft-barcelona-hackday.herokuapp.com/

A big temptation to break for the evening, for food and an organised tour of La Pedrera. Very nice.

Day 2: the final push


An earlier start.
Journalist more “I’m not a morning person”      (than usual).
Developer forgot their badge.
Nice weather. Again. Sunnies out.

Next steps (ported from Day 1)

  • brand the page
    • buttons (play , stop)
  • interact directly with youtube buttons
  • panels extra stuff
    • comments.
    • contextual reading.
  • tidy ups
    • fix buttons
    • fix the colors
    • fix the auto-open panel
    • fix the title
  • deploy latest to heroku

Swingeing cuts to scope and ambition. This will be for one video, but will work nicely to get the gist across, no live commenting integration, no site-wide betafeature.

A moment of light relief when Journalist, frustrated with the inability to start a tab between the spoken words rather than breaking a word, wonders if we couldn’t switch to millisecond resolution. Developer and Designer share a knowing chuckle. Not a chance. Journalist takes it personally.

2pm deadline approaches. Designer switches focus to the presentation. Turns out Journalist has been putting together an awesome presentation all this time.

Final dev steps

for presentation

  • our own controls
  • blanking out all youtube controls
    • transparent overlay
  • buttons
  • rounded corners
  • font sizes
  • boldening

Hack title is now “Cut To The Chase”.

Hack details emailed to organiser.

2pm. Pens down. Fingers up. Hackery is over

And relax. No, don’t relax. Start rehearsing/tailoring the presentation. We have 4 mins in which to pitch the idea and the technicalities. We are warned by the organiser “don’t get too technical”.

Do a quick practice on the presentation laptop. Argh. Bl@#dy youtube ads where before there were none, and not switch-off-able because of the transparent layer bodge. Well, that means we do need to use Developer’s laptop for the demo, like we’d promised we wouldn’t. Each team plugging in their own laptop for their presentation always goes well. Never any Mac-what-screen-size-does-anyone-have-an-adaptor-no-not-that-one-the-new-one issues.

Judges are herded from table to table to hear the details of each hack direct from the horses’ mouths, so to speak, asking questions, before the formal stand up and present happens. This is a good idea, IMHO, since it means that the judges have a much better chance of understanding what each hack is about before the under-stress presentations. And particularly for this collection of teams from across the globe, with many having to give their presentation in a foreign tongue. Much kudos to them.

Presentations begin. We are on 2nd. Gets it over with early. Much better than being on tenterhooks all the way through the other 15 presentations.

We make our pitch. Journalist wows them with a confident performance. Designer wraps up with some technicalities (but not too many). Developer drives the slides and the working demo via laptop.

Some questions. And sit back down. That’s it. Alea iacta est. We can now enjoy the other teams’ presentations.

Casual scouting during the earlier canapes had revealed the team from Argentina were working on a hack which sounded the most similar to ours, so we had them marked as our main competitor. However, it turned out one of the Times teams had played a blinder with a completely different approach that played perfectly into the target audience, a room full of Editorial types. Plus a Sepp Blatter pratfall on an infinite loop. What’s not to like?

The three finalists were announced:

  • the Dublin event winners    (The Times)
  • the Glasgow event winners (us, the FT)
  • the Polish event winners     (Wirtualna Polska)

After some confusion that also turned out to be the actual final result too. The Times (Dublin team) had won, and we were second.

Well done team: some development awesomeness, and potent journalistic writing and presentation.

All in all a jolly enjoyable event, and lots of lovely people.

So what have we learned?

about organising hackathons

  • speed-geeking is painful but beneficial: being forced to meet and actually talk with *every* other team before the event started meant the whole event was more sociable that it might otherwise have been.
  • good food makes people happy
  • so does good weather but, if it is too good, it makes them sad
  • the judges meet-the-teams walkabout before the formal presentations leads to better judging

about participating in a hackathon

  • for a hack, start small and extend
  • using an unfamiliar technology for the first time (in our case, D3) during a hackathon is a recipe for stress
  • it is worth moving to a dynamic source of config ASAP, i.e. not-hard-coding config into one dev’s code. It saves on one bit of dev (refactoring from hard-coded to dynamic), and means the rest of the team can dabble and fiddle with the config in parallel with Developer developing.
  • start with a git repo from the very first moment, with a remote/offsite instance as the means of sharing code and disaster recovery.
  • designing is all about confidence, plus criticising whatever anybody else suggests

about presenting your hack

  • it all comes down to the presentation. Doesn’t matter how good the idea is, or how clever the implementation, you’ve only got 4mins to get it across.
  • be thinking of how you will present the hack from the start, even before you’ve started the actual hacking.
  • speak slowly
  • what worked on one laptop in one corner of the room will probably not work on another laptop in a different corner of the room
  • a Sepp Blatter pratfall on infinite loop is hard to beat

Leave a Reply

Your email address will not be published. Required fields are marked *