Content management systems: Why we can’t have nice things?

In a rare but welcome turn of events, this week I read three thoughtful deep dives about content management systems.

1

I found myself nodding a lot at this Mediashift piece that discussed how magazines can better use analytics to determine their digital focus. Some highlights:

“We watch numbers on each of these platforms and determine what platforms can have a rich workflow and rich experience, and where we want to enhance the content with video. We also have replica editions where people are happy with just a flipbook. We make decisions on a per-platform basis [by considering] the return on investment of any of these.” —Kerrie Keegan, Reader’s Digest

“All of the different platforms — not even just production platforms like Mag+, Zinio, Adobe DPS, but also Apple versus Google versus Amazon versus Next Issue — all of those have a different set of analytics and metrics that can be obtained. Those really differ widely. It’s one of the core challenges for anybody trying to publish in this space and across those markets…. The challenges aren’t really technical at this point. The challenges are what I call infrastructure. In print, we all know what rate base is, what CPMs are going to be, what metrics we pay attention to. We don’t have the same infrastructure for monetizing digital. From an advertising point of view, does rate base matter, or is it interaction, engagement, time in app?” —Mike Haney, Mag+

2

This excellent piece from Neiman Lab gets into the inner workings of Scoop, the New York Times‘s CMS, with Luke Vnenchak. The parts I found most interesting had to do with something I always advocate: better integration of basic editorial functions, such as, oh, I don’t know, editing words, into CMSes.

Scoop incorporates a number of real-time editing options that might look familiar to Google Docs users. Different team members can work on different parts of a story at the same time: “For example, a reporter can work on the article while an editor is writing the headline and summary and a producer is adding multimedia. But one editor can’t work on the headline while another works on the summary.”

Isn’t it amazing that this very basic functionality is so hard to come by in most off-the-shelf CMSes? Additionally, for being content management systems, most CMSes are abysmal at actually managing content in the editorial sense:

One thing that is always handy in newsrooms is a system for tracking the status of stories as they move from assigning and writing to editing. Beyond knowing the status of an article, Vnenchak said they want the system to track when stories run online and in print, and how a story is performing once it’s published.

Our asks as editors are quite standard, if not primitive, from a content-making standpoint. Something as essential as status tracking being incorporated into a CMS should be common, not rare.

3

Finally, an intriguing post that could indicate the end of cobbled together, homegrown editorial CMSes. Much can be said about Google, but even its detractors have to admit that when the company puts its mind to doing something, it gets done. That something might soon be a CMS “that would unify editorial, advertising and perhaps commerce activities for media companies.”

The so-far-untapped opportunity that Google is chasing — articulated with greater frequency this year in ad tech circles — is to take a holistic approach to managing yield that spans multiple publisher revenue sources and screen form factors.

The idea that a editorial-based, unifying CMS hasn’t yet been developed is rather shocking in itself. But the arguments the article makes against Google developing such a product are the pinnacle of self-reproach and shame. It’s almost as though all of online publishing has been told by its shrieking mother, “This is why we can’t have nice things!” and internalized the message:

A CMS could be a tough sell for Google, especially as a number of publishers have lately staked their future on the strength of a proprietary CMS. Three prominent examples are Vox Media, whose vaunted Chorus CMS is considered its secret sauce, BuzzFeed, which has baked native advertising into its content platform, and The New York Times, where technology-powered storytelling is seen as core to its editorial and advertising mission. For such publishers, adopting a CMS from a large platform player like Google would be tantamount to outsourcing the very notion of innovation.

Additionally many established publishers have customized their content tools to integrate with legacy publishing systems. Many publishers use multiple CMSs, for instance a custom platform powered by Drupal alongside WordPress for blogging. So there’s a big technical hurdle to adopting any off-the-shelf solution Google has on offer. That’s setting aside the technical and human resources barriers required to migrate away from “good enough” content systems.

This last part reminds me of the great Aimee Mann song “Momentum”: “But I can’t confront the doubts I have/I can’t admit that maybe the past was bad/And so, for the sake of momentum/I’m condemning the future to death/So it can match the past.”

It seems obvious that we should embrace enhancements to CMSes for editorial, be they analytics, metrics, platforms, workflows, or appropriate ad-edit collaboration.

Read More

The differences between print and online publishing

I’ve spent the past month helping edit a book. A real, old-timey, printed-pages book, with big photos and tons of words. While it has been an all-consuming grind to move the thing from words on a screen to designed layout to perfected page, creating a book also opened my eyes even further to a handful of differences between the print and online worlds of publishing. I suppose I knew these differences abstractly — after all, I’ve worked in the print publishing world for a more than a decade and I’ve written about some of these variations before — but living the book-publishing life instead of the online-publishing one for a month solid has put these five distinctions into stark relief.

1. Standardized technology
Practically the entire print world (magazines as well) uses Adobe’s Creative Suite. If you’re a publisher, you’re using InDesign, Photoshop and Illustrator, period. Occasionally there are major disruptions —  when the industry moved from QuarkXPress to InDesign around the turn of the century, for example, after having been Quark-centric for the previous half-dozen years. If a stranger wandered in off the street to a prepress shop or printer, they’d see InDesign being used. If a college kid majors in graphic design, she’d better be taught to use Illustrator. If you’re a photographer or retoucher, Photoshop is your go-to.

Compare this to the completely opposite world of online publishing. There’s not a standard content management system that every publisher uses. Open-source platforms like WordPress and Drupal are huge and growing — they’re being selected as the go-to CMSes more every day — but they’re not widespread enough to be called a standard, at least not the way InDesign is for print publishers. More often, each Internet publishing site has its own, homegrown, cobbled together, Frankenstein half-solution, which works well enough to connect A to B, but just barely, and it is not a complete solution in the way that Adobe Creative Suite has been for print.

There’s also no standard photo-editing app: Photoshop is one option for online photo editing, but so are Pixlr, Aviary, Gimp, on and on. Even Facebook and Twitter — not to mention Instagram — offer online photo editing.

In fact, Internet publishing reminds me of nothing more than print in the 1980s and 1990s. Computers were being introduced and used to some degree for word processing, but there was no single software system for print publishing. We’d moved well beyond copy boys, news alerts coming across actual wires and traditional typesetting, but the “technology” that most publishers used then included paste-ups and X-acto knives (or some version thereof). We’re living the equivalent now online. Will the Internet standardize to a single CMS? Will there be a turnkey solution invented that takes online publishing from primordial to fully evolved?

2. Established process and workflow
The printed word carries with it an established process, one that has been more or less the way things have worked since Gutenberg. First you write the words, then you edit them, then you publish them. This is true still in print publishing. Broadly: brainstorm, assign, write, edit (line edit, fact-check, copyedit), design, prep, print, and then distribute completed, unalterable product. There are often many rounds of each of these steps, and distribution can be a months-long process. But a process it is, and one that carries a fixed order and a good degree of finality.

Online publishing, on the other hand, usurps this process from end to end; the online workflow is not fixed. Anyone can devise her own ideas and then write them. They needn’t be edited nor fact-checked, but even if they are, many people and even organizations publish first and edit later, and then republish. This doesn’t actually disrupt the distribution process a bit, because the piece is a living document that can always be changed. The immediate distribution means that readers can also respond immediately, and they do, via comments and social media, and this often precipitates yet another round of reediting and republishing.

Compare the reactions of print versus online outlets to the publishing scandal of the summer: Jonah Lehrer’s making up of quotes and self-plagiarization. His book publisher, Houghton, had to “halt shipment of physical copies of the book and [take] the e-book off the market,” as well as offer refunds to readers who purchased copies of the book. Presumably, they will actually fact-check the book sometime, then issue a new version in a new print run sometime before…who knows when.

Lehrer’s online publishers, on the other hand, merely republished his pieces with an “Editor’s Note” appended that they “regret the duplication of material” (NewYorker.com) or a  “notice indicating some work by this author has been found to fall outside our editorial standards” (Wired.com).

I haven’t discussed the cost-as-expectation factor because I want to limit this post to my observances on technology and workflow as an industry insider, but I do wonder whether, because the Internet is free, the standards are lower for both process and product. Regardless, it’s clear that making corrections as you go along isn’t possible with a printed product once it’s been distributed.

I also think that because the Internet is not only a publishing business but is also a technology business in a way that print is not, editors are cribbing from technologists’ desire to embrace iterative methodologies and workflows, such as Agile (in relief to Waterfall) — more on this below.

3. Clearly defined roles and responsibilities
Hand in hand with the process itself are the people who conduct the process. Print, having been around for centuries, has evolved to the point where jobs are delineated. It can be stated generally that in the world of print, photographers shoot pictures and photo editors select among these pictures. Designers marry text and art. Copy editors edit copy. Printers print. Managing editors meet deadlines, collaborating with all parties to get things where they need to be when they need to be there. There’s no such delineation in the online publishing world. Editors in chief shoot photos and video; copy editors crop art; writers publish. Everyone does a little bit of everything: It’s slapdash, it’s uncivilized, it’s unevolved.

I think that soon this madness will organize itself into more clearly defined roles, or else we’ll all burn out, go crazy and move to yurts in the middle of Idaho. This is happening already in small degrees in online newsrooms, and it’s starting to reach into online publishing broadly, but I have to believe that the insanity will decrease and the explicit definition of roles will advance as we sort out how it all fits together.

4. Focused, respectful meetings
It caught me off guard to realize that something as simple as speaking to coworkers is very different in the print versus online worlds, but the meetings I had when I was working on the book were a far cry from those I’ve had when I was working online. They were focused, with little posturing, corporate speak, agenda pushing or bureaucracy. At no point did anyone say, “Let’s take that offline” (translation: “Shut up”). At no point did I wonder, “Are you answering email or IMing the person across the table right now instead of paying attention to what I’m saying?” It’s pretty simple: No (or few) laptops and lots of respect for others and their abilities.

Technology likes to put labels onto concepts that publishing has been using for decades. For example, Agile has concepts like “stand-ups” and “Scrum.” Print has been having these sorts of as-needed-basis check-ins as long as it’s been around — it’s called “talking to your coworkers,” and it works quite well as a method of communication and dissemination of information. For all that’s going against it, print succeeds on a human level; technologists are playing catch-up in this respect. Whether this is because most technologists are men or most technologists are introverts I’m not sure, but the cultural and human-interaction differences are clear. If online publishing did a little more in the way of focused and respectful meetings — or maybe even fewer organized meetings and more on-the-fly collaboration — I think the industry would reap major benefits.

5. Frequency of disruption by and importance placed on email and social media
When I was head’s-down editing on paper for this book, and when I was on the computer editing, devising schedules or creating task lists, I didn’t check email, Facebook, Twitter, or really any other website except during lunch. Turns out, this behavior is fairly easy to do when you’re not working on a website yourself. I’ll admit that I felt a little out of the loop on the latest stupid thing Mitt Romney said. I missed the uproar about, next-day recap of, and explanatory cultural essay regarding Honey Boo-Boo. But I didn’t actually feel less engaged with the world. Having been completely engaged in the task at hand, I felt like the focused energy I was able to pour into the book benefited the work and my own sense of accomplishment.

When I work online I often end days thinking, “What did I actually do today? Meetings, emails, checking social media…now the day is over, and what do I have to show for it?” Quite distinctly, when I ended days on the book, I could say with conviction that what I had worked on mattered. I moved whatever I was working on from one state to the next, and I improved it when it was in my hands. It was a welcome departure.


The book will be in stores a few months. And I’m about to press “publish” on this post, which will then be live and available to anyone with an Internet connection the moment after I do. All of which serves as the starkest reminder yet about the benefits of, drawbacks surrounding and often chasm-like differences between each medium. Unlike print, for online publishing the history is being written as its being lived, and I feel privileged to be a witness to it.

Read More

Publishers tackle the outdated CMS and the damn DAM

This article in Folio about CMSes and DAMs reads like a primer for magazine-based web publishing. It’s a bit dumbed down for those of us in the industry, who’ve been having this exact conversation since, oh, 2006. But that’s precisely why this quote from Time Inc. CIO Mitch Klaif is so hilarious (and hilariously sad). “Time is currently evaluating CMS platforms that offer ‘create once, publish many’ capabilities, but Klaif notes that it is too early to know if these can meet Time’s multi-channel needs.”

It’s too early to know and the company is evaluating CMSes? Interesting spin. Here’s what’s actually going on: Time Inc. uses outdated technology that was created in 1997. I’ll say that again, in all caps: NINETEEN NINETY-SEVEN. They rely heavily on a CMS that was built in 2002. So in web years, that translates to, what, around 50 or 75 years behind the times? Consider that the company that makes the CMS Time Inc. uses doesn’t even exist anymore.

So it’s more than a little disingenuous to claim that “it’s too early to know.” They know, it’s just that what they know is either, “We don’t have a strategy except to keep maintaining this ridiculously outmoded tech that doesn’t even use languages recognized these days and for which the runway is quickly vanishing under our wheels” or “We’re scrambling to find a solution that won’t leave us in this exact same position five years hence, except no one on our tech team is remotely bold or forward thinking, so we have no clue.”

As for the rest of the article, I certainly agree that a CMS or DAM environment that makes assets “smarter” is desirable…and has yet to be built. Letting publishers “easily find and use relevant content — not only based on the article’s specifics, but also on the asset’s relevance to a particular platform” and allowing “access only to assets for which sufficient rights were secured” are both awesome ideas. But no one in publishing does this well.

I’ll grant that media tech — heck, all of tech — is constantly evolving, and often in unpredictable ways, and getting digital rights from writers and photographers is its own hell. But after all these years, no turnkey solution has yet been built. It simply does not exist, and it likely will not until actual technologists take an interest in what publishing is doing and the particular challenges the industry faces. But they probably won’t, because (have you heard?) the media industry is dying, and it’s unable to monetize itself, let alone create forward-thinking systems.

Apparently at Hearst, “Our plan is to have a system where, no matter where content is created, we’ll be able to store it in such a way that it can be easily used on any platform.” Really, is that your plan? Do you plan to do that? How about less “planning,” less “it’s too early” and more doing, building, iterating, testing, shipping code? The time is now; in fact, the time was years ago.

[Disclosure: I used to work at Time Inc.]

Read More

Where are the digital editorial workflow tools?

Mediabistro captured some great thoughts on workflow from Fast Company social media editor Anjali Mullany:

“I’m a strong believer that workflow and technology changes the kind of journalism you put out. What I’ve seen is just how crucially important it is to have in place workflows that make sense and to use technology that understands that workflow.

For example, a CMS [content management system] that has a lot of constraints behind it will literally change the kind of journalism you can produce and the workflow. …If you don’t have a great project management system, whether you’re using Basecamp or Google Docs or whatever, if that project management system doesn’t understand how your reporters operate — if they feel they have to jump between email, IM, and text and whatever — that can actually disrupt the kind of work they’re able to produce.

Trying to figure out strategies for digital newsrooms, technologically and in terms of workflow, is the biggest challenge. I think it really comes down to these hardcore, very fundamental infrastructure type problems that haven’t been adequately solved yet.”

Unrelated (yet completely related) recent story about how The Bangor Daily News overhauled its workflow to incorporate Google Docs and WordPress.

A great workflow can elevate your work and a bad one can really hold you back, and I sincerely hope we will see more efforts to improve processes surrounding digital workflow in the near future. Just as curation is getting rightly hailed as an essential element of filtering out the noise and making sense of the Internet, so too should great processes be invented to corral the historically awful editorial workflow found in typical CMSes. It’s overdue. Way overdue. Not just Asana and Basecamp and the like, but tools and hacks that work specifically for journalists and that journalists can finally put to work.

Read More