Scoop: A Glimpse Into the NYTimes CMS • Hacker News Board

Re: Scoop: A Glimpse Into the NYTimes CMS

#51

Post by snide » Wed, Jun 18, 2014, 6:24 AM UTC

sondr3 wrote: post #47

snide wrote: post #24

Earlier quoted context omitted.

Heh. You might find my CMS ( http://www.webhook.com ) funny then. It's a CMS based on static-site-generator concepts... it deploys static websites for example and is easy to use and malleable. However it still has a firebase backend and a traditional /cms/ page with all the modern trappings you'd expect. So I kind of went for both :)

Any news regarding hosting this yourself? I remember this being asked a few times, but I'm curious if your stance has changed since.

It's still roughly the same answer. Likely later this year. Certainly not from lack of want! More just because you'd have to sign up / install so many different services: firebase, elastic search, app engine for image resizing, mailgun or something for emails. There's just a lot of pieces.

Re: Scoop: A Glimpse Into the NYTimes CMS

#52

Post by grayclhn » Wed, Jun 18, 2014, 6:42 AM UTC

jawns wrote: post #30

Context: I'm a former copy editor with experience working for digital-only (e.g. Forbes.com) as well as print-driven magazines newspapers. One of the things that's difficult when designing a CMS that works for both digital and print is that there are far fewer space constraints online than in print, and you want to ultimately generate an article that works in both formats. (Oh, and on mobile, and in a condensed versi…

Finally, a role for the DFW-inspired footnote-heavy writing style!

Edit: to be more constructive, it doesn't seem like this would be hard to represent in the underlying data:

    ...
    omnia haec, quaecumque feret uoluntas
    caelitum, temptare simul parati,
    pauca nuntiate meae puellae
    non bona dicta.

    cum suis uiuat ualeatque moechis,
    quos simul complexa tenet trecentos,
    nullum amans uere, sed identidem omnium
    ilia rumpens;

    
    The next part is usually taken at face value, but, really? Try
    reading it in the most insincere and melodramatic way possible and
    it becomes quite funny. His love is cut down like a flower by the
    plow? Seriously? Have you read the rest of Catullus's poetry?
    Have you read the rest of this poem? The last verse was about how
    many lovers his ex girlfriend is sleeping with (300 at once).
    

    nec meum respectet, ut ante, amorem,
    qui illius culpa cecidit uelut prati
    ultimi flos, praetereunte postquam
    tactus aratro est

I'm sure there are much better ways to do it than that; that seems like a workable starting point, though.

But I'm really surprised that newspapers and magazines really present different versions of the same story to digital readers vs. print readers.

Re: Scoop: A Glimpse Into the NYTimes CMS

#53

Post by grayclhn » Wed, Jun 18, 2014, 6:54 AM UTC

keehun wrote: post #19

systematical wrote: post #7

Earlier quoted context omitted.

https://github.com/NYTimes/ice/

I know ICE is on it. That's just a VERY small part of the entire CMS, however. Why the downvotes?

I didn't downvote you, but vague comments idly questioning the point of the article usually don't do well on HN.

Re: Scoop: A Glimpse Into the NYTimes CMS

#54

Post by minikomi » Wed, Jun 18, 2014, 8:34 AM UTC

Are there any google docs based CMS's ? Seems like you could offload the editing, saving, tracking changes to google docs - a platform many people seem familiar with now - and then keep the actual CMS to a bare minimum. Have it import the text & spit out a static page even.

Re: Scoop: A Glimpse Into the NYTimes CMS

#55

Post by alphapapa » Wed, Jun 18, 2014, 9:46 AM UTC

ryanklee wrote: post #46

thathonkey wrote: post #45

Earlier quoted context omitted.

Interesting idea but I'm skeptical that any writer would ever be able to adopt something so "technical" (for lack of a better word). Writers just don't think like that and I don't think they ever will. It's a wall between creative types and tech types that is here to stay, imho.

I'm a writer and I think "like that". I know many other writers that do, as well. And it's not surprising, because writing itself is a technology in a traditional sense. Further, it's more "tech" oriented (in the more contemporary sense) than you give it credit for. It's very close to coding: It's structural, admits of procedure, copy reuse, partakes of historical design advancements, adapts to tech around it, etc. F…

You have a point, but so does he. How many nonsensical comments have you seen online that are obviously the result of failing to proofread from start to finish after editing? You move a sentence from here to there, or rewrite or remove one, and the flow is broken, and it no longer makes sense. Writing and reading are--at least, within a single piece--linear activities. Creating a system for removing or rearranging sentences or paragraphs creates an exponentially increasing number of potential combinations, each of which would need to be proofread completely by a human or an advanced AI. Otherwise you'd end up with nonsensical articles and dumbfounded readers, and then the whole system would be thrown out.

Re: Scoop: A Glimpse Into the NYTimes CMS

#56

Post by darylteo » Wed, Jun 18, 2014, 9:57 AM UTC

BrandonSmith wrote: post #4

The CMS is in a renaissance period with Wordpress, Joomla, Drupal and the like falling out of favor. I believe the CMS is bifurcating into two specialized directions. Several online publishers are coming out and describing their new, home-grown custom CMS. The features are rich and provide robust, innovative tools across the long-form content lifecycle: writing, editing, and publication. There is special attention to…

Take any normal CMS, cache the html, and you have a static site generator.

Re: Scoop: A Glimpse Into the NYTimes CMS

#57

Post by stdbrouw » Wed, Jun 18, 2014, 9:59 AM UTC

edavis wrote: post #21

chestnut-tree wrote: post #18

Earlier quoted context omitted.

I agree - I find the idea of static site generators (SSGs) very appealing, but they are not user-friendly to setup - unless you happen to be technically-minded. Some tell-tale signs that SSGs are made by programmers for other programmers: command line-installation and configuration, a liking for markdown (and a dislike for WYSIWYG). Just to be clear, I'm not knocking any of this. The fact that people have put their o…

> What would it take to make an SSG appeal to a broader set of users? I don't think the SSG, as they largely exist today, will ever gain widespread usage by mainstream users. But one thing that could drive greater adoption would be to develop an aesthetically pleasing web front-end that lets users write content using familiar WYSIWYG tools, but save the content to local files instead of a database. From there, the pr…

Here's that aesthetically pleasing web front-end for SSGs, though it's tied into GitHub: http://prose.io/

Re: Scoop: A Glimpse Into the NYTimes CMS

#58

Post by stdbrouw » Wed, Jun 18, 2014, 10:10 AM UTC

minikomi wrote: post #54

Are there any google docs based CMS's ? Seems like you could offload the editing, saving, tracking changes to google docs - a platform many people seem familiar with now - and then keep the actual CMS to a bare minimum. Have it import the text & spit out a static page even.

Bangor Daily News does all of their editing in Google Docs. They then feed things into WordPress and InDesign, but I imagine you could feed it into pretty much anywhere.

http://dev.bangordailynews.com/2011/06/16/marrying-google-do... http://toc.oreilly.com/2011/06/google-docs-wordpress-indesig...

Re: Scoop: A Glimpse Into the NYTimes CMS

#59

Post by vertex-four » Wed, Jun 18, 2014, 11:18 AM UTC

dreamfactory2 wrote: post #43

BrandonSmith wrote: post #27

Earlier quoted context omitted.

There is no doubt that SSGs will "grow up" and appear to gain features like Wordpress. The difference will be that SSGs are born out of loosely coupled tools in a toolchain ecosystem. Over time, I believe the successful SSGs will have a decidedly Unix flavor to them. Take http://www.metalsmith.io/ as an example.

SSGs are fundamentally flawed. The web is moving fast away from being a static page-centric medium to a dynamic content-centric one.

I think the future of "SSGs" is that they're going to end up as programs running on the server that watch data from various feeds - databases, RSS feeds, APIs - and generate output from those. Basically, a streaming processor framework. The output would likely be in a "semi-baked" format so that they can contain processing instructions that are executed at request time, or otherwise lazily.

These won't be static site generators any more, and will lose out on the "you can throw it up on Github Pages" benefit, but they'll be far more powerful, and it'll be easier to develop dynamic, data-driven websites.

Re: Scoop: A Glimpse Into the NYTimes CMS

#60

Post by thathonkey » Wed, Jun 18, 2014, 12:41 PM UTC

ryanklee wrote: post #46

thathonkey wrote: post #45

Earlier quoted context omitted.

Interesting idea but I'm skeptical that any writer would ever be able to adopt something so "technical" (for lack of a better word). Writers just don't think like that and I don't think they ever will. It's a wall between creative types and tech types that is here to stay, imho.

I'm a writer and I think "like that". I know many other writers that do, as well. And it's not surprising, because writing itself is a technology in a traditional sense. Further, it's more "tech" oriented (in the more contemporary sense) than you give it credit for. It's very close to coding: It's structural, admits of procedure, copy reuse, partakes of historical design advancements, adapts to tech around it, etc. F…

I think you're definitely an exception. I work with large editorial staffs every single day and haven't come across a single person who I think would feel comfortable crafting a "dynamic" story that is susceptible to losing and gaining chunks of copy depending on how much space there is. It would be a total sea change for how most editorial shops operate. They are so detail oriented, and to them, every word counts and has a distinct purpose within the greater text. Basically, if it could be cut, it would have already been cut (either by the author or by a managing editor).

To have a whole section arbitrarily cut from the version of an article that user X reads on their iPad vs user Y on a big screen laptop would be met with skepticism at best, outright horror at worst.

I am a writer as well and I can't imagine writing like that or how such a system could possibly work from a technical perspective, much less a UI perspective.

PS. I didn't mean to say that creative people can't be technical or vice-versa, just that writing tends to be a creative-oriented job while programming is obviously a technical-oriented job. Obviously there is overlap between the two and many people excel at both. Sorry if it came out sounding like I believe there is a creative|technical binary.