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.

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.

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!

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

One of the best search experiences

If you have anything to do with presenting a search product to your customers, check out www.kayak.com.  The site aggregates travel data from other online products (including other aggregators like Expedia, but also direct from airline, hotel, and car rental sites) but check it out regardless of whether you travel.

Why?  I would say this site has created one of the best search experiences I have ever seen.  Now it may be that it is such an upgrade over other travel sites that it just blows the competition away, but I think it is more than that.

There are little things, like auto-populating the input box with airport codes (instead of a separate little link to "look up" the code), and really big things, like the ability to filter results.  In many oth er online travel products, if you want to change dates or other criteria you need to go back to the main search.  Or some will include the search form on the results page.  But on kayak.com, you are offered a set of dials and levers for adjusting the query, such as eliminating airlines, changing departure time frames, or looking for the shortest trip.  You want to leave between 10 and 12, just move the dial and the page is updated with results that match.  You want to find the shortest trip.  Move the lever.

Does your content, or its metadata, lend itself to this type of search?  Is there a way to present options for your customers to refine search results in a more appealing way?   And before you answer "no" think of how Expedia or airlines have offered search for years and then look at how kayak.com does it.   There is probably always a new and better way.

One last note.  I heard a podcast from Jon Udell a few months ago about how the CEO of kayak.com has his developers answer customer service inquiries.  The people building the software interact with the people using it.

Kayak.com’s customer service was inspired by craigslist. Paul English says that making his engineers directly responsible for customer service has done wonders for the software development process. Because they’re on the front lines dealing with the fallout from poor usability, they’re highly motivated to improve it.

Here is another (written) interview.

Going online first

We've started to chronicle moves to abandon print editions in favor of sole digital delivery in our new Demise of Print blog.  On the other side of that coin are publishers who skip the print version of a new publication entirely. There certainly are publishers who have opted to create a new product, which 5 or 10 years ago would have been a print product, in an online only format.

CQ Press, a DC-based publisher who has dealt with some of these print vs. online challenges (a few years ago they stopped the print edition of the Supreme Court Yearbook but still produce the content, which feeds several online products), recently launched a new newsletter product. In doing so, they made a decision to launch it online with no print counterpart. However, and at first I found this somewhat ironic, the product offers a PDF version of the content that mimics a printed form.

I found this interesting. Even when we can free ourselves from "the tyranny of print" we sometimes still find that we need to offer a print-like PDF version of the content. Why? I decided to ask Mary Grace Palumbo of the CQ Press product development team (thanks to her for sharing the insight) about first, the decision to go online without a print counterpart and second, why offer a print-like PDF.

Ed: First off, can you give me some background on the new product?

Mary Grace: It is the Global Researcher, which is based on our venerable CQ Researcher weekly report, which is published in print and online.  The CQ Researcher covers timely issues and topics, such as energy regulation or immigration reform.  The Global Researcher is modeled off of that and covers global issues from an international perspective.

Ed: So, why did you decide not to offer this new product in print?

Mary Grace: We actually didn't make that decision.  What we decided to do was to first offer it online.  If it is successful, which it looks to be, we may also offer a print companion.  So it is not that we are not going to do print.  Rather we want to be practical in how we launch new products. This product covers a new area for us so we want to test the waters online first.

Ed: So, and this may be obvious, the barrier to entry was lower for an online product.

Mary Grace: Certainly.  There are no print production costs and we already have the online infrastructure set up.  Sure there are costs with that as well, but we also feel our audience would expect an online version.  We knew we would have to have an online version—there is no question about that—so we started there.

Ed: Ok, but being an online only product, at least for now, why did you still feel the need to offer a print-like version through a PDF?

Mary Grace: The entire production process is based on the CQ Researcher production process, which is set up to support both print and web. It’s a traditional print production process with a conversion to XML at the end.   We are using the same model to produce the Global product because, (a) it was already there, (b) the editorial staff is already used to it, (c) when a decision to create a print product is reached, it can quickly be done as opposed to creating a new process, and (d) to answer your last question, it is already set up to quickly create a PDF.

Ed: So it’s easy to do, a byproduct of the process.  But was the market need discussed?  Is your audience asking for the PDF?

Mary Grace: It really was just assumed in the beginning.  The editorial group came in assuming a PDF output would exist. And yes, since the reports are over 20 pages long, people find that PDFs are useful as “take-aways” from the website – they just look nicer than printing out the HTML pages.  Since we based the workflow on the existing print CQ Researcher model, it was very easy to do.

So to recap, CQ Press used an online version of the product before print to confirm success before investing in print and offered a PDF because, well, it was easy to do and the editors expected it.  I am going to try to find some other stories of publishers who either do online before print or online only for new products, and if they offer a print-like PDF, I'll ask why.  Stay tuned.  If you fit this criteria and would be willing to share, please let me know.

The Demise of Print blog

Back in April, I wrote a post called print death watch that grouped a few announcements of the transition of a handful of print publications to sole online format.  For them, the printed form of the product is dead.  The announcements had been covered elsewhere but I didn't see anyone group them together in one list.  I also started to track these events on my own in my del.icio.us account.

This is a question many publishers are facing.  We see this happening and although personally I don't really believe print as a whole is really dead or will die soon, there are certainly examples of it happening now.  Some content products have made this transition and I expect we will see more do the same.

We at Really Strategies are launching a new blog to chronicle these transitions.  The blog is simple really, just a list of content products that were once found in print but have moved solely to online delivery.  It won't be a typical blog.  We will only post announcements as they happen.  We have no problem "back-dating" a post for an event that happened in the past.  The point is to collect, in one place, a list of publications that have made this transition.  We started the list.  We probably missed some, so your help is appreciated.

Check it out—Demise of Print —and let us know what you think.

Educational publishing - a parent's lament

So my kids are getting older - and starting to move through school.  I haven't seen a textbook come home with them yet, but those massive, weighty, colorful, and engaging things are going to come soon, no doubt.  Aside from needing small forklifts to move their books around, what's the problem?  And there are nice PDF facsimiles of the printed pages online if you want to print them out - or just read online.  There are also fun supplemental educational games and some online multimedia to look at.

Well, as I sit at my laptop writing this, I'm occasionally alt tabbing between a few online newspapers The New York Times, The Wall Street Journal, etc., and this blog (not to mention the new 'Demise of Print' blog).  And I think to myself, if I use online publications as a primary source of content, why don't kids use online publications as a primary source of content?  The New York Times and The Wall Street Journal don't put up facsimiles of their printed edition (that would be a laugh).  Why should I settle for that for my children?

When we also look at what is happening in publishing elsewhere, with magazines and newspapers ratcheting up their capabilities to publish simultaneously or web first, with layouts that are ready for  web first consumption, I have to wonder how long educational publishers can hold out.  They are certainly not in the forefront - and they need to be.

The question may hinge to some extent on how kids will consume content and learn online - what is an appropriate web format for say a social studies book?  It will be very different from a newspaper layout, certainly,  but It is probably not something that *is* a print textbook page.  So this is hard, particularly for established editorial staffs that have been producing books all their lives.  It's new territory.  But newspapers and magazines have successfully moved forward and developed compelling web layouts for their content.  It's time for textbooks to do the same.

Some are concerned about equal access for kids to computers.  Poorer kids might still not have computers.  This is an important issue certainly, but this has been an excuse for 10+ years - I'm sorry, but what level of access is required?  Certainly the print editions won't go away for a while, but don't make the entire country stay with print while the last 10% or less of the population gets online.  It is well past time to take the plunge - and it would be nice to have it happen before my kids graduate, thank you.

Everyone knows that today's kids - and now young teachers - are more than ready for the online world.  If we are teaching our children to learn to manage information as they would in the workplace and real life, then don't give them an 800 page hardcover book for each subject - let them log-on instead.  By chance I recently shared a plane ride between a teacher from Iowa and an education consultant.  We talked shop and found ourselves discussing this very idea.  The consultant was not convinced.  But then I asked how she got her news and it dawned - she had been reading newspapers online for some time.  And that was food for thought.

The “content” in web content management systems

My colleagues have posted some interesting thoughts on content management and bridging web and print worlds, especially Lisa's post on CMS vs Web CMS vs Print CMS.

I believe the term "content" in "web content management systems" will eventually become a misnomer, if it is not already. Sort of like how I still "dial" a telephone or "roll" down my car windows.

Eventually web content management systems won't be about the content, at least not for publishers or companies with large amounts of content. As publishers move towards the big content integration, tools will streamline to manage content separate from the web delivery. Some content will go online and some content will go to print and some will go to both. But the workflows and tools will be synched.

So where does that leave web content management systems ? There will probably be two directions (and again this is from the traditional print publishing point of view; there are good business cases outside this model that I am not speaking to).

1. Some will be strong in managing content and will need to separate their content creation aspects from their delivery pieces, and/or integrate that content creation with other output channels besides the web. In effect they will become authoring environments.  The first steps in this will be partnerships and integrations between web CMS and print CMS products but eventually we'll ask the question of why do we need both.
   
2. Some will be strong in managing web sites and related functionality. So, forget about the content creation but fill the need for managing the web site itself: page creation, templates, interactive user functionality, and so forth.  In this case, think about web content management as an online Adobe InDesign or Quark Express, but with the complexities of the full online world. Content will be fed from some other system, and the user will manage the web site, not so much the content.

It is in that regard (the second point above), I think the term "content" in web content management system will eventually be misleading. Just remove it.  It will be a "web management system" or a "content management system" but not both.   Well, unless the content you have is only for the web...

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?