Today I lodge my complaint about content management systems (CMS).

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.

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…