8 ms·

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 t

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.

w1ntermute 11y ago
I imagine the interactive elements may not render correctly even just 5 years from now.
- SamReidHughes 11y ago
  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.
  - poppup 11y ago
    Another poster also referred to the animations as interactive... I guess some people think of animations as interactive.
    - kzrdude 11y ago
      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.
  - flashman 11y ago
    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-interactive-storytelling.html 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?
    - jballanc 11y ago
      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.
- deleted 11y ago
  [deleted]
- comex 11y ago
  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.
  - huskyr 11y ago
    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.
underwater 11y ago
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.
- joelhaasnoot 11y ago
  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.
- coob 11y ago
  …it's adapted from a book.
untog 11y ago
The Times does have plaintext archives of pretty much everything - aside from anything else, it's how they make the print edition.
jashkenas 11y ago
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-panoramas.html?ref=us 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.
- thomasfl 11y ago
  "Always bet on Javascript" - Brendan Eich
- flashman 11y ago
  Thanks for your comment, that's exactly the kind of answer I was looking for :)

w1ntermute 11y ago

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

SamReidHughes 11y ago
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.
- poppup 11y ago
  Another poster also referred to the animations as interactive... I guess some people think of animations as interactive.
  - kzrdude 11y ago
    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.
- flashman 11y ago
  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-interactive-storytelling.html 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?
  - jballanc 11y ago
    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.
deleted 11y ago
[deleted]
comex 11y ago
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.
- huskyr 11y ago
  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.

underwater 11y ago

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.

joelhaasnoot 11y ago
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.
coob 11y ago
…it's adapted from a book.

untog 11y ago

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

jashkenas 11y ago

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-panoramas.html?ref=us 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.

thomasfl 11y ago
"Always bet on Javascript" - Brendan Eich
flashman 11y ago
Thanks for your comment, that's exactly the kind of answer I was looking for :)