The CMS and API

Q. What’s going on under the hood on the new site? We want to know every little thing about your CMS and API.

Ok! Let’s start with where much of our content comes from: an API called Media Connect, which is how we serve our media clients. When we started this project, we threw away everything downstream of that because we had some really fundamentally different ideas about how the new Reuters.com should work that we wanted to try. The Media Connect API, however, serves content to other systems, and isn’t a permanent store of Reuters content. So we had to build our own API both to poll Media Connect and pull down all the content we needed to populate our own data store.

We also wanted this API to serve all of the applications we were building as the next generation of Reuters Digital: our new website, our new mobile apps, and our new CMS. Yep! All of those apps are actually clients to the new API. This is because we wanted to control content for all the public facing platforms from one place—the new CMS—and keep the display rules on each individual client. API power!

The other thing this setup lets us do is show off the depth of Reuters content. We produce, including videos, text, pictures, and other content types, something like 20,000 unique items per day. But our current website really didn’t let us show off the depth of our reporting. So one of the main functions of the CMS is really set up to allow editors to create and curate collections—we call them streams—of stories. This lets us get to the endless-scroll type behavior that Facebook, Tumblr, Twitter, and the rest have made popular as the new default behavior of the web.

As for the tech choices behind all these decisions, they’re standard, modern and webby—everything from JSON to MongoDB. I think this tweet says it all:

The new @reuters site is using bootstrap, require.js and backbone. preview.reuters.com Hot.

— Yuri Victor ♥ (@yurivictor) May 2, 2013

 

Q. How do your tech choices specifically support the move to this stripped-down design that boosts the importance of individual article pages?

Everything, as mentioned, was designed in service of editors being able to work with Reuters content and create these collections in the API. We had a lot of thorny data problems to handle. But one thing the new system is great at is respecting the metadata that has come from the upstream publishing tools Reuters journalists use today. As we build more and more of the new system, we’ll be able to use that metadata to do delightful new things with our content, and for our readers and advertisers. We always want to show off this clean new look and trust the reader to scroll to get to more of our content. But we do want to take advantage of all the data that comes with our stories, pictures, and other assets, to find new ways to do journalism online.

Another big thing is that this CMS is ultimately replacing a bunch of very fragmented systems. So besides working with all this upstream content, we had to get to a kind of parity with the existing tools that editors use for the existing Reuters.com. The power we have one level below this new system is that everything editors do in this new CMS—adding content to collections, “promoting” content at the tops of pages, attaching photos to stories, editing headlines—are all captured by the API and ultimately turned into data that we can use to test and improve upon the assumptions that went into building this platform.

Moving to the Cloud

Q. You’re in the cloud! What advantages are you seeing from switching the site to Amazon?

I know it’s our desire to get away from the idea of a big iron datacenter with fixed costs to something much more flexible to the ever-changing needs of news. We are using EC2 and S3, and a few other services in our stack. I don’t think we’re doing anything revolutionary on the hosting front, when you look at what any startup is doing these days. But it’s revolutionary for a company that typically has done things in a very different way in years past, not so much by choice, but out of necessity.

Testing and Iteration

Q. What kind of testing have you been doing in the last few weeks/months leading up to the preview launch?

We’ve done a fair amount of user testing, including in the Thomson Reuters Design Lab in London. That helped us affirm we weren’t crazy to move to this kind of scrolling, snacking behavior. And our design team is really first-rate, coming at this brand new way of consuming news with a ton of internal thinking on how they should make this thing work. But really, this new system is so dramatically different that any kind of A/B testing against our current system is useless. We are even throwing away analytics comparisons as far as year-over-year. I’m sure we’ll iterate on the design, but in order to see how “Bs” do, we had to build an “A” first.

Q. What can we expect to see as the new design rolls out and you start iterating?

A lot! We are just taking the wraps off of the first public versions right now. But because we built this system to be rapidly iterated on, we’ll be able to roll out new tweaks and fixes quickly and frequently. In fact we already updated our iOS apps with some nice UI enhancements!

That Other Thing

Q. What really interesting thing did I forget to ask you?

One thing worth mentioning is that streams aren’t just for content; they are for everything, including ads. Right now you see a very basic IAB ad at the top of every “stream” of content in the promoted content area (that’s the area at the top of every “stream” where editors have pinned the stories most important to that stream). But I’m super excited about what our design/tech team has thought up to support the business model for this new site. I can’t wait to see more of their work make its way to the public.