Really Strategies Blog

"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. 

Investing in RSuite CMS: A four month ROI

I’ve been involved in technology well over 20 years now and in the information industry just over a decade. In that time I’ve seen my share of project successes and failures, but one thing I have never seen until now is a publisher actually get the ROI they were expecting out of their technology investment within the first year of implementation.

Blood-Horse Publications, a Kentucky-based publisher that is the definitive resource for thoroughbred information, licensed RSuite CMS in 2007. At our recent user conference, Luther Andal, Director of Technology for Blood-Horse, provided the following summary of their investment in RSuite:

• Evaluated (through a proof of concept) and launched RSuite CMS in less than 16 weeks
• Recognized significant revenue from the data feeds and editorial content that was aggregated by RSuite in an automated fashion, which in turn populated a subscription-based website and created and distributed a daily PDF product
• Reallocated two IT staff because of the efficiencies gained (saving over $100,000 of annual production costs)
• Realized an ROI in 4 months

That is pretty impressive if I say so myself. In these days of year-long projects that go off the track (I’m thinking train track here, not horse track), it is refreshing to see a publisher with a success story by keeping the project scope tight to meet a true business need. As a best practice that we promote, keeping the scope focused on meeting specific business objectives allows for the best possible success. Just ask Blood-Horse Publications who is now enjoying the capabilities of RSuite CMS as a core technology to their publishing operation.

Stay tuned for more RSuite success stories.

"XML is like air"

I overheard a co-worker saying "XML is like air" the other day. After an initial chuckle, I find myself thinking about this statement a lot. While I agree that XML is ubiquitous I know there are many authors, editors, and production editors who still think XML is mysterious and something for the IT people.
O'Reilly Media's Start With XML project is a must read for anyone who is not breathing XML. You'll find out why you should care about XML and discover ways to implement XML upstream in your environment.

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!

The 21st century will begin in September

According to Esquire magazine, "the 21st century begins now" or rather in September when it will use E Ink technology on the cover.

Of course it all sounds quite flashy and exciting, but I can only think of the ecological impact. Esquire had to invest six-figures to hire an engineer in China to develop a battery that's small enough to supply power. The batteries are manufactured in China, shipped to Texas, then on to Mexico where they are inserted by hand into each magazine (100,000 copies will have the electronic cover out of 720,000 circulation). I hope there is a large note on the cover regarding special recycling of the magazine and battery. The flash will only last about 90 days.

New York Times article here.

Some conference recaps and digressions

It's already halfway through December and I have not yet made time to recap some conferences.  Here you are briefly with a few points from the conferences and some digressions.

ProPub Summit 2007
Participated in some panel discussions here.  Adobe, MEI, Softcare, and even Snap were well represented.  Publishing was also well represented in the participants, from tech to non-tech. 

The critical mass of publishers showed just how successful K4 has been over the years.  A few years ago, the word on the street was: "K4?  That's the publishing system that actually works."   While it has always had competitive features, particularly on the end user side, some creative implementations in the field show just how it is moving to the next level.

For example, Business Week (one of the panel discussions) has combined print and web editorial staffs and they both use the same Adobe/K4 platform.  See this case study for details. Along with the other benefits, this is a great way to start cultural transformation that can lead to print editorial finally comprehending and following downstream requirements.  Their actions (or inactions) in following content development policies can have a big impact on:

• the value of downstream content (with the application of metadata)
• the length of time it takes content to get online
• and on the staff side, the late hours put in by processing staff downstream

One more important point that I did my best to make at the conference: Scripting should be in your future.  The power of JavaScript and Adobe InDesign/InCopy (and K4) in the right hands (and solving the right problems) is amazing.  And while Adobe does a great job fitting in your feature requests, they can't do everything for everyone on every release.  This is where scripting comes in: build it yourself.

And finally, I should specially mention that MEI again did a really solid and particularly thoughtful job as host. 

Gilbane 2007
I was only able to briefly get to the floor show this year but also saw the opening keynote - so I can't comment very fully on the show.   

The keynote, on what's current and what's coming showed the great breadth of the subject area at this conference - with veteran industry representatives promoting user experience/interface, open source systems, Web 2.0, and contextual content.  (game: please match with 1.IBM,  2.Alfresco, 3.Adobe, 4.Oracle) Wow - if we could do a good mash up all of these ideas, then we would really have something.  (Mash up being the jargon of the moment).

There is an amazing array of content management systems vendors represented at Gilbane, including WebCMSes and other variations on a theme.  If you're shopping around, this conference is a great place to get a look (but note here).  I discussed this at the show with a colleague - asking why this market has always had so many players.  When will it ever consolidate?  The consensus is that CMS market is still in the early market stage - as it has been for a while. 

But why is this?   Maybe it's that home grown systems keep coming out of the woodwork and it is still very easy to get in the market place.  Or maybe CMS terminology is just too fragmented to understand.:)  Maybe the typical customer doesn't yet understand how to implement these systems to gain value in their operations, particularly if they got into it too early and/or have inflexible operations. Maybe, until recently, not enough systems have been able to provide a clear and compelling value proposition. 

I tend to look at it from a different angle.  The real hindrance to market maturity in my mind, is that there still tends to be a break down between company strategy and a compelling business case for a CMS.  This may be because up until recently, a CMS didn't really seem to fit most strategic moves.  If you have a strategy for increasing market share, then how does a CMS help?  This has started to change though, with some changes in the market and some evolving thinking.  In any case, being able to make this linkage work, with solid analysis, will compel successful implementations.  When successes reach critical mass, and real leaders become apparent, the market will finally mature - and consolidate.

The architect and the interior designer

I heard a story the other day about a store owner who hired an interior designer to design her new retail store. With great enthusiasm they set about designing a great space. It was going to look great - and it did look great in the sketches. So she submitted their plan for approval.

What she didn't know and what she found out very quickly is that she was required by law to hire a registered architect to draw up the submission plans. So the designers sent their plans and drawings to an architect to 'just draw them up'.

Unfortunately, the architect found that there was no HVAC system in their design - oops. Bathroom design was not to code, as were several other things. Well, everyone scrambled, and after much brouhaha between the groups, as you can imagine, the design was revised and I suppose everything turned out fine (if more expensive). But it was touch and go for a while.

The lesson: work with an architect from the beginning, so you can create with the required constraints in mind.

Does this story sound like anything related to print-to-XML/web workflows and print content production in general? If so, then who is the interior designer? Who is the architect? And what is the HVAC system?

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.