Really Strategies Blog

The Oxford University Press Licenses RSuite

  We are delighted to add the Oxford University Press to the RSuite customer list.

Oxford University Press (OUP) is using RSuite to transform its publishing operations. RSuite offers OUP the tools and the facility to automatically ingest and store content from its authors and other content suppliers. RSuite also allows the delivery of OUP content both manually and automatically to multiple targets in various formats. Examples of content delivery range from XML documents that are converted to Word and sent via email for editorial updates to batch delivery of XML and media files based on user selection and other criteria for web site updates.

[Full press release here.]

Using a Wiki as a CMS Editorial Tool

I visited a client recently and had a fascinating conversation around how they are using a Wiki as an editorial tool.  To set the stage, this was a manufacturing company who has a technical publications department responsible for all product documentation.  Their engineering department is responsible for creating the majority of the content they publish with the goal of quickly publishing content to their clients and partners.  The technical publications department is responsible for publishing quality publications that follow standard formats and along a defined publications schedule.  Can you see where this is going?

On one side you have an engineering team who has a vehicle for creating and publishing content to their product portals quickly using a Wiki.  On the other side is the technical publications department who has a publications process using a CMS to create content according to content standards and timelines.  Engineering desires to have the flexibility to publish content at any time to the partners who need the content.  Speed to market versus content accuracy and presentation.

It was clear from the conversation that the Wiki approach to content development was causing stress among the technical publications group, and rightly so!  The technical publications group is all for embracing new technology, but I'm not sure the business rules around the Wiki developed content were fully explained to either side.  Which organization has the repository of record?  Who is ultimately responsible for the quality of content.  Along with quality, who is responsible for any liability issues that arise? 

I'm sure over time a Wiki strategy will be defined and the business rules for incorporating content into the traditional CMS environment will be worked out.  In the meantime it would be interesting to hear how others have embraced Wiki technology in the traditional CMS environment.

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!

An interesting content experiment

German publisher Bertelsmann is publishing "The One-Volume Wikipedia Encyclopedia" in print. The book will go on sale in September for 19.95 euros. The initial print run is anticipated to be about 20,000 copies and Bertelsmann agreed to pay one euro per copy sold for use of the Wikipedia name.

“We think of it as an encyclopedic yearbook,” Dr. Beate Varnhorn [editor in charge of Bertelsmann’s reference works] said, leaving open the possibility of new editions if the 2008 version is successful.

It will be interesting to see what happens this fall.

Inhalt Wiederverwendung auf Deutsch...viel Glück.

Read the full story here.

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

Complex layout, XML and a little...Obama?

Complex layouts.  Full automation.  That is what many of us are working toward.  You know what I'm talking about - Layout to useful XML (and back again) with speed and very little increase in manual effort.  It's achievable.  But it means changes to production practices no matter what technology you use.  Change is coming.  And change is possible - if you don't believe me, go ask Barack Obama.  So if you're on the Obama bandwagon - and after Iowa, any candidate's bandwagon, red or blue - you must believe you can change production practices, even in the most intense and fragmented development operation.  Think about how hard it is to change the country - what's change in the publishing trenches compared to that?  I'm asking you to believe... :)

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?