MozFest 2013: If it ain't broke, break it — how and why to test your news site

Moments following the Boston Marathon bombings, the Boston Globe's website shut down due to excessive traffic. And it stayed down. For hours. Suddenly, the state's most prominent news provider was no longer an information resource for arguably the state's most newsworthy event in years.

As Dan Sinker, head of the Knight-Mozilla OpenNews project, and speaker at this year's MozFest so eloquently put it: this is a really stupid problem to have.

Sinker teamed with Dylan Richard, former director of engineering for President Barack Obama's Obama for America Technology team, to discuss how, why and what we can learn from a news website's server going down — otherwise known as failure — and potential solutions for dealing with the issue.

To start, the best way to avoid failure is to prepare for it. Basically, this involves baking in the ability for something to stop working in an application, because seeing how things break, or what failure actually looks like (think: the dreaded 404 error message), allows the site's backend team to amass a playbook on how to handle potential unexpected issues (Richard calls them "game days").

It's collective muscle memory on how to fix things.

Richard explained that he and his team performed these game days by shutting off subsequent databases at random for 12 hours straight. What this does is test the server's resiliency, which, while time consuming, is necessary to protect against problems that may be outside the realm of their control, such as a hacker infiltration or natural disasters.

The two then posed three questions to the room in front of them: What are the specific ways a site goes about simulating failure? What does that failure look like? And what can be learned from such incidences?

First, how to simulate failure? I thought first about cutting off email and phone communication, but suggestions from the group included intentionally slowing down or turning off the site's database, turning off its cache and simulating traffic.

Secondly, what failure looks like, in many cases, can be missing widgets or other integral portions of the page or the aforementioned 404. While a larger publication like the Globe isn't likely to lose users over a broken server here or there, I imagine the negative consequences on a smaller, less-established site could be far more significant.

One person in the workshop recommended rectifying the situation by providing a "helpful" error message that explicitly explains to the user why they can't view the content, or, better yet, placing the actual article in plain text on the 404 page itself.

The benefits of performing game days are plentiful. A company can define how they communicate with users in the worst-case scenarios (a solution here would be to direct them to another resource they've created, such as a Tumblr blog), determine the quality of its documentation, who its core users are — i.e. who's complaining the loudest — and, perhaps most important of all, how to fail gracefully.

As someone who may be (re)entering a newsroom environment in the near future, I feel these are the types of discussions that can help improve communication between companies' often segregated tech and reporting teams.

With knowledge of how user traffic and failure scenarios work, journalists can remain informed, which beats the more typical alternative of an exasperated plea to "fix it" without understanding the process behind the problem.

Latest Posts

  • With the 25th CAR Conference upon us, let’s recall the first oneWhen the Web was young, data journalism pioneers gathered in Raleigh

    For a few days in October 1993, if you were interested in journalism and technology, Raleigh, North Carolina was the place you had to be. The first Computer-Assisted Reporting Conference offered by Investigative Reporters & Editors brought more than 400 journalists to Raleigh for 3½ days of panels, demos and hands-on lessons in how to use computers to find stories in data. That seminal event will be commemorated this week at the 25th CAR Conference, which...

    Continue Reading

  • Prototyping Augmented Reality

    Something that really frustrates me is that, while I’m excited about the potential AR has for storytelling, I don’t feel like I have really great AR experiences that I can point people to. We know that AR is great for taking a selfie with a Pikachu and it’s pretty good at measuring spaces (as long as your room is really well lit and your phone is fully charged) but beyond that, we’re really still figuring...

    Continue Reading

  • Capturing the Soundfield: Recording Ambisonics for VR

    When building experiences in virtual reality we’re confronted with the challenge of mimicking how sounds hit us in the real world from all directions. One useful tool for us to attempt this mimicry is called a soundfield microphone. We tested one of these microphones to explore how audio plays into building immersive experiences for virtual reality. Approaching ambisonics with the soundfield microphone has become popular in development for VR particularly for 360 videos. With it,...

    Continue Reading

  • Prototyping Spatial Audio for Movement Art

    One of Oscillations’ technical goals for this quarter’s Knight Lab Studio class was an exploration of spatial audio. Spatial audio is sound that exists in three dimensions. It is a perfect complement to 360 video, because sound sources can be localized to certain parts of the video. Oscillations is especially interested in using spatial audio to enhance the neuroscientific principles of audiovisual synchrony that they aim to emphasize in their productions. Existing work in spatial......

    Continue Reading

  • Oscillations Audience Engagement Research Findings

    During the Winter 2018 quarter, the Oscillations Knight Lab team was tasked in exploring the question: what constitutes an engaging live movement arts performance for audiences? Oscillations’ Chief Technology Officer, Ilya Fomin, told the team at quarter’s start that the startup aims to create performing arts experiences that are “better than reality.” In response, our team spent the quarter seeking to understand what is reality with qualitative research. Three members of the team interviewed more......

    Continue Reading

  • How to translate live-spoken human words into computer “truth”

    Our Knight Lab team spent three months in Winter 2018 exploring how to combine various technologies to capture, interpret, and fact check live broadcasts from television news stations, using Amazon’s Alexa personal assistant device as a low-friction way to initiate the process. The ultimate goal was to build an Alexa skill that could be its own form of live, automated fact-checking: cross-referencing a statement from a politician or otherwise newsworthy figure against previously fact-checked statements......

    Continue Reading

Storytelling Tools

We build easy-to-use tools that can help you tell better stories.

View More