Event Storytelling Challenges

Event-result storytelling is a challenge that arose mid-project. While some large data projects may be able to predict their sub-challenges from the get-go, the more common response in my experience is to allow those challenges to emerge as teams work. Many are simply not apparent during the higher-level planning, despite a team’s best intentions in planning or expertise.

My focus here is we how covered event results, which is an essential yet small part of a full-fledged Olympics project. I draw strongly from The New York Times’ project experience from London’s Summer Games in 2012. Here I can only summarize major technology questions like where we got the data and how we parsed it, as well as the technical challenges of running a high-traffic section of the website for the duration of the Games.

To arrive where we could focus on specific events’ stories, we had to work through a series of key questions:

• Which audiences do we focus on?
• How do audiences “read” results?
• How do we show the right competition format?
• How fancy could results get anyway?
• How do we balance standardizing versus customizing?
• And (in the end) did our audience justify our hard work?

My examples come from The New York Times, yet I expect any website offering Olympics updates ran into similar challenges. Just event results alone magnify rather quickly: the Summer Games comprised 14 days, 39 sports, 304 events and 7,233 separate competitions. The upcoming Sochi Winter Games in 2014 will comprise 9 days, 9 sports, 98 events and 1,386 competitions. For each competition we needed to show the correct results and how they came about. There’s little room for error.

Your Audience == Your Audiences, and they Read Differently

The audience for the Summer Games ranged from a massive number of what I think about as “casual fans” who are curious about the statistics in a general way to a tiny but ardent segment of “mega-fans” who know a particular sport inside out. While it makes sense that the mega-fans have the highest expectations, we determined we couldn’t take casual fans’ interest lightly. We figured out mid-stream in the design and build process that we needed more insight into the expectations of each type of fan in order to make our event results helpful. We didn’t have time for formal research, so we improvised in the most rigourous way we could. We gave our own experiences as fans a thorough examination and came up with a working sense of what each would expect.

Casual fans learned to expect a lot in watching TV coverage from Olympiad to Olympiad. They are Olympics watchers—not necessarily sport fans—who like the Olympics storylines, ceremonies and tune in to the TV broadcast. They know a good deal a bit about scoring, competition rules and how a competitor bested another for a medal. They probably expect information about world records or personal bests, too. Those are more detailed expectations than you might expect casual Olympics watchers to have.

Mega-fans, on the other hand, are people who follow the sport outside of the Olympics, know their national teams and athletes as well as all the rules and history. They know how competition formats and rules make otherwise obscure data plain as day. They expect accurate reporting for minutae like disqualifications marks, tie-breakers, points accumulation, and as much as you can give them, actually.

Casual fans and mega-fans share a few fundamental expectations: accuracy and timeliness, the competitors and how the final results compare between the competitors. Without them, neither audience would find the information they sought and we’d be doing a pretty poor job covering the Games. Beyond that, we needed to consider the differences in each fan-type’s expectations. To understand an event from both groups’ perspectives, we drew on our team’s collective Olympic-watching experience which within our group comprised both casual and mega fans.

Summaries and Full Results

Summarizing event results started with the medals—who won gold, silver and bronze. Next on a fan’s mind (we extrapolated) would be times/scores then the appropriate flags/countries. Getting those fundamentals in place set us up for event-specific customizations (more on that in a bit).

Iterating on designs and early front-end coding samples, we coalesced around two types of event results: summary and full. Summary results took the form of medals won, flag, athlete/country and score.

Summary results for teams and individuals

The summary result unit appeared in a variety of places in our overall site designs: sidebar widgets, schedules, daily summaries, embedded within articles, etc. They provided a consistent “pulse” of the Games day-to-day wherever they appeared. As such, they needed to be skimmable so readers could rely on them wherever they might ask wonder things like: what events just happenend, what’s coming up next, when did the qualifying rounds happen and which countries are winning the most medals.

Full results is where the larger storytelling challenge arose. For full resuls we needed to show all the competitors and how they advanced (or not) though the phases leading to the medals.

Sample full results

Aside: Where did we get all that data? The Olympics technical support staff collected and organized a vast amount of data for each venue, sport, event and individual competition. They republished it to partnered news organizations as a giant feed that abstractly details how one competitor beat another. They also sent massive lists of all the competitors, their bios (including hobbies), all the participating countries, historic/world records, venues, specialized codes for everything and more.

We could rely on the fact the Olympics organizers could not afford to have each sport running its own unique competition format and schedule. To fit everything into a sane schedule, they shoehorned events into a few basic competitive formats that enforce simple patterns in how competitors advance. One of the best-known competition formats is the classic bracket playoff, where 64 (or more) athletes or teams winnow down to 32, then to sixteen, then eight, then four and lastly the final two. Another common variation and Olympic format is pool play followed by a bracket, used in team tournaments like basketball, volleyball and soccer.

A typical bracket

Another frequently used format is a head-to-head competition for events like Track & Field or Swimming where all the final competitors compete as one big group. There may have been qualifying rounds to thin out the field but all the top athletes/teams in the finals start at once. The best three(ish) get medals.

The fourth—at least for the major Olympics formats—is cumulative results, where a competitor’s score from one phase follows him or her into the second. Gymnastics does this for both Individual and Team events, albeit with quite a few quirks.

Competition Formats

Showing an event’s results means understanding not only its competition format but also its rules. Event rules added a layer to the competition format rules and—frankly—meant exceptions to our fundamental designs and coding patterns. Rapid prototyping and experimentation proved we needed consistent, bullet-proof table markup. The event-specific rules gave us clear cases for overrides to show more complex <table> structures.

As we studied the rules we realized we needed to be ready to explain:

• ties or tie-breaker scenarios
• disqualifications
• penalties or faults that count against points
• double-elimination formats (e.g., a loser’s bracket)
• sport-specific scoring standards (like Tennis’ unique scoring vocab)
• whether multiple medals are awarded
• …and more.

As we studied U.S.-centric major events (then expanded to include internationally popular events) we needed to show custom layouts where we could. That gave us clear guidance about our front-end coding patterns.

How Fancy?

How fancy could we get? Answer: very.

“Fancy” results vs simple results (inset)

While final scores are the only marks that matter for medaling, we needed to explain how those final marks came about. More than a few of our competitors went with a simple factual route, like the sample below. We felt that was the letter of the law though missing perhaps the competitive spirit.

Lackluster results for Men’s Long Jump on ESPN

We wanted do better. At worst, our casual fans could learn a bit more about the competition than who medaled. If we did a particularly good job, mega-fans might think we’ve represented the rules and competition in a smart way.

Men’s Long Jump, which aims to show that only the furthest successful attempt counts

Working through the sports and schedule, we added data that conveyed a much better story about the competition. Starting with a flexible, semantic table markup patterns, we built “helper” tools that supported intricate row/column structures. And somewhat surprisingly—yet proving the power of clear, semantic markup—our table structures grew more complex while the CSS stayed fairly lightweight. (I’ll share some of our front-end code patterns in an upcoming section.)

The Olympic Data Feed provided clear pointers for the competition formats in their XML. We mapped all the Summer Games events to their competition formats. With test data (the Beijing summer games’ results) we could see enough to test how well we showed the rules.

Balancing Standardizing and Customizing

First we made sure the competitive format worked for well-known events like Basketball, Soccer, Track & Field and Swimming. Track & Field and Swimming both included a wide variety of events, from sprints to team relays, where the final time doesn’t tell the full story. For Relays, the most interesting data is each competitor’s split within the total. So we got to work on the event-specific customizations, which were old-school <table> markup: colspans, rowspans and sub-markup within table cells.

Staying out the coding weeds, it helps to see how we generated different degrees of markup complexity for our result tables.

Markup for bare-bones table results

<%= result_table_for(unit) do |table| %>
    <%= table.caption(unit) %>
        <thead>
            <tr>
                <%= table.rank_header %>
                <%= table.competitor_header %>
                <%= table.result_header %>
            </tr>
        </thead>
        <tbody>
            <% table.create_rows do |row| %>
                <%= row.rank %>     
                <%= row.competitor %>  
                <%= row.result %>   
            <% end %>
        </tbody>
    <%= table.footer_row(:colspan => 3) %>
<% end %>

Resulting display for bare-bones table

Markup for a more complex result (Gymnastics Individual Vaulting)

<%= result_table_for(unit, :with_stages => true) do |table| %>
    <%= table.caption(unit, :double_header => true) %>
        <thead>
            <tr>
                <%= table.rank_header(:rowspan => "2") %>
                <%= table.competitor_header(nil, :rowspan => "2") %>
                <% vaults.each do |vault| %>
                    <%= table.header("#{column_header :vault} #{vault}", :colspan => 3) %>
                <% end %>
                <%= table.result_header(nil, :rowspan => "2") %>
            </tr>
            <tr class="sub-head">
                <%= table.header(column_header(:difficulty)) %>
                <%= table.header(column_header(:execution)) %>
                <%= table.header(column_header(:penalty), :class => "segment penalty") %>
                <%= table.header(column_header(:difficulty)) %>
                <%= table.header(column_header(:execution)) %>
                <%= table.header(column_header(:penalty), :class => "segment penalty") %>
            </tr>
        </thead>
        <tbody>
            <% table.create_rows do |row| %>
                <%= row.rank %>
                <%= row.competitor %>
                <% vaults.each do |vault| %>
                    <%= row.result(vault.extensions.diff) %>
                    <%= row.result(vault.extensions.exec) %>
                    <%= row.result(penalty, :classes => ["segment penalty"]) %>
                <% end %>
                <%= row.result %>
            <% end %>
        </tbody>
    <%= table.footer_row(:colspan => "9") %>
<% end %>

Resulting display for a complex table

In addition to custom structure, the sub-information in cells proved to be little challenges in their own right. For sports we knew little about as a team, building more elaborate markup helped us wrap our heads around the competition rules.

Our last effort—which really reflected data journalists having a bit too much fun and not enough sleep—was to try to meet or exceed Wikipedia’s event summaries, which seem to operate for posterity once the Olympics mothball their websites. In studying the Wikipedia volunteer team’s efforts, we hoped our rather nerdy layouts might contribute to event result standards on the web. Perhaps during the next Summer Games, fans might remember our notation and engage a bit more with unfamiliar events.

Keeping up with Wikipedia: our table for the Women’s Pole Vault, where athletes can pass on some heights to save their allotted attempts

Did Audience Engagement Justify Our Hard Work?

The powers-that-be are still considering the question, frankly. We learned a lot and devised clever, reuseable tools and business strategies. And we have to evaluate the audience reading patterns we saw for the New York Times readership, who are our core responsibility. One of our partners was the CBC in Canada—their readers were different from ours and offer their own lessons. Needless to say, discussions and meetings abound.

One clear fact is that event results can’t be half-right or half-told. Whatever our Olympics coverage evolves to include, the summary and full event storytelling challenges remain the same. With Sochi 2014 development work already in progress, we face a Winter Games only 1/3rd the size of a Summer Games. It gives us some room to experiment and refine our approaches.

No doubt we’ll be revisiting these problem sets and new ones for Brazil 2016! (Anyone want to try to wedge multi-day cricket matches into a bracket over a 17-day Summer Games schedule?)

The Takeaway

The scale of the Olympics is a long-cycle challenge for data journalists. Breaking it into small storytelling units and customization options mirrors more common problems, however. While we focused on variations of HTML tables, the problem set could just as likely have been telling detailed stories in charts, graphs or maps.

Due to the size and complexity of some projects—such as the New York Times’s Olympics work—you can get caught up in overplanning and advanced preparation. It can be very helpful, and sometimes essential, to let lessons emerge as you work. Continually asking ourselves if our audience conceptions were correct helped affirm early assumptions and refine them. And, most importantly, it kept the user experience foremost in our priorities while juggling many other concerns.

Similar UX storytelling challenges can be approached by:

• determining the low and high expectations from your audience(s)
• building the fundamentals first, then explore intricacies and edge-cases
• grouping your data set by major themes helps identify those edge-cases more quickly
• thinking of each element as a small, unique story keeps the user’s experience front-of-mind for the team
• being prepared to adapt to new insights along the way in the development process

Following these problem-tackling steps helps you both shape your team shape data into smarter patterns and maintains a high awareness of your audience reading and understanding it.

About the Author

Tiff Fehr is a web developer in the awesome Interactive News group at The New York Times and is still fairly surprised by the latter fact.