editorial workload

How many millions of dollars, how many miles of code, how many lifetimes of human productivity have been lent so far in the service of replicating on the web the ease-of-use and sophistication that print publishing has achieved just in the last several decades?

And we’re still not there. But thankfully we’re getting close. Just maybe not fast enough.

For those of us with longer memories, this is all a little reminiscent of the dawn of desktop publishing 20 or 25 years ago. Back then moving text around required not just an eye for symmetry but also some dexterity with the typesetter’s tools — an Xacto knife to cut Lintronic type, and a pica ruler (or “pole”) to make sure everything was placed straight and even on the layout board. I became so adept at using both that I sometimes came home with waxed pieces of type on my shirt sleeves.

The introduction of DTP was joyous for most publishers. Can we say the same about a typical web CMS?

How joyous was the introduction of desktop publishing, to suddenly have sole control of every element on a page with a swipe of the mouse or a peck of the keyboard. Oh, the transition was not instant. Early versions of DTP software like Aldus Pagemaker and Quark XPress were complicated enough that a whole new occupation sprung up: “desktop publisher.” Try finding that title on the job boards today.

DTP instead quickly became so mainstreamed — such an extension of the eye and hand — that its reins were placed where they should be: in the hands of graphic designers and editors.

Exactly where control of the web CMS should be today.

And in that spirit…

Here’s what I’d like to see in a CMS:

The bulk of web content should be easily edited and moved around on a web page by nearly anyone, no HTML knowledge needed — like an extension of their own hand. This means web developers are never needed for workaday content — just for special applications like high-level interactive elements and for moving to new platforms. As I say we’re nearly there on this count, and WordPress (thank you) may be its highest manifestation so far.

Bulk content should be easily portable across any publishing platform — e.g., from QuarkXpress right into WordPress or vice versa. Eh, we’re not so close here. A web CMS has a bias for the web; DTP has a bias for print. Today’s harried content producers make no such distinction. XML offers much hope but the reins are still in the hands of web developers. CMS suppliers: Tear down this wall!

Editors should be able to easily create basic tables and charts — static and interactive; for later enhancement by designers / developers if necessary — right in their one-screen CMS. Some freestanding applications are out there like Piktochart but nothing is right at the editor’s fingertips at the point of origination of content.

Content producers should be able to get an instant preview of what their page-in-progress looks like on any application — print, browser, smartphone, tablet, etc. In DTP we called this WYSIWYG (what you see is what you get) and it’s needed still. Responsive design is on the cusp of making this happen for the user but the next logical step will be making sure the content producer can see it too, while they’re working, on any given platform.

The issue of image file size needs to be resolved: print wants hi-res for quality, web wants low-res for page speed, and publishers have to retain both versions. When can we use just one? This issue may be forced by the boom in publishing for hi-res tablet displays.

DTP operates in a controlled environment, of course: Its sole destination is the printing press; whereas web content of course relies on the Internet and must be legible on multiple devices, operating systems and devices, and all this keeps changing. So it wouldn’t be fair to hold DTP and a web CMS to the exact same expectations for ease-of-use. But I dare to dream…

Like this:

Dwight Eisenhower, who of course was a master of logistics as well as a general and U.S. president, was famous for having said:

In preparing for battle I have always found that plans are useless, but planning is indispensable.

In its own modest way the same could be said of content planning. Rare indeed would be the edition that comes together precisely the way it was planned. Stories and relatively priorities change. Cover concepts evolve through brainstorming and refinements. Ads come in (or don’t).

So is planning a waste of time? Absolutely not. Planning affords choices and flexibility – important factors both quantitatively (“do I have enough stuff?”) and qualitatively (“do I have enough GOOD stuff?”). In my own issue planning, this is how I’ve sort of liked to see the pipeline at any given time (and when I say “pipeline,” I mean content that is “in” or is “committed to and on its way”):

For instance, for the immediate next print issue I always want to have 125% of what I think I need because a story may fall through, an 8- or 16-page form may be unexpectedly added, etc. And I’m always trying to modulate that mix of timeless (often outside-authored) and timely (usually inside-written) – dialing up the relative ratio on the newsy stuff as each issue deadline approaches and as market conditions and audience needs dictate, knowing our staff editors can turn these timelier stories around on a dime and to our specifications without a whole lot of time-consuming to-and-fro at the 11th hour.

But no matter what your system is for planning – be it mighty or modest – know this: Any planning is better than none.