Reimagining The New York Times Digital Story Experience

May 08, 2018 0 Comments

Reimagining The New York Times Digital Story Experience

 

 

Illustration by Jackie Ferrentino

By FRANNIE HANNAN, JOSH HOELTZEL AND PETER RENTZ

The New York Times publishes more than 150 articles a day to our iOS and Android apps, and our desktop and mobile websites. All of these platforms were originally developed by separate teams, so each had its own implementation and user experience. Though it may not have been obvious to the users of our products, we were maintaining a fragmented experience spanning multiple applications.

Every time we built a new feature or even implemented something as simple as a stylistic change, we needed to build it separately in each place. That meant replicating work, coordinating roadmaps and releasing code across multiple teams — mobile web, desktop and in each of our native news apps, which required a full app release to roll out even the most minor changes.

At the same time, editors producing articles saw a rendering that didn’t represent what the content would ultimately look like on our platforms. This did little to help them envision their work as users would see it. In short, we were blocked by inefficiencies from delivering the best product to our users.

May 8, 2018, marks the culmination of a years-long project to create an article ecosystem that promotes internal efficiency and delivers an enhanced reading experience for our users. We now have a single responsive article for both mobile and desktop on the web, and we use a subset of the same code to render stories in our native apps, Google’s Accelerated Mobile Pages (AMP) and our content management system. Here are the biggest benefits of the work we’ve done:

In order to create a consistent reading experience on all of our platforms that we could iterate on in tandem, we had to make major changes to how our native apps render articles. Prior to the “hybrid” project (i.e. a hybrid between native and web), each native app parsed article data and rendered the headlines, bylines, paragraphs and media natively to display the article.

Now, articles are rendered on the server and delivered to the apps as an HTML string that the native apps display in a web view. This means that as we add new features or change the way we treat existing ones, we can do it with a single web application release without updating the apps in the store.

Another efficiency of the new article system is the introduction of shared components. As we add elements to our article experience, we are building them in an abstract way outside the context of any specific application. This allows them to be shared across applications, pulled in anywhere that the component needs to be rendered in user-facing applications, as well as content creation tools like our CMS.

As an example, consider our bylines: We recently made changes to include headshots and a short blurb about the author, so we built a shared component that would render the byline with these enhancements. We could then utilize that component in the hybrid article, the web article and the CMS, as well as any future application that might need it.

Implementing this approach required a lot of planning, experimentation and coordination across teams. Engineers throughout the tech organization and in the newsroom worked together to make it happen. Today we are sharing more than 40 components across our web, native, CMS and off-platform apps.

The desktop story page is where we made the most transformational user-facing changes. We’ve moved away from a model that is standard for many news organizations on the internet — an article template that has a right rail crowded with ads and other content that draws a reader’s attention away from what they came for: the story. With this new launch, articles are presented in a focused, single-column layout that intentionally strips away the clutter and puts our journalism front and center.

We now have a clean slate on which to build elements that truly add value for readers. In conjunction with Oak — our new visual article editor — we will create and enhance story forms that take advantage of the space and flexibility on the new story page.

The single-column story page was designed to create an integrated reader and advertising experience, built around our proprietary FlexFrame display units. We’ve removed the cluttered right rail of small, standard banner ads in favor of premium, full-bleed, in-stream units that are responsive to the page’s width.

Ads on the new page are achieving twice the click-through rate of our old design, and initial studies show higher brand recall and four-times the reader attention to ads.

“With the new Story page, we’ve successfully integrated our reader and advertising experiences with a pristine, user-focused design,” says Allison Murphy, vice president of ad innovation. “A more engaging page is better from every angle: it means more connection with our journalism, and more connection with the messages of our marketers.”

This marathon effort to reimagine The Times article has given us the infrastructure to build features faster and better meet the needs of users and advertisers on all of our platforms.

In January 2017, an innovation group within The Times released a report titled Journalism That Stands Apart. It lays out how the company must change in order to meet aggressive goals and thrive in the media landscape of the future. Key recommendations included a more visual report and more diverse forms of storytelling. We believe the new article page is a critical step toward allowing us to evolve how we tell digitally native stories that make The Times stand apart.

Frannie Hannan is a senior product manager at The Times overseeing the story page.

Josh Hoeltzel is the senior development manager for the story page.

Peter Rentz is the design director for the story page.


Tag cloud