Last week, the New York Times gave us an inside look at their custom CMS, Scoop. Though a few NYTimes blogs run on WordPress, the main site is managed by a fairly massive custom effort. It got me thinking about how far WordPress has come in terms of managing complex websites and applications, and all of the work that still needs to be done.
Data Management
One of the major advantages of Scoop was its ability to store content and data in meaningful ways. This includes the basics like a robust tagging hierarchy but also the ability to store all of the drafts of every post. This allows the NYTimes editors to output their content however they want, from arranging post drafts like Microsoft Word’s “track changes,” to outputting posts alongside relevant similar content arranged by topic.
WordPress has an incredibly advanced tagging system. Rolling out a custom taxonomy is a simple affair and creating a layered hierarchy of content is what the platform was built to do. And on the backend, drafts are stored and even auto-saved. Where WordPress can really grow in how this data is output. Connecting taxonomies and smart relevance algorithms are a good next step. Plugins like Posts to Posts and Post Connector get us some of the way there, but we need better ways to latch content together, and decouple them just as easily. Whether this translates to different database structures or a deeper API is up in the air, but this could really propel the software further. And how about a track changes plugin?
Drafts and Workflows
The NYTimes team works in a multi-author workplace with multiple writers, editors and developers touching the same post. As such, Scoop has been custom built to address this process. For instance, it is possible to lock certain fields in a post (i.e. just the summary). There is an elaborate story planning and budgeting system built in. And notifications are sent to authors through the CMS and email whenever a post is edited.
Luckily, I saw very little that WordPress couldn’t do, either on its own or with a plugin. Installing Edit Flow and Coschedule will fill in most of the functionality. And the o2 team is doing a great job with the power of Javascript and back-end notifications. The problem is, the technology and UI are still nascent in almost all cases. Post locking only works for an entire post. The learning curve for plugins like Edit Flow and Coschedule, and indeed WordPress as a whole, can be a bit steep for new users. o2 isn’t widely available. I believe the future here lies in the ability to customize the admin and mold it to the needs of CMS users, not just consumers. We’ve seen Happy Tables adapt this model to great effect. We need more clever experiments with how to harness the power of back-end customization, not just the front.
Seamless Visual Editing
Editors and authors at the NYTimes need to be able to easily preview and visualize their content and integrate all kinds of rich media with the click of a button. To that end, editors and story authors can create smart crops of images for different sizes and contexts, which a computer then turns into art directed images for over a dozen image sizes. And multimedia items like slideshows and videos can be dragged anywhere into a post. When the post is ready, authors can view a preview, exactly how it will look once it’s published, on both the desktop and mobile site.
Again, I see very little that WordPress can’t do, if not as well. The cropping abilities of WordPress’s media uploader are generally underutilized but present. Algorithmic art direction is something I’ve never seen before, but I imagine it is possible. And through a clever system of custom fields and modular content blocks we can be smarter about how rich media is integrated into posts. The technology is there, it needs only to be implemented.
But what’s most promising is how we’re leaping even further ahead in this regard. With a front-end editor like VelocityPage being rolled into core with a new UI built from the ground up, average users visiting the admin will be a thing of the past. That will free up writers to do what they do best—write. And let the developers, designers, and builders of WordPress websites deal with the back-end administration.
Open API
One of the more interesting insights that the Scoop team provided was its focus on a lean and adaptable content API that can be used to extract content and place it anywhere. Their focus is on read and write abilities, meaning that content can be edited anywhere and placed anywhere. A rigid system of metadata tagging lays the groundwork for this effort, but opening up data so that it can be used on the web, in apps, or on your toaster, all while being synchronized across platforms, is no easy effort. It is clearly a focus for them going forward, as they look towards interesting way to repurpose and utilize the content they have.
One of the most exciting features coming down the pipe in WordPress development is the JSON REST API (WP-API), slated for Version 4.1. It opens up the data architecture of WordPress as a RESTful API, so data can be manipulated on the client side using Javascript, in apps, or just about anywhere else. If you don’t know what this means, it is a huge step towards ensuring that WordPress becomes a legitimate application framework. It is also a major component of other back-end frameworks, like Ruby on Rails.
What WordPress lacks, however, is the Javascript community behind it. There are many efforts in the works at the moment (like the aforementioned o2), but unfortunately WordPress and its programming language PHP are sometimes looked down upon by front-end developers. As noted by Natasha Postolovski, this is a growing concern for many leaders in the WordPress community (and for me as well). I think that the forthcoming JSON REST API (WP-API) will go a long way in showing the power of WordPress outside a traditional blogging platform, and will certainly enable many of the features I’ve listed in this article.
Looking Ahead
WordPress has begun to move in two solid directions concurrently. That of increased user experience, lowering the barrier of entry through tools like front-end editing, notifications, and enhanced workflows. At the same time, back-end technologies, like the new JSON REST API and a leaner codebase, will draw more serious application development on the platform. The NYTimes CMS is a great example of how those two worlds can be combined in a single platform, borrowing from one another.
Can WordPress be used to power the NYTimes today? Maybe, but probably not. But every issue I saw the Scoop team take on is being thoughtfully considered by the WordPress community. As the future of WordPress continues to evolve, we need to look towards its most robust applications. Or let me put it this way. If we can power the full site of The New York Times, we can power anything.
How far away do you think today’s WordPress is from powering the full NYTimes site?
Jay Hoffmann is a WordPress developer hailing from NYC. In the strictest sense of the word, he is a WordPress enthusiast with an eye for front-end development and design. He has been working with WordPress since 2006 and currently works for a popular children’s media company. This year, Jay started Tidy Repo, a curated list of the best and most reliable plugins from around the web. You can also follow Jay on Twitter.
8 Comments