Hacker News Reader

Comment by flashman | Hacker News Reader

I'm really interested if anyone knows how the Times is planning to keep this type of content available on long time scales. They can realistically assume that twenty, fifty, a hundred years out people will be reading these articles.

These articles are a bit different from maintaining a text archive.

View on HN

I can speak a little bit to that question.

We do, indeed, hope to keep interactive articles working and available over the long term. But you can't always predict the technical choices of the future web.

For example, there are plenty of past Times graphics done with Flash, which may not be easily viewable within the next 5 years.

On the other hand -- one of the biggest culprits is simply using external APIs as part of a graphic. APIs shut down, change their terms of use (Google Maps), or have data updated in ways that break the graphic. For example, as we just noticed the other day, this 2011 graphic used to show Joplin, Missouri before and after the tornado hit:

http://www.nytimes.com/interactive/2011/05/27/us/joplin-pano...

Now, the "before" panoramas are actually "way after" shots. We'll need to go back and fix it somehow.

But it's not all Sisyphean. The standard operating procedure for any interactive article page is to live somewhat inside and somewhat outside of the CMS -- with the page's own baked-out HTML base, and individual copies of any JS libraries and CSS it needs (apart from the super common ones). With a little foresight, this should be resistant to breakage from future site redesigns, even if the page continues to look a little "old" ten years from now.

As long as browsers in 2025 understand JavaScript from 2015 (likely), I'm optimistic.

"Always bet on Javascript" - Brendan Eich

Thanks for your comment, that's exactly the kind of answer I was looking for :)

I read it through a reader that uses Readability, so it was plain text. I didn't know anything was missing until I read your comment.

That said, the text was a little flowery and aimless. In retrospect it feels like not was written to support the animations and not the other way around. If and when the format becomes more mainstream then it probably won't hold up as well in the future. Kind of like early 3D films.

There's even a substantial difference between mobile and desktop - and I didn't even know I was missing out. Some of the change is good (air traffic areas are labeled by their designators vs names on mobile), others are just missing which is a pity.

…it's adapted from a book.

The Times does have plaintext archives of pretty much everything - aside from anything else, it's how they make the print edition.

I imagine the interactive elements may not render correctly even just 5 years from now.

What interactive elements? All I saw as part of the content were static images, and newspapers have had those for a long time. There were some other illustrations and animations, kind of like the way some children's books have them interspersed among the text, but none of those were interactive either.

Another poster also referred to the animations as interactive... I guess some people think of animations as interactive.

I see animations that are driven by scrolling. Which you can control and scrub backwards and forwards again. So it's got an interactive element.

The Times broadly refers to this kind of storytelling as 'interactive' judging by this 2014 showcase: http://www.nytimes.com/interactive/2014/12/29/us/year-in-int...

I guess the underlying question is how they plan to support these web technologies into the future; what's their long-term technical debt in that sense?

Given that past coders for the NYTimes have included the creator of CoffeScript/Backbone and the current maintainer of ClojureScript/Om, it seems (at least anecdotally) that whomever is in charge of staffing the dev team is doing a decent job.

Of course, some of the worst technical debt I've had to deal with came from "world-class developers", so this is no guarantee that they won't collapse under the weight of their own code at some point...but I think the odds are at least in their favor.

Why not? It's not like web browsers habitually break compatibility, with some notable exceptions (removal of Flash and Java)... I guess it could break as part of a CMS refresh.

The chance that this will break because of a CMS update, a new paywall, site-wide Javascript updates is far higher than because of a web browser upgrade.

Reply on news.ycombinator.com