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

RSuite conference - business takeaway

Ed and I have both discussed different aspects of the RSuite User Conference, here and here.  Here now are some key business points that I saw demonstrated at the conference and that are particularly related to our current RSuite CMS 3.0 release:

RSuite is a very flexible tool.  Not only can it fit a large and diverse number of publishing needs, as demonstrated by our installed base, but it is very easy to adjust implementations after they have been rolled out.  Configuration is big, custom coding of general purpose functionality is not generally required. 

This means faster deployment of RSuite, which means shorter return on investment.  It also means low ongoing costs for making significant adjustments to the system as business needs change.

Existing and growing asset management features mean that businesses can consider the option of one RSuite implementation rather than a CMS and a separate DAMS.  And though I don't think it came out as clearly at the conference, RSuite's ability to act in several ways as a WebCMS also allow businesses to consider further options in reducing the number of systems they have to manage.  Finally, the new CS3 Connector will provide several additional possibilities as we grow the system. 

Basically, RSuite might be considered a new type of CMS that is really content centric rather than content *type* specific - perhaps it is better called a UCMS - or Unified Content Management System.  As we branch outward, this means that businesses may not need a separate system for every content type or distribution channel, meaning less overhead and maintenance overall.

RSuite was designed by (very) smart developers who care passionately about fast and easy implementations.  I can't overemphasize this.  Why is this good for businesses looking at RSuite?  All developers worth their salt, truly despise coding the same thing over and over again, a major hassle with older tools.  So it follows that many innovations in RSuite are about making easier implementations and allowing changes with configuration rather than coding.  Each release has come closer to that objective up to 3.0, which, I think, has achieved much of that goal.  Further refinements will just make things easier. 

At the conference, we had a couple of examples of 4 month implementations (including analysis).  This time taken should go lower with 3.0 - how far, we're not quite sure yet, but it should be significant.  And a more iterative approach should allow implementations to roll out even faster (but that's another post).

Finally, RSuite is a very developer friendly tool.  With RSuite, developers' time will be well spent concentrating on specific integrations and customizations to meet your specific business needs, rather than building and maintaining generic functionality or building general APIs.  They will also appreciate the elegant way that they can add functionality to the system - some real power will be in their hands to provide your organization with what it needs to succeed.

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?

Requirements, the publishing manager, and accountability

Senior publishing managers: do you have a clear idea of your role in publishing systems projects?  How about in requirements gathering for publishing systems projects?  (By senior publishing managers, I mean the publisher and direct reports or the equivalent - print or web).

BAs & PMs: How clear are the lines drawn between your business requirements, your functional requirements, and your system requirements?  Are you encouraging your senior publishing managers to take the appropriate project roles?

I'm thinking of two major projects I've come into contact with over the years where it was clear that the dividing lines drawn were wholly inappropriate to the intended constituencies, particularly for publishing managers.  I've also seen one major project where the requirements gathering was rigidly compartmentalized by the consulting company, probably as a means to ensure that each constituency was dealing with the appropriate subject matter. 

Some problem indicators:
1. Publishing managers reviewing quasi-technical diagrams in a functional requirements session (yes, we need to use XML; yes, we need a digital asset management system!).
2. Business/financial managers making top down decisions on specific systems. (Though there are cases where this could be appropriate)
3. Technical teams being left to determine how much time a task should take.  (What’s the matter? it only takes 10 minutes to process...)

Each to their own:
- Publishing managers should be concerned with functional requirements, which determine the effects of a system on staff work, including how work gets done by editors, etc.  They should also include setting standards for performance.
- Business/financial managers should be concerned with business requirements, or the overall financial effects of a system including related process changes.
- Technical teams should be concerned with systems requirements, systems, and architecture, to meet publishing manager needs (within financial constraints)

Publishing managers can have an important impact on a project.  My advice is not to get your hands dirty with specific technology.  Falling in love with a particular system or even a type of system, is a baaaad idea, trust me.  Falling in love with improvements in performance and ease of getting work done for your staff is a much healthier idea.

Senior publishing managers often consider the following:
    - We need to create this new online product
    - We approve doing this publishing technology project. 

They can more positively impact a project by making a few simple accountability statements and holding on to them like a pit bull.  They might sound something like this:
    - We need to create this new online product, and make content production for it take only this amount of staff time.
    - We approve doing this publishing technology project.  This project must reduce time spent on these non-editorial tasks, this amount, by this much, and decrease overall time in our production process, this amount, by this much.

This should set up a good interplay between subordinate publishing managers/staff and the technical team as they participate respectively in the creation of functional requirements and system requirements.

XMP Open day in NYC

Had a really fun day yesterday talking about XMP with about 40 other people in NYC. Reminded me of the early days of SGML and then XML - some confusion, lots of excitement. Much better software though. If you have any need to capture metadata for non-XML assets, check out XMP Open or my article from 11/05 as a starting point. XMP is a very smart technology (briefly: RDF/XML metadata embedded inside assets - particularly binary assets - so that you can capture it at any point in a workflow, not only when working in a DAMS or CMS), and is also a very practical technology.

The day:

Andrew Salop - the guy who "invented" XMP at Adobe - and Dianne Kennedy of IDEAlliance split the hosting activities of the day. Andrew has his own consultancy now (http://www.metaseed.net/) and continues to be an XMP evangelist.

John Dougherty of Hachette Filipacchi gave the keynote. He has a terrific vision of how XMP can transform workflows and facilitate looser coupling of systems. "Connectivity by confluence not by brute force."

Chris Griffin of  Pound Hill gave an XMP tutorial. Pound Hill has bet their business on XMP. Check out their site for interesting software.

Gunar Penikis of Adobe gave an overview of XMP in Adobe products. He also ended up in the hot seat throughout the day, with the audience pushing for a clearer statement of why Adobe doesn't want to cede control of the core XMP standard. Was a friendly discussion - everyone is grateful to Adobe for the effort and investment they've already made - but general consensus seems to be that the community would be better off with the spec in the hands of a standards group, provided that there was an appropriate balance between keeping things moving and being careful in the evolution of the core spec.

A group of XMP users (publishers) spoke about what they want to happen next. Focus was on better software tools. Was a savvy group, but when discussing a disruptive technology like XMP, even smart people find it difficult to articulate exactly what they need; it's not just new software that's needed, but new ideas about workflow.

Those of us on the last panel talked about the spec itself - how to proceed? The end result was that IDEAlliance enthusiastically signed on to continue the XMP Open work of refining and promoting XMP (with continued control of the core spec by Adobe). There's a lot of interesting work to be done in this area in 2006. Possibilities identified include: choosing a schema language for XMP metadata sets, a suite of conformance use cases and content, continued development of more metadata sets for particular domains (for example, the PRISM group has made PRISM metadata XMP compatible), promotion of XMP through discussion of how metadata capture should be supported through typical workflows, and some refinements to the spec itself. I'll post additional information as we move forward. If you're interested in participating, contact Dianne Kennedy at IDEAlliance.

And if you're a software engineer with some time on your hands, consider developing software to help people read/write (especially write) XMP metadata without needing to code in C++. There's a new version (4.0) of the Adobe SDK on its way that adds support for more file types, but it's still C++ only. There is at least one other implementation out there that writes (Image::Exiftool), but it's limited in the file types supported and in the namespaces you can use. (Bob DuCharme mentioned this to me; Bob, tell me if I misquoted you.) Additional open source tools would do more to promote adoption than anything XMP Open can do...

XMP notes from DAM summit

I attended the PRISM/DIM2 meeting and DAM Summit yesterday in New York City.  There was much good discussion between publishers and DAM vendors, and one of the more interesting topics was the growing use of XMP.

Bob Schaffel, Senior Product Manager for XMP at Adobe, offered two definitions.  The first is his technical description, “XMP is a labeling technology that allows you to embed data about a file, known as metadata, into the file itself. XML for metadata.”  The second is his human definition, borrowing from Marshall McLuhan, “The message is in the medium.”

One of the benefits of XMP is that the metadata is wrapped in the object itself.  Without it, if you transfer an object (say a jpg) from one system to another, you also need to determine a way to transfer metadata (implying this metadata also needs to be stored somewhere, such as a relational database or a separate XML file).  With XMP, the metadata is stored within the object itself and is transferred with the object from application to application (assuming the application supports XMP).  So if the systems that are transmitting the object can truly work with XMP, the metadata can travel with the object.  There is no need for additional querying for other data. 

For example, if you create an image in PhotoShop (including assigning some metadata), import it into InDesign and then create a PDF, the metadata travels with the image all the way through. Theoretically when you load the image into your DAM or other repository and then license it out, republish it, or deliver it somewhere, the XMP metadata can be delivered as well, as part of the object itself.

However, buyer beware!  Not all applications really work with XMP.  Some of the problems noted from the discussion at the meeting included:

• Some applications will export the image but ditch the metadata.  For example, you edit your image in an application that can’t read or write XMP.  Some of these applications will output the image by recreating it, leaving out the XMP metadata.   So your output file “looks” the same (with the edits) but the metadata is lost. This reminds me of opening HTML files in Microsoft Word or FrontPage, which inserts additional tags into the file.  It's transparent when looking at the output, but underneath the covers, things are bad.
  
  
  
• The file formats for images (and other objects) have a certain area for the binary data to create the image and then some other space for the XMP.  Some applications can read and write to the XMP but don’t understand the native file format enough to accommodate a growth in the area reserved for XMP.  That is, you could add so much additional metadata to the XMP area that it outgrows the space originally assigned to it.  The application needs to understand the file format enough to stretch the file to accommodate this.  There was some debate on how real this issue is (chances of adding so much that the area needs to be expanded) but it is a limitation to be aware of when evaluating applications that claim they handle XMP. 
  
  
• Even if a current version of software supports XMP fully, older versions may not.  So if files are transmitted back and forth, say between staff editors and freelancers, be careful that someone in that loop doesn’t use an older version, which will most likely not return the XMP metadata to the file.

XMP has been around for a few years, but it is gaining more traction within the publishing community and vendors are moving to offer better support.  At least smart ones are.