
Scoop: A Glimpse Into the NYTimes CMS - edavis
http://open.blogs.nytimes.com/2014/06/17/scoop-a-glimpse-into-the-nytimes-cms/
======
jawns
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 version in a sister
publication, and an expanded version for the wire.)

For hard news, the inverted pyramid format comes in handy -- if you don't have
enough space in the print edition, you just lop off the last few paragraphs --
but for things like op/eds and magazine-style pieces, that doesn't always
work.

What I'd love to see is a CMS (and, more fundamentally, a way of representing
the underlying data) in which writers and editors can designate certain
paragraphs or sentences or phrases as more important than others, so that even
a story with a complex format can be dynamically "scaled," sort of like what
web designers do with media queries, or what image editors do with seam
carving.

~~~
charonn0
> a way of representing the underlying data in which writers and editors can
> designate certain paragraphs or sentences or phrases as more important than
> others

Doesn't HTML do this? <h1> is more important than <h2>, etc.

~~~
jawns
<p><span class="cut-me-first">Well, </span>yes, but <span class="essential">in
only the broadest sense possible.</span> <span class="cut-me-next">For the
purposes of an op-ed piece <span class="nice-to-have">or a feature
story</span>, though, you'd need to have much more control.</span></p>

<p class="normal-priority">Actually, this comment illustrates that such a
system might not be as easy as you'd think. Some natural-language
processing/generation would come in handy to ensure the following <num-of-
bullets> things:</p>

    
    
        * proper capitalization
        * subject/verb agreement
        * proper punctuation
        <span class="cut-me-first">* number agreement</span>

~~~
charonn0
Aren't these the job of a human editor? (or is this the reason why my
e-newspapers have so many copy editing errors?)

------
BrandonSmith
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 collaboration.

On the other hand, more and more website developers align themselves with the
goals and properties of static site generators. SSGs are best suited what I
call "malleable" websites.

Thus, I think the way to think about this CMS renaissance is that traditional
the CMS tried (and failed) to optimize for both long-form content and the
malleable website. As a result, people are sick of trying to patch the
traditional CMS with plugin after plugin and instead are simply crafting their
own.

~~~
smacktoward
I would humbly suggest that static site generators are not nearly as popular
as you might think if you only view the CMS market through the eyes of the HN
crowd.

SSGs are hugely popular among nerds and practically unknown among everybody
else. The result is a kind of distortion where, to nerds, it looks like SSGs
are about to take over the world -- "all my friends use them!" But step
outside that tight network of people and they are more or less completely off
the radar.

~~~
chestnut-tree
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 own time and effort into building SSGs and then generously open sourced
them is pretty awesome.

In my view, the audience for SSGs, whether intentional or not, is mostly other
programmers. What would it take to make an SSG appeal to a broader set of
users?

~~~
edavis
> 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 process would be largely the same as it is now:
transform this directory of lightly marked up plain text files into raw HTML.

So, to answer your question: Make it more like Wordpress.

~~~
BrandonSmith
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/](http://www.metalsmith.io/) as an example.

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

~~~
vertex-four
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.

------
minikomi
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.

~~~
amalag
That is a very interesting idea, but since NYTimes opensourced their ICE
editor, I am not sure what Google Docs would provide.

~~~
minikomi
Transparent version control, tracking of changes, collaborative editing,
familiar interface, familiar workflow (just drop finished articles into this
directory to be available to the CMS)

------
powera
This appears to be unrelated to the Kuro5hin derived CMS named Scoop?

------
burritofanatic
I was always under the impression that they're Django/Python. Can anyone
confirm?

~~~
krishy
No.

We use a pretty normal ("boring") Java stack with Spring, Hibernate and
Jersey. Some of the older components use Struts + JSPs whereas the newer
components use Backbone (and related libraries).

~~~
augustl
Which database? A JDBC one?

~~~
lvnenchak
scoop uses mysql for its managed repository. we also use mongodb for our
published repository that serves our apis to everybody else.

------
Grue3
It looks surprisingly nice for an in-house app. Usually there's no point to
focus on web-design for these kind of apps since the public won't be able to
see them anyway.

------
keehun
Very interesting and cool article, although I wonder what the point of this
is? Just a show and tell? Doesn't seem like they're open sourcing it.

~~~
systematical
[https://github.com/NYTimes/ice/](https://github.com/NYTimes/ice/)

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

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

~~~
keehun
Oh, I should have written my post better.

It should be known that I love behind-the-scenes more than the movies, and I
love these peeks more than anything else. Just was genuinely curious why
NYTimes would take the time to show us. I don't think it would help any with
the subscriptions/circulation numbers but I am probably wrong.

------
jonaldomo
I could see this as premium wordpress service successfully charging $15 - 25 a
month for bloggers.

~~~
cliveowen
I don't, and it would be too expensive even at $15 imo. But even if something
like this had a market there's the problem of the editor, as it uses
contenteditable which is at best inconsistent across browser and at worst
completely broken. That's also the reason Google Docs dropped it and started
doing editing the hard way. As long as you know who uses your software and you
can enforce the use of a given browser (as is the case with the writers for
the NYT) there's no problem with contenteditable, but for a general solution
you need to drop it.

~~~
volaski
ice plugin works for tinymce as well as contenteditable
[http://nytimes.github.io/ice/demo/](http://nytimes.github.io/ice/demo/)

------
nsher
Looks like Drupal with a few node_hooks to me

