Reuters' former Next Web system
Sep 19, 2013 - Nieman Journalism Lab - Reuters nixes Next: Failed redesigns and the challenge of expanding a digital audience
May 2013 story
May 2013 Every page is your homepage: Reuters, untied to print metaphor, builds a modern river of news
Dave Winer: Here’s why every news organization should have a river
Reuters Next: http://preview.reuters.com
Reuters unveiled a preview site for the future look and design of Reuters.com. It’s a river-of-news type of approach that mirrors the flow of data on one of Reuters terminals, but has also become increasingly popular in the era of social media.
The stream approach has become somewhat fashionable in the world of news, said Daniele Codega, design director for Reuters Digital, partially because audiences (and publishers too) no longer have a fear of scrolling. (Some, like Quartz, have built an entire navigation hierarchy around scrolling rather than clicking.)
In an era when many newspapers and magazines are using typography and layout to make their apps look like their print product, Reuters — with no print edition to ape — is instead making its website look a lot like its new apps, building a consistent experience across platforms.
Roberts said news sites homepages are still a powerful driver of traffic, but the tide is shifting in another direction. “The days where you could drive big portion of audience to any single page? That’s pretty much done,” he said. The media have to be willing to adapt to changing times, Roberts said, and that means having a highly adaptable website and apps.
So much cool tech behind http://preview.reuters.com , I have to share: 1. RESTful API outputting assets as JSON.
One custom built CMS controls API and all client-facing apps.
Hosted on Amazon cloud, no more big iron datacenter for Reuters News.
Much of back-end built in Python and associated technologies.
Oh yeah, we used MongoDB too.
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. 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!
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.
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.
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.
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.
... 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!
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.
I guess the Reuters group developing Next tried to do too much. Maybe they should have started even simpler and launched and iterated much sooner. Maybe they should have avoided trying to be too cool, too hot, too hip with all the "webby" stuff.
The API makes sense. That's a good place to start. But maybe they tried to do too much with everything else.
#media - #design - #programming - #api - #json
From JR's : articles
1053 words - 6063 chars - 5 min read
updated on - #
source - versions - backlinks
API-first-development design - Jun 23, 2014
Comments about commenting systems - June 2014 - Jun 23, 2014
Draftin.com WebHook URL info - Aug 09, 2013
Short list of REST API info - Jan 13, 2017