Today's theme (if you wish) is focus on the evolution of content creation best practices ... To be more explicit, I'll use a comparison with the world of software development (yes ... I will talk about code! ^^)
So if I had to ask a question:
to draw one's inspiration from.
Does content production should take the same path and adopt the same principles?
First, an observation
In non-structured information world (ie in the functionnal world generally...)
- Users enjoy the use of desktop tools (MS Office, Open Office ...) to create the vast majority of content (Report, documentation, manual, form ...) inside the company.
- They store information locally on their computer (hard drive).
- They share content via network shares (shared hard drives in a network) or via an e-mail attachment.
- Sometimes content will be grouped, merged with other content to form for example a multilingual advertising campaign, a response to prospect, a manual for mounting a furniture, a booklet, a catalog ...
- One of the best practices in content creation is to create a template to re-use it. In general we want to re-use the style of the document (PowerPoint template), or content (word document template ...)
- To share these models, we publish the file in a shared directory or website
In technical information world (eg software development)
- Developers enjoy the use of development tools (Eclipse, Visual Studio ...) to create the vast majority of code file (.java, .c, .html ....).
- They store files locally on their computer (hard drive)
- They share code via a management system version (SVN, Hg, CVS ...).
- With all code, developers create a project which will be compiled using automated environments (Maven, Continuous Integration...) to produce a program (software solution)
- When code can be reused, developers include this code in a library(.NET, Java, Spring ...) This library can then be used in new code.
- To share libraries, they publish it in a system directory or a website.
Now it's game time ! Let's spot the difference ! ... ie try to find the differences between the two worlds. You have 5 minutes!
Ok... let's forge ahead ...
My vision
I think best practices and principles acquired through development (or other) will be increasingly used in content creation.
It's time to explain ...
As you can see, there are differences in how to create / share / edit content between functional and technical domain.
In software development world, we assist in last few decades :
- Local code
- Shared code
- Shared code in a version management system
- Shared code in a standardized code management system
In content creation world, we assist :
- Local file
- Shared file
- File in a content management system
- File in a component management system
In other words, content management will know (and already knows... I have to be precise ! ) the same changes than development with programming had with object-oriented approach and continuous integration !
We try to apply to content the well-known principles :
- Write Once, Deploy Everywhere
- Stop Reinventing the Wheel
This new idea tries to create and use tools like :
- A management tool for configuring multi-dimensional content (how to manage versioned content composed by other versioned content which are composed by other versioned content)
- A generation platform
- An editor (integrated in office tools or not)
- A coherent system to rule them all !
What are benefits of this approach?
Take the example of "response to a call for tender" (Sorry if it's the wrong term...)
For those who are not familiar here is the principle.
A call for tender is a procedure by which a potential buyer requests different suppliers to make a commercial proposition to the detailed formulation (specification) of buyer's need (product or service). Of course all communication between the parties is usually done with documents in office format (printed or not). Response to a call for tenders is the technical proposal and commercial office format.
Let's explore the difference between a company called A which owns a component management tool and a company called B which have no tool.
Company A has made an habit of creating components. That's why it has a catalog of
- Client references
- Architecture and methodology
- Proposals
- Resources
- Stylesheets
User, who are reponsible for the response, will simply assemble major components (up to 80% of the document) in a few clicks and work on the last 20% (the heart of the response...)
Company B does not have such a system. User must seek in his old one example the one that will serve as start model. It should then do a lot of copying and pasting, checking the different information, may update or ask to update ...
And usually, this person finds few hours before the deadline he had forgotten to take the right stylesheet or the last reference ...
To conclude, according to this quick example, the gains are many:
- Gain of time
- Gain of money (because time is money!)
- Gain of modularity
- Gain of efficiency ...
What's this system?
I do not know if there is still a true acronym, but the term CCMS for Component Content Management System (CCMS) is the one who is closest!
So don't hesitate to inquire about it! (And me too at the same time ....)
And future term may be ECCMS (Enterprise Component Content Management System) ...
Special Thanks to Componize.com (and staff cf. [FR] Interview of Herve Quiroz ) which help me to understand Component Content Management and don't hesitate to try their CCM solution !
Note
The only problem I find with CCM adoption would still the graphical interfaces and user experience. The man (and woman) still remain the key and most important variable...
Thanks to everyone and don't hesitate to post a comment !






