Really Strategies Blog

Why newspapers have failed

I by no means profess to know much about the newspaper industry.  I read newspapers both online, and yes, in print, but that's about it.  When it comes to analysis on the newspaper industry, I leave it up to the experts such as Ken Doctor who writes his analysis in the Outsell Insights daily newsletter. 

I recently came across an article in the Columbia Journalism Review by Walter Pincus who writes for the Washington Post.  His article - Newspaper Narcissism, Our pursuit of glory led us away from readers - is a very good read.

Some interesting facts from the article:

• An average reader spends 25 minutes reading the print newspaper
• There are 110 million daily readers of print newspapers

• Consumers of online news generally read between 10AM and 4:30PM.  Hmm, don't we all have a job to do?  Pincus' point is that consumers who read online generally only have time to read headlines. 

I didn't take away from this article that Pincus was some old guy complaining that it is not like it used to be but rather that the industry has taken the wrong approach over the past few decades.  It is worth the time to read this article if you are interested in a good retrospective look at the newspaper industry.

Saving newspapers, one article at a time

Good article by Walter Isaacson, formerly of Time, on how to save the newspaper industry.  Content micropayments - an old idea with a new endorsement.

My comment would be that a large association of newspapers and magazines should create its own micropayment system - open to all.  That way it would be ubiquitous, which is the only way that micropayments for content will work.  Otherwise, users will just click to something else. 

You can't rely on a generic micropayment system that may never materialize - or it will be too late!  Steve Jobs created micropayments for music all by himself.  It helped that a majority of music could be easily found and browsed in iTunes.  I don't think it will work that way for online news, though if anyone can do it by themselves, it would be Steve Jobs.  Otherwise, micropayments has to be introduced by a majority of publications and include a majority of publications. 

I agree with Walter, it may be the only way newspaper companies will survive. 

"Barbarians at the gate?" NFAIS Conference

I was highly interested with the title of the upcoming 51st Annual NFAIS Conference.  Quoting from the brochure: "Barbarians at the gate?  The impact of digital natives and emerging technologies on the future of information services"  Essentially the gist of the subsequent write-up is that those who were born in the digital era and have almost exclusively known digital communications, are getting ready to storm the world and start driving the information technology revolution from inside companies and organizations (presumably the way they have with consumer communications). 

How perfect.  This is what all of us in the publishing technology community have been waiting for and have started to see out there in the last few years.  It means that it is less and less important for the publishing technology revolution to be driven by the visionary technical whizzes.  Less problematic to convincing companies to adopt more and more advanced digital workflows and systems.  As the 'digital natives' come into their own, demand for better systems is beginning to drive things.  What a great thing to happen in publishing technology!  Of course this process proceeds differently in different publishing verticals, with more scientifically oriented (e.g. technical) companies already there.  But now we can expect the non-science oriented publishing to come aboard. Magazine and book publishers should be coming around, and goodness knows, we have been waiting for this moment in educational publishing - the slowest of publishing verticals to change. 

Why a CMS? why now?

Maybe you've got a gut feeling that it's time to buy a content management system.  Maybe you've  gotten a demo of one and gotten general buy-in from the team.  Now it's time to justify it financially. 

The first thing to keep in mind is that a CMS is a tool.  It is a tool that serves two purposes, so there are two angles that can be taken for justification.

First, and easiest, if most mundane, a CMS serves to wring out non-creative tasks from content development.  Think about how much time is wasted in content production: routing, tracking, moving, backing up, converting from one format to another, cutting and pasting, rekeying, etc., etc.  All of this takes time and an efficient publishing operation will reduce this work to a minimum by using a contemporary CMS so that more resources can be put into making the best content available.  If you produce a lot of content, then these numbers may surprise you once you pull them together. 

Ordinarily, publishers won't want to rock the boat with this stuff, it just causes angst and is hard for management to relate to hot topics in expanding market presence, competing with other publishing organizations, etc.  However, many publishers are feeling angst anyway, and have no choice at this point.  Profitability is a serious issue as is well known.  But more compelling, publishers are now feeling the weight of these non-productive tasks now that electronic distribution of content has expanded so dramatically - and along with it, manual production tasks.  Content must be agile, and this won't happen if production staff or offshore vendors have to touch every piece, every time.

Second, and much, much more interesting, a good CMS can put some forms of content distribution in reach that were never in reach before. In this sense, a CMS can be part of a new initiative to compete in the publishing market. For example, a traditional publisher may want to slice and dice their content to form specialized publications for niche customer segments.  A licensee might be willing to pay for certain topics of content, if it can be delivered in usable form.  In many cases, this was never seriously considered because it was never financially possible before - there would have been too much manual and editorial labor in finding and organizing appropirate content, and producing it in appropriate forms.  But today, with a native XML CMS like RSuite, this is financially possible.  And the first publishers to execute well will be able to create specialized demand and win customers.

Maybe you pay for your new CMS through ordinary savings, but take advantage of it by using it to develop new publication types.  Whatever your strategy, the technology is here, is now, and for the new generation of systems, particularly RSuite CMS installed on a Mark Logic repository, the technology actually works well enough to be cost effective.  We know this because our customers are starting to report savings and interesting new revenue stories to us.  All we can say, then, is: go for it!

A coffee, donut, and some Proust....to go

My colleague shared an interesting quote from today's Outsell newsletter:

Reading on mobile phones is becoming more common both in the US and abroad. "Literature on mobile phones is massive in China," says general manager of Penguin China, Jo Lusby. "The tube is so packed in Beijing you can't physically open a book, so everybody is reading on their mobiles."

Single source knitting

I love my job at Really Strategies and I love knitting. So you can imagine my delight when I read about News Knitter, a data visualization project that focuses on knitted garments as an alternative medium to visualize large scale data.

Basically, XML from RSS feeds are gathered daily and absorbed into a pattern generation program. Next a computerized flat knitting machine produces the final output: a knit sweater.

The gallery Ars Electronica at the Kunstuniversität in Linz, Austria will exhibit a collection of these sweaters through September 11th. If anyone attends, please tell Ebru Kurbak and Mahir M. Yavuz (the artists and technicians behind the project) they have at least one groupie here in the US.

The big content system integration II

I've modified the 'big' diagram from the first post on this topic to show a circular content flow - now called editorial flow. 

Please find it here: Download the_system_ii.pdf. 

The diagram is still more conceptual than technical.  Of course at some point this thinking needs to be specialized for the particular publishing vertical, product needs, and company needs.

A few thoughts:

1. Shows content editing flowing in a circle.  Enter at any point and proceed downstream. That is, start  developing a print article or publication and complete it, then proceed to develop it into a web article or publication.  Or visa versa.

2. Prior to entering a print or web editorial workflow there is a content adding, packaging, editing phase, where it is assumed that a web interface will allow review of content sources and collection into the initial manuscript for the subsequent print or web editorial workflow.  This might, for example, allow enhancement of an article - with a new sidebar, for example, as it proceeds downstream. 

3. Implies content reuse if the circle keeps flowing.  The circle can also stop at any point if needs are met.  Some publishers might stop at having a print and web output (in any order), some might stop with either a print or web output, some might keep the cycle going indefinitely, building a large content repository over time (e.g. educational publishers).  The diagram also implies content maintained as XML rather than being imported and exported from editorial/workflow tools.   

4. It has a central repository built of two fundamental parts - XML and binary content (images, etc.).  Work done in page layout tools/editorial tools/workflow tools is transitory (though might be archived).  The purpose of the repository would be to accurately manage 'content' of published products and to also provide a starting point for initial manuscript creation for the next stage in the cycle.

5. Upon completion of the web or print cycle, a number of XML enabled exports are possible along with the main article/publication produced.   This is a requirement of some publishers, and certainly there for the taking, if content is accurately managed as XML.

Well, readers, what do you think?  Does it match your thinking?  Should we keep going with this?

What I want from Adobe - x-ray file formats

Consider The big content system integration diagram (draft 1).  What are the bottlenecks for the content stream?  Well if what I'm doing is any indicator, importing and exporting from InCopy or InDesign still has a little friction to it.  This is being addressed by Adobe progressively - see CS3 (yay!) for example over CS2.  Also being addressed by Softcare and other companies, again progressively.

But is there a fundamental change that can happen here?  Can we get XML that can pass through Adobe formats frictionlessly like Superman can see through walls with his x-ray vision?  (Digression here: There is a surprising amount of controversy on the Web about Superman's powers - many self proclaimed pundits seem to say that his X-Ray vision is unrealistic!  Not science that it is caused by low gravity on his home planet?  Baloney!)

Maybe the problem isn't that content can't yet be imported and exported seamlessly, maybe it is that content shouldn't be imported and exported at all.  If Adobe considered InDesign/InCopy not to be a holder of data, but an aggregator of data for print layout, then we might start getting somewhere.  Already, images are externally linked, why not, we might then ask, have text objects be externally linked?  I'm not talking about the page geometry, etc. that might live inside of an InCopy document.  I'm talking about just the text - and as XML if you please.

If Adobe therefore allowed XML content to remain external as files, and it allowed all external content, XML or images, to be linkable via HTTP protocol or otherwise, then we might have a situation where media and XML management systems could maintain content continually - without having to messily import during print production and export after print production.

Think of all the advantages!  Tremendous.  Metadata could be added externally, preparation for web could happen simultaneously. And Adobe page apps would still manage page layout and editing within page geometries so no skin off their nose.   Of course, this is not an easy thing to accomplish - but it is the logical future state - each format to its own system, with specialized apps consolidating, editing, and arranging the last mile of content.

Print and web: one ecosystem?

Ah, content, what are you doing to our beloved work culture?  We were happy when the world was simple!

Print production, so well known, so comfortable in its methods of achieving uncomfortable deadlines.  It was so simple when 'this is how we do things here' easily fell from our lips. 

Web production, so comfortable in it's freshness and technical knowledge.  Yet it still had a world all to its own.

But now, maybe the idea of 'content' is just starting to bring each world into the other's focus.  The definition of content is not really tied to any medium - it lives outside of the reality of 'deployment', of paper & ink, or web browsers. 

Clearly the 'star' theory of content (circa 1999) is long dead, where content is produced centrally and sent seamlessly to different mediums.  Content cannot live completely outside of its context.  It must be edited to each medium.  It can start, end, and be stored centrally, in something like an RSuite (XML CMS), but it changes as it moves to print, or moves to web.

With today's tools, many publishers are living in a world where content flows from manuscript-to-print-to-web.  And where the most efficient content development ecosystem will only be achieved if upstream (print) production and downstream (web) production work to accommodate each other.  Its one ecosystem after all, where the same 'content' travels through both of these environments.

A content hand-off at the the dividing line between these worlds was the first step in fitting these two systems together.  Loosening and blurring that border seems to be the next step as we forge ahead.   A single content ecosystem demands it.

A bit like making sausages

How do you make XML?  Well, as the old saying goes, it's a bit like making sausages.  You don't want to see them made, but they sure taste good.

By the way, a quick search on 'a bit like making sausages' reveals that almost everything is a bit like making sausages.

I was reminded of that saying when 'opening up the hood' on a pre-export InCopy file variant for a client the other day - that is, right after the final preparation script was run and right before triggering the XML-Exporter.  I think those in the room actually took a step back, with the look of someone seeing a meat grinder in action for the first time.

There was tagging all over the place - and in many different forms.  All of it was either automatically generated or semi-automated, with scripted support.  It looked awful!  Precisely.  That is because the final form was a machine readable document no longer built for editors or designers.

Well, we checked in the document to the XML export status in K4 and Presto! we had our lovely, tasty XML files - soon to be ready for consumption by a Web CMS.

Lovely.

Funny, but right now I cannot stop thinking about those wonderful sausages you buy in the country markets in France.  Truly you haven't lived until you have tried them.  (Apologies to other national sausage makers - I have not done the sausage travel circuit as much as I would like to.)