Coding your product out in the open is fairly standard operating procedure for tech startups. It’s not something that typically seeps through the legacy cultural barriers and dwindling budgets of the newsroom at a 193-year-old newspaper. Yet that’s just what’s been happening at The Guardian.
Borrowing from the open source ethos long beloved in engineering circles, The Guardian launched a new responsive site that was built via a public GitHub repo and with a steady of flow of feedback from thousands of readers. It may sound like a bunch of hype, but their approach has real-world benefits that other publishers could learn from.
“Open is the guiding philosophy at the Guardian, so developing our new site in the open was a logical step for us,” says The Guardian’s lead software developer Patrick Hamann. “It also allows us to share the knowledge we have gained in the process externally and to learn from other organizations and developers, as well as from our readers.”
The design itself meets the standard criteria for a news site redesign: Faster page loads, a modular content framework and a responsive layout that–crucially in this evolving industry–accommodates new types of ad units. As our cohorts at Co.Design put it, “The Guardian’s new design joins the rest of us here in 2014.” But the benefits of using an open process are the same as they are for anybody else: Distributing the workload, learning from the community and ensuring high standards in quality and security.
“Using GitHub has enabled us to promote internal and external visibility on new feature development and to utilize a fast feedback mechanism,” says Hamann. “The peer reviewing process like ‘pull requests’ also facilitates a much higher quality of code.”
Allowing outsiders to contribute code and offer feedback on designs made it considerably easier to hire the new talent to work on the project internally. What better way to find developers than by letting them contribute code to your company’s most important project as it unfolds?
The impact was even more pronounced on the design side. “The project has literally changed the way our design department has had to work,” Hamann. “No longer is design a service, but is now innate within our product development teams. Designing in the open like this has been a revelation.”
Building the new site wasn’t without its challenges and, as you might imagine, many of them were design-related. As anyone who’s ever been involved in any kind of redesign project knows, managing internal expectations and opinions can be a huge challenge even among a small team. Imagine inviting the public into the process.
“The toughest balance has been with creative design as that’s where reader opinions are often strongest, while internal viewpoints are fairly fixed,” Hamann says.
Throughout the redesign, the Guardian’s UX team rounded up reader responses and then fed that feedback directly into the product development process, where it was reconciled with internal priorities and design best practices in general.
The open approach raised unexpected questions related to licensing, especially for fonts. “We eventually settled on the Apache license, which offered a good balance of IP protection and freedom of sharing,” says Hamann.
The team was also forced to think differently about security. Hamann says that one side effect of coding in the open was the need to design a system with bulletproof security and avoid things like storing passwords in the codebase.
While the Guardian’s U.S. site was formally relaunched last week, this is hardly a project that begins or ends with that big unveil. The team remains committed to an iterative development process, reportedly sending out as many as five code pushes per day. As the front-facing interface and the underlying code continue to evolve, the next big milestones will be launching the site in the U.K. and Australia.
The redesign builds on top of under-the-hood development that has been underway for some time, but nonetheless played a critical role in letting the project unfold as efficiently as it did.
“One of the biggest lessons we’ve learned from 15 years of software development at the Guardian is that large monolithic applications are a nightmare to maintain,” says Hamann. “With that in mind we have spent the last three years separating our entire infrastructure into a service-orientated architecture. Our fantastic content API has meant that our new responsive application never has to query a database and is purely responsible for rendering content.”
The Guardian’s backend also employs strategy called swimlaning: decoupling crucial parts of the site’s architecture so they can be hosted and served separately. For instance, photo galleries live in one place while news articles live in another. If one goes down, the other won’t be affected.
“One of the hardest challenges of this project is that we’ve essentially been rebuilding an aircraft while it’s in flight,” says Hamann.
For instance, transitioning to the new content management systems (yes, they built two CMSs) required a cautious juggling between the legacy systems and new ones. It was tedious, but ultimately worth it. “The new tools are completely bespoke,” explains Hamann. “The Guardian could never be produced from generic CMS, so we consider these tools to represent real strategic value.”