I'm old fashioned...the parallax motion and the embedded widgets and things don't do much for me, but what really sticks out to me is the great photography, and this format, whether you like the effects or not, at least showcases the great images.

That said, I don't think this story-telling format is the future of journalism. The reason why this story looks so attractive is because there are so few ads, if any. Yes, this format lends itself to being able to do full-page ads or special built-in ads...but those take work to both acquire and construct. Given that these type of feature stories are far and few between, I'd be surprised if the higher-CPM on special-feature-story-ads outweighs the bespoke-effort needed to acquire and implement them. In any case, I highly doubt that if it does, that it does so at a scale that is meaningful.

And another thing: the reporting and editing is obviously the bottleneck here. But let's let that be a given...the other main bottleneck is the non-web-dev reporters and editors trying to get their ideas into this innovative format. My guess is, that even at the New York Times, this is a very painful and slow process, even if your devs include Mike Bostock, creator of D3. Part of these features are done with generated templates. And part of them appear to be handcrafted.

But again, it's not the hand-crafting that is necessarily the most painful part of the tech workflow. It's the editing across systems that weren't designed for this collaboration. Have you ever built a fancy website in Flash only to have your client want to change a bunch of links that were hard-coded? Imagine that, except across several editorial departments. Another way to think of it: newspaper reporters and editors typically do not use Sublime Text.

----

Some technical observations:

The NYT interactive team has been doing analytics on these different story formats. Check out the source code for their previous feature on The Jockey:

http://www.nytimes.com/projects/2013/the-jockey/#/?chapt=bre...

At the bottom is some JavaScript that seems to be handcoded for that feature and refer to analytics:

NS.jockeyMeta = {
photoPath: 'http://graphics8.nytimes.com/packages/images/multimedia/bundles/projects/2013/Jockey/',
videoStillPath: 'http://graphics8.nytimes.com/packages/images/multimedia/bundles/projects/2013/Jockey/',
videoPosterPath: 'http://graphics8.nytimes.com/packages/images/multimedia/bundles/projects/2013/Jockey/',
videoPath: 'http://graphics8.nytimes.com/packages/video/multimedia/bundles/projects/2013/Jockey/',
url: 'http://www.nytimes.com/projects/2013/the-jockey/',
viewport: document.documentElement.clientWidth,
legacyDesktop: window.NYTMM_IE,
imageSizes: [1400, 1280, 1024, 980, 800, 680, 640, 540, 420, 380, 320, 280],
videoSizes: [320,600,970],
blankImage: 'http://graphics8.nytimes.com/packages/flash/multimedia/ICONS/greyC.png',
comment_page_url: 'http://www.nytimes.com/projects/2013/the-jockey/comments/'

If you view the source of the Russia story, you won't see any such analytics code. You'll see a lot of D3 code and even some special video-player helper code that I haven't seen on the other features. So again, these features are a pretty new thing, but I think it's a long way from being something that is scalable, and not because for lack of technology or skill at the NYT.