Some notes on the need for a CMS
Our organization is currently firming up the intranet for division and branch web sites. We recently conducted a workshop to present the current status of individual web projects, as well as other online services such as knowledge management systems and several diagnostic tools.
To synthesize the various projects and come up with a homogenous structure for the intranet, I gave a presentation on the need for a better content management system (CMS).
We do have a CMS solution, albeit a rudimentary one, based on PHP and MySQL. In my opinion, it fell short of the growing needs of the organization, hence the need for a better CMS solution.
I started off by presenting the current workflow of one of our major web projects: the online publication. Our major goal with this is single-source publishing, that is, documents emanate from a single source into various formats like web pages, newsletters, technical bulletins, among others.
The current setup calls for an editorial team who will create and deliver content, mainly for the web first, then later on culling stories for the newsletter and special editions. The concept is good, but the implementation leaves much to be desired. For example, the current workflow model calls for a writer and editor to exchange notes on documents several times before articles can be published. This is well and good for a print setup, but for the web, the workflow should be more streamlined.
There is also the issue of tools being used for the work process. The team currently uses basic word processing tools for the articles, on which markup is later added for presentation on the web. This is crude, because editors end up spending more time doing markup, when they should be focused on the content. The current CMS does not have a WYSIWYG interface.
I then focused on the content requirements for the intranet, enumerating specifications for content creation, management and delivery. The CMS solution must fulfill the following requirements:
That's a pretty tall order for a CMS, but given our requirements, and the projected escalation of content that our organization generates, I think these pretty well cover our ground for the immediate future.
To synthesize the various projects and come up with a homogenous structure for the intranet, I gave a presentation on the need for a better content management system (CMS).
We do have a CMS solution, albeit a rudimentary one, based on PHP and MySQL. In my opinion, it fell short of the growing needs of the organization, hence the need for a better CMS solution.
I started off by presenting the current workflow of one of our major web projects: the online publication. Our major goal with this is single-source publishing, that is, documents emanate from a single source into various formats like web pages, newsletters, technical bulletins, among others.
The current setup calls for an editorial team who will create and deliver content, mainly for the web first, then later on culling stories for the newsletter and special editions. The concept is good, but the implementation leaves much to be desired. For example, the current workflow model calls for a writer and editor to exchange notes on documents several times before articles can be published. This is well and good for a print setup, but for the web, the workflow should be more streamlined.
There is also the issue of tools being used for the work process. The team currently uses basic word processing tools for the articles, on which markup is later added for presentation on the web. This is crude, because editors end up spending more time doing markup, when they should be focused on the content. The current CMS does not have a WYSIWYG interface.
I then focused on the content requirements for the intranet, enumerating specifications for content creation, management and delivery. The CMS solution must fulfill the following requirements:
- An integrated multi-user and non-technical authoring environment. Authors must focus on content, nothing else. They should not be made to learn markup, although it does leverage their skills, but way too much time and productivity are lost on the shifting of focus.
- Separation of content and presentation. This ensures that content can be formatted in different ways through the use of style sheets. By strictly separating presentation from content, rendering can be based on context and the medium.
- Single-source publishing. Content will often be used for different contexts, audiences and media. With single-source publishing, content can be reused, without the need for replicating it for different outputs.
- Metadata creation and powerful linking. On its own, content is okay, but combined with other content and sprinkled with properly formed metadata, content increases its value.
- Version control is necessary for accountability and archiving. Given the workflow, with multiple creators on multiple documents, it is easy to get lost.
- An efficient workflow, specially one that is resilient to organizational changes is the core to a well-oiled CMS.
- Finely grained access levels and audit trails help protect the integrity of the content.
- Usability and accessibility issues must also be taken into account in the content delivery phase. If the content is to reach a wider set of audience, it must rely on well-defined and established standards.
That's a pretty tall order for a CMS, but given our requirements, and the projected escalation of content that our organization generates, I think these pretty well cover our ground for the immediate future.
Comments
Post a Comment