Really Strategies Blog

eMedia Professional Certification Program Raffle

Don't let anyone tell you there is no such thing as a free lunch...(in fact, we have them once a month at the office but I digress) or in this case...a free eMedia Professional Certification.

IDEAlliance just launched its eMedia Professional Certification (EMPC) program. This program is offered in four distinct blocks of courses. Each block comprises a series of webinars that covers a range of topics related to eMedia Publishing, including

• eMedia Workflows’ Impact on Organizational Structure and Partner Relationships
• Controlled Vocabularies, Taxonomies and Ontologies
• XML Under the Hood: What Everyone Should Know
• Which XML Workflow Really Works?
• Integrating DAM and Content Management

This program runs from March through November. All classes will be recorded so publishing professionals can join at any time. 

The entire session costs $1800 but Really Strategies is raffling off one free pass to any individual who provides the most compelling reason why he/she should win. Yes this is not at all scientific but that means you can be as creative as you want to be.

Either submit a comment below, including a valid email address so I can contact you OR send me an email with your contact information.

More info on the program is located here.

RSuite Engine now available

For organizations that want to jumpstart development of content management projects on top of MarkLogic Server, the industry's leading XML server, Really Strategies now offers RSuite Engine.

RSuite Engine is the foundation of RSuite CMS and provides a robust API for technical teams to accelerate the development of sophisticated content management applications.

Read more about RSuite Engine here and here.

Strategies for successful XML content management initiatives

With a mandate to implement XML, and content management across your organization, how do you develop a strategies for a successful initiative?  And what are the pitfalls that detract from success?

In a large organization, does it make sense to centralize the effort?  For example, should you begin with alignment on XML formats and metadata across the organization, and then proceed to an across the board CMS implementation?  Or should you begin with alignment on a CMS technology?  Does it make sense to have one division or group pilot an effort so the organization as a whole can learn from the experience?  And then roll out to other divisions?  Or does it make sense to let all groups move forward at their own pace?

The answer, of course, is, it depends.  It depend on where your organization is at the moment, its culture, and your ROI period and expectations.  But, perhaps more importantly, it depends on the capabilities of the relevant technologies out there - how fast they can be deployed; how flexible they are once they are deployed;  how fast they are changing in the marketplace.  If you're implementation is expected to be rigid, or the tools you have require a certain level of rigidity, then it might be best to go top down and align the organization as a whole, then implement as a whole or in a unified manner.  But if you are expecting to be flexible, and your technology, formats, etc. can be flexibly configured, perhaps bottom up is the better route.

RSuite CMS places itself in the flexible category, which allows the flexibility of any of the possible implementation approaches. 

Start With XML Conference

Attended the Start with XML conference on Tuesday and am happy to report it was excellent!  This bodes well for the next O'Reilly conference - Tools of Change, where we will have a booth and where our own Lisa Bos will be speaking.

There were a lot of highlights for a single day.  The morning keynote by David Young, Chairman & CEO of Hachette Book Group USA was an engaging overview of why to start with XML. (All presentations are on the Start with XML conference site, though some may miss something without the talk).

Several presentations by top production leaders were also interesting.  In particular, I'd like to point out the accomplishments of Rebecca Goldthwaite's team at Cengage Learning in developing standardized design that does not appear standardized(!).  Amazing that so many strikingly different appearances can be auto-generated from XML and layout templates.  It just goes to show that their design teams 'get it' and more importantly, that design teams in general can remain highly creative in the world of XML.  Take this to heart people!

But the presentations were all very good.  If I start mentioning all the good ones, then I'll be mentioning everyone.  I think this may indicate a watershed year - the number of people who have quality knowledge of the business, technology and people issues in developing an XML workflow is potentially reaching critical mass.  Perhaps we are ready to move forward in publishing after all.  If Start with XML is any indication, then the larger Tools of Change conference will be a watershed event this year.  It's a very exciting time.

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.

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

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

Quick thought on XBRL

I was just reading Mark Logic CEO Dave Kellogg's post on XBRL and Microsoft's claim to be the first company to use it.  After taking a look at the filing from Dave's blog link, it struck me that:

- The poor pilot companies that are outputting XBRL - presumably by hand!  This is clearly no language to be editing or even converting without software/system support.

- Wouldn't it be great to have a publishing oriented XML CMS like RSuite to help author, edit, and pull required information together! 

Achieving automation: InDesign/InCopy to XML

InDesign and InCopy are built for desktop publishing - giving great power to design and editorial.  This is all great news.  However, it makes exporting XML rather tricky - particularly the development of fully automated XML exports.  Sure you can capture XML coming out of these applications, but can you really push that XML into your CMS without having text processing look at it? 

We've looked at this over many projects and the key issue is, of course, the discipline required by each group in the process.  If they don't follow the rules, then their content might not match what your CMS is looking for.  A deck must be labeled as a deck somehow.  Likewise, a B-Head or run-in head must be labeled appropriately. There are also customer or genre specific structures and metadata that must be maintained - with paragraph or character styles (or one of several other techniques).

The point is that you can't look over everyone's shoulder.  Styling and other structure related errors are bound to creep into your content on occasion.   If you only want to accept well structured XML, then you need the capability to automatically identify errors and only ingest acceptable documents.

While you can create scripts to QC the content during production, this poses a scripting update problem every time you want to change your format structure (every time you do a redesign, perhaps).  And while scripting is extremely powerful in CS2 & CS3, it is pretty low level stuff and time consuming to produce anything complicated.  It is also problematic if you don't have a specialist on staff.  Better to write scripts once and move QC somewhere else.

So what to do?  One solution is a Schema (or DTD) validation technique that allows this QC operation to proceed during an automated export.  The Schema will be more restrictive than just looking at Adobe structures - it will overlay structures specific to your content.  And while updating a schema requires some technical knowhow, it is more straight forward and much faster than updating scripting of any kind.  The reason, of course, is that this is what Schemas are meant to do well.

Using a Schema to validate InDesign/InCopy content can detect a surprising number of human errors with styling and other structuring techniques.  Not all errors, but it can do a solid job if your content is moderately complex.  Content flows into an interim format and is validated before being transformed into its final form in your CMS.  This means that valid content can be fully automated from InDesign to the CMS.  Invalid documents can be automatically siphoned off for review and correction by production.  Users can then be retrained if necessary.

Beats checking every exported document ad nauseum, doesn't it?  Especially at 2am.