Really Strategies Blog

"Journalism is the act. Newspapers are the artifact."

The past week was flush with conversation (ie, Tweets and blog comments) about Clay Shirky's rousing blog post Newspapers and Thinking the Unthinkable.

Read it. Read it in its entirety.

One comment on the post from Mark Bertils that won't leave my head is "Journalism is the act. Newspapers are the artifact."

I make a habit of looking up known definitions in the dictionary (and I do mean digital not the heavy tome I have here at my desk) because I find additional thought-provoking but commonly-known information. While reading the definitions of newspaper and newsprint I am reminded that the essence of the newspaper business is timeliness. Why were evening editions so popular in the 1950s and early 60s? For the same reasons that Twitter and RSS newsfeeds are so popular now. Timeliness.

I do lament the demise of print and I don't like seeing my Google news alerts on this topic competing with my spam folder in terms of volume. But I am heartened by the fact that journalism, reporting, writing, editing, authoring, these beautiful professions whose fundamental job is the exchange of thoughts from one mind to another, are not going away.

RSuite CMS provides loud and clear answer for Audible.com

We are often asked by publishers to describe the real business impact RSuite CMS has on our clients. Along with my previous post on Blood-Horse Publications, Audible.com is another client that has leveraged the power of RSuite to realize its business goals.

Audible, Inc., an Amazon.com, Inc. subsidiary, is the leading provider of premium digital spoken audio information and entertainment, on the Internet.

In early 2007 Audible.com launched an aggressive project to revamp their entire metadata program to better manage and process the metadata files they receive from their publishing partners.This program had the following business objectives to meet:

• Ensure error-free metadata by using publisher or publisher aggregators as the source of data, and by developing new tools to drive, search, browse, and publish to store functions off this sourced data.
• Ensure the ability to identify Audible products on partner sites by providing ISBNs that correspond to the downloadable digital binding with each product in feeds to partners, wherever and whenever possible.
• Reduce the occurrences of human error by automatically populating data into web site databases, from the sourced data.
• Improve findabilty, searchability, and marketability of products by standardizing keyword, category, authors, contributors, and publishers.
• Improve royalty systems by making contract entry a requirement for any product being pushed to an Audible site.

During a 4-week proof of concept (POC), RSuite was configured to prove out several use cases:

1. Leverage RSuite’s workflow tool to ingest ONIX feeds and audio files
2. Apply additional metadata (both manually and automatically)
3. Distribute the appropriate content packages to target delivery sites.

During this stage many business rules were also documented that were applicable to improving Audible's business opportunities. After a successful POC, Audible.com selected RSuite for its metadata and aggregation solution.

RSuite became the framework upon which Audible crafted solutions to meet all its requirements: workflow, business rules validation, content aggregation and delivery. In 6 months, RSuite was configured and implemented to become Audible's workflow tool, which enables seamless transfer of content from publisher feeds to web site-ready files.

Now after using RSuite for over a year, Audible has realized its goals of integrating a tool that would satisfy the business objectives and show a return on investment quickly. As Art Zegarek, director of data architecture told our team, “RSuite has become a very critical system very fast!" It is satisfying to know that RSuite is helping an aggregator such as Audible.com meet its business objectives every day.

What is the difference between RSuite CMS and MarkLogic Server?

Publishers often ask us “What’s the difference between RSuite CMS and MarkLogic Server." Great question!  The most straightforward answer is that RSuite is a content management application and MarkLogic Server is a database. It’s that simple.

MarkLogic Server is an incredibly powerful XML repository on top of which many publishers have built fantastic applications, O’Reilly’s Safari U, Elsevier, and Congressional Quarterly, to name a few. These custom built delivery applications are just one way MarkLogic Sever has been used.

RSuite CMS is also an application built on MarkLogic Server. RSuite CMS sits on top of MarkLogic Server to leverage the native XML repository (i.e., database) and search capabilities. Without a database, RSuite would not be able to run – just like a car needs an engine. However, without a chassis, steering wheel, electronics, etc., the engine would be of little use. Therefore, think of RSuite as the ignition system and think of MarkLogic Server as the engine. Both are very important to content management.

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.

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 Evolution of Content (and Us)

Four and a half minutes that are worth 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."

Online-only success story

Last April (2007), International Data Group (IDG) transitioned its magazine, InfoWorld, into an online only publication. A year later, the company reports

...the InfoWorld Web site is generating ad revenue of $1.6 million a month with operating profit margins of 37 percent. A year earlier, when it had both print and online versions, InfoWorld had a slight operating loss on monthly revenue of $1.5 million.

My colleagues and I attempt to track the demise of print publications  that have been discontinued in favor of sole digital delivery of the content. There's always a twinge of sadness documenting this trend, so it was nice to finally read this report in The New York Times.

Call for Participation: DITA 2 InDesign Plug-In

Really Strategies is supporting the creation of an open-source, community-developed DITA-to-InDesign plug-in for the DITA Open Toolkit. We are donating a small amount of existing code (some early XML-to-InDesign transform experiments) and development effort over the weeks and months to come, as well our existing expertise and experience with both DITA processing and getting arbitrary XML into InDesign.

The project is managed on SourceForge as the DITA2InDesign project.

There's nothing much there now: we're just getting started with development and are actively soliciting contributions from others in the community. See the project's Web site for details on the project and how you can help us move it forward.

Our goal with this project is to help make it easier for Publishers, in particular, to take immediate advantage of DITA, or at least experiment with it with a minimum of up-front effort, by fostering the creation of a print production tool chain that uses tools both familiar to Publishers and capable of meeting Publishers' typographic and composition requirements.

With DITA today you can create printed output using the XSL-FO-based plug in. That plug-in is adequate for technical documents and, with a little effort, you can customize and extend it to reflect corporate branding and specific page layouts.

However, the inherent limitations in the XSL-FO standard and its available free and commercial implementations make it incapable of producing the more sophisticated layouts required by most commercial publications and more heavily-designed technical documents. Thus the need for something like the DITA2InDesign plug-in.

The goal is for the DITA2InDesign plug-in to help bridge the gap and make it as easy as possible to use InDesign with DITA-based content.

NOTE: While the plug-in will go long way toward automating the layout of DITA-based content with InDesign, it won't be able to do everything. There will always be a class of documents that require more automated layout sophistication than the plug-in could hope to provide. For those documents, the Typefi product offers a very attractive solution. Typefi provides very sophisticated automation features for rendering XML content into InDesign layouts. While one doesn't exist today, it should be fairly easy to create a generic DITA-to-Typefi "CXML" process that would allow you to use existing Typefi-based InDesign layouts with any DITA-based content.

Live DITA Application: FASB U.S. GAAP Codification

The work of all accountants doing commercial accounting in the U.S. is governed by the Generally Accepted Accounting Principles (GAAP), created and maintained by the Financial Accounting Standards Board, a member-supported organization mandated by the U.S. Congress.

Historically the GAAP has been created as a mishmash of different documents and supporting interpretation and commentary. There was no single organizing schema or source. In short, it was essentially impossible to determine whether or not you had found everything relevant to a given accounting issue.

To address this problem, the FASB decided to create a new all-encompassing classification taxonomy for the GAAP and codify all existing GAAP standards under this taxonomy. This project has been going on for over four years and has resulted in the Accounting Standards Codification, or ASC. The ASC content is currently undergoing an extended period of public review and is available through the FASB ASC Web site: http://asc.fasb.org/home.

While the ASC taxonomy itself was a major achievement, the codification activity was a daunting editorial process in which all the existing standards content had to be re-authored in a new form that directly reflects the taxonomy. To support this activity the FASB decided to use an XML-based system, which should come as no surprise.

But beyond that, the FASB realized several important things:

• The GAAP content is highly modular
• The GAAP content can be organized in many different useful ways depending on how it is being used:
  • By subject
  • By industry
  • By business process
  • By what's of immediate interest to a particular person researching a problem or set of problems.
• The GAAP content requires rich metadata to enable accurate search and retrieval as well as binding to the new ASC taxonomy
• Licensees of the content will want the XML source and will want to be able to use it with as little effort and expense as possible
• The FASB does not have huge budgets for XML application development and implementation yet needs non-trivial systems for authoring and managing the GAAP content through its editorial processes as well as for delivery through the authoritative FASB Web site.

Given the foregoing, the FASB realized that a more traditional XML application, while possible, would not necessarily be optimal and would likely be prohibitively expensive and would not meet the requirements of licensees for ease-of-use of the XML content.

However, a DITA-based application would satisfy all these requirements. David Prather at FASB realized that the GAAP content could be modeled quite handily using DITA with some GAAP-specific specializations.

David worked out a clever way to use DITA maps to manage the organization and packaging of the codified GAAP content and hired me to design and implement the necessary GAAP-specific specializations (as well as do the data conversion from an initial XML format they had used for the initial codification editorial work). The FASB selected Ovitas to implement a new editorial support CMS system as well as the dynamic delivery system used to serve the ASC content through the FASB Web site.

The project went remarkably quickly--we had working DITA specializations defined and in place in a matter of weeks and the models required only minor refinement as the system implementation progressed, mostly stemming from new understandings of the underlying content as the codification editorial process approached completion. The CMS and Web site implementation went equally smoothly (remarkably so in my experience building such systems).

Because we could use the free DITA Open Toolkit to generate HTML sufficient for internal review of the codified content we didn't need to invest any time or money in acquiring or building rendering support just to support internal Q/A of the DITA content, a significant savings. Essentially, it allowed one part-time consultant, me, to do what would in the past have required a team of three or four consultants months of work to implement. By the same token, we were able to use the off-the-shelf DITA support in XML editors like Arbortext Editor and OxygenXML, removing the need to invest in document-type specific editor configurations and customizations, again saving weeks or months of consultant time. I think I spent about two days coming up to speed on how to configure Arbortext Editor to work with specialized DITA document types and about 1/2 day creating the necessary configurations (it's essentially a copy and modify process that I can now do in minutes).

Likewise, the Toolkit means that licensees can do *something* with the ASC content immediately, as well as giving them a solid base from which to develop whatever internal processes they need. Large publishers with existing XML infrastructure can of course apply that, but smaller publishers with little or no XML infrastructure can still take immediate advantage of the ASC XML source.

The ASC content is currently undergoing an extended period of public review and is available through the FASB ASC Web site: http://asc.fasb.org/home. The content is served dynamically from a slightly sanitized version of the DITA source--it is not static HTML pages generated from the DITA source.

The FASB ASC application is a working example of how the unique features of DITA XML applications significantly lower the cost of building this type of system while enabling significant value for the DITA-based content itself.

One interesting side effect of this system is that most, if not all, of the FASB's licensees, which include all the big name publishers and many smaller ones, will end up with both DITA-supporting internal systems as well as internal DITA expertise that can then be quickly and easily applied to any other DITA-based content, regardless of its markup details or subject domain. That seems pretty interesting to me....