Scoop: A Glimpse Into the NYTimes CMS
open.blogs.nytimes.com
open.blogs.nytimes.com
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.
Doesn't HTML do this? <h1> is more important than <h2>, etc.
<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>That said, html5 is pretty free in terms of what you put in the document -- personally I'd probably prefer a "weight" or "weight-group" attribute applied to elements and/or set on span-elements. Weight might be a float between 0.0 and 1.0 (pick one to be most important, maybe let "heavy" weights "sink to the bottom", and "fall off"... ?) -- the idea of a "weight-group" would be to group headers and/or phrases/paragraphs to be dropped together -- eg for this comment, you might want to drop all references to "weight-group" -- if you wanted a shorter, simpler version.
Too far down this path and you're square in natural language processing territory -- but it should be easy to mock up a web app that lets the author/editor preview how different versions would render/look -- and allow adding/removing tags/weights to the text(s) as appropriate.
Perhaps one useful extension would be auto-promoting a paragraph and/or (depending on format/space) part of a paragraph, or just a header -- to be used as a "deck" and/or summary (for eg rss feeds) etc?
Is there much precedent for writing scalable copy? Yes! I used to have to cut wire stories to fit. Let's say 25 newspapers run the same wire story, each with different length requirements. That's 25 editors who have to make different cuts, and some might in haste cut sections that are actually pretty important. Some writers give cues to the editors -- "cut this graf if necessary" -- to avoid that happening.
Is there much NEED for scalable copy? Yes! It potentially saves copy editors a lot of work. And if the "magic" can be automated, it saves a lot of time, too!
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. Fuzzier, maybe. But try and do it well, sometime. The edges are harder than you might think.
(And, as an exasperated aside: Ugh!! There is no wall between creative types and tech types! No such types exist in the first place. Only weird, sticky prejudices.)
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.
You mention elsewhere that "It potentially saves copy editors a lot of work." but I think you'd have to be a pretty darn good copy editor to keep multiple versions of a story in your head at the same time and ensure all of them keep their flow and coherence. Perhaps it really just is faster to read and edit any and all versions of a story separately.
What you're describing could work, but only if people changed the way they wrote to make it easy to cut things out without having to rewrite other things. But then you're back to something like the inverted pyramid.
What we ended up doing instead was to give authors the ability to "fork" stories into different editions that are, from that moment on, edited completely independently from each other, but behind the scenes keep track of which parts of the story are still the same, so you can provide intelligent diffs, notifications and potentially even merges like "In the web edition it talks about a guy named Jon but the print edition refers to John -- which is it?" without changing the experience for writers and editors too much.
Edit: to be more constructive, it doesn't seem like this would be hard to represent in the underlying data:
...
<p>omnia haec, quaecumque feret uoluntas
caelitum, temptare simul parati,
pauca nuntiate meae puellae
non bona dicta.</p>
<p>cum suis uiuat ualeatque moechis,
quos simul complexa tenet trecentos,
nullum amans uere, sed identidem omnium
ilia rumpens;</p>
<aside>
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).
</aside>
<p>nec meum respectet, ut ante, amorem,
qui illius culpa cecidit uelut prati
ultimi flos, praetereunte postquam
tactus aratro est</p>
But I'm really surprised that newspapers and magazines really present different versions of the same story to digital readers vs. print readers.
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.
I think Wordpress is still going to stay in the game. It still has a road ahead of it. I do think that the big newsrooms are going to expand past it's limiting multiple-people collaboration features into a new CMS, but most blogs will want to use WP.
Developing a custom CMS makes sense for exactly one type of company: a publisher whose entire business depends on their CMS. For companies in that situation, developing a custom CMS is a capital investment in their core product.
Everyone else will save time, money, and security headaches by building on a popular open source platform. Heck even Twitter uses Drupal to power their developer site.
My point is that the traditional CMS is falling out of favor as the default solution for content on the Web. Need a blog? Wordpress is increasingly NOT the solution. As developers, we are trending away from the one-size-fits-all CMS and into specialized categories of CMS.
The CMS renaissance is due to two factors:
1) A proliferation of great tools emerging into a toolchain ecosystems. Node's Grunt and Gulp are fine examples. This is largely different than the traditional CMS because...
2) Developers are increasingly wanting to gain more control over our craft.
> As developers, we are trending away from the one-size-fits-all CMS and into specialized categories of CMS.
Most of the sites which would typically get built on Drupal (and especially Wordpress) aren't owned by developers. Further, these owners probably don't even have a developer on staff or even on a maintenance retainer. Many of these sites are setup by relatively non-technical users. Many of these sites are setup by a developer the owner has paid and then that developer is out of the picture to be run by the owner.
Even if you are a start-up building your own web app, it still often doesn't make sense to build your own blogging system. Rather, you would get your first version out the door ASAP, throw your blog up on a sub-domain running Wordpress and then maybe down the road figure out something different.
Do what you want for your own site. But when you are doing something for clients who don't have a tech staff, it's not about what the developer wants.
Wordpress, on the other hand, appears to be on fire.
By any metric of public popularity, Wordpress is growing a lot faster than Drupal. Drupal's growth is into the enterprise arena which is not as public.
The number of purely Drupal shops is dropping because pretty much every agency of note had added Drupal to their stable of solutions. It's not an esoteric differentiator anymore--which is actually a form of growth for the platform.
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.
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?
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.
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.
- For complex web pages with a lot of design, we have to put most of the content into .jade files - mainly because of the style of our webpages (long-single-page style with a lot of sections). If we were doing a more traditional page structure, then we could have markdown files. This is "ok" but requires content authors to get into .jade files which can be a little intimating. (if anyone has any thoughts about how to get around this, I'm open to hear them).
- We're storing the files in Github, but have now figured out that if we want a distributed team to work on this, we'll need something like Jenkins to auto-deploy to a staging server on commit. The problem is that the first thing people want to do once they've made an edit check the page to see if it worked. This is trivial in WP or Drupal, but without Jenkins in place, I don't see an obvious way to do it unless we have the content folks run Hexo locally (which I'd like to avoid).
- Huge improvement in the speed of the site vs. the Drupal website. Not shocking given the move to static files, but there is also a reduction in javascript - some of which was coming from Drupal.
- Nice to have all content under source control.
All in all, it's a bit of a mixed bag at the moment - the SSG is supposed to be a simplification of our stack, but now we have to run Jenkins to manage deploy (probably not a bad thing but no one here is an expert in it), and our content people are finding it a bit intimidating.
My worry: we setup all this stuff, and then someone key on the engineering team leaves and we're left with an overly complex stack vs. just going with Wordpress.
Depends on your definition of SSG. I'd consider an app such as RapidWeaver[1] to be a SSG. They aren't targeting "HN nerds."
So I kind of went for both :)
Alright... hear me out... thoughts on combining webhook.com with Atom as a single download/install. There are custom Atom packages that provide UI to achieve what you are doing through the CLI. Preview locally, too.
Atom stuff sounds like a neat idea, but I'd rather not tie us to any specific editor. Obviously people can write whatever they want though. We plan on open sourcing most of the code.
There is always a case for building a custom CMS and some companies go that route. That has been case since the WP/Joomla/Drupals off the world came into existence. I don't see a trend though, in fact I think all 3 of those are growing.
For some companies a custom CMS just makes the most sense. It doesn't really reflect anything on the off-the-shelf cms-es.
And static site generators are not exactly taking off like crazy either, in terms of growth.
Choice is always good though. In that respect, I agree that there is a renaissance There are lots of great ways to run a site now. There are some nice looking CMS platforms and the popular platforms continue to mature as well. It's good stuff all around.
The conclusion is way off base and ill informed; early digital pubs recognized immediately that OS CMS systems and blogware weren't going to cut it and brewed their own tech (a few of which were subjected to attempted productization, which inevitably failed, exa: vignette storyserver), and nothing's really changed in that regard.
know your history before you declare a renaissance, mm-kay
http://dev.bangordailynews.com/2011/06/16/marrying-google-do... http://toc.oreilly.com/2011/06/google-docs-wordpress-indesig...
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).
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.