Content management systems can be a great asset to your organization in managing the plethora of content that passes through your business before landing in the hands of your customers, no matter the channel they use. But like anything valuable, these systems require care and attention. They require someone to take ownership and responsibility and they need everyone to play by the rules to keep order. In this blog we’ll discuss some rules to consider by way of a governance model.
Follow these basic content management principles.
Use the functionalities of the CMS to separate content from design, reuse content where appropriate, put content in defined content schemas, use component templates to render the output using defined business rules, build templates that can use inline editing where available, and encourage reuse and localization rather than redevelopment.
Design for operational efficiency.
Web content is created to be reused and changed. Content must be built to evolve. CMS users are mostly non-technical, so build for a non-technical user. Ask yourself – can I make one change that is propagated everywhere this content is used? If the answer is yes, you’re using the power of the CMS.
Collaborate with your CMS product team for new development.
New components, templates, and schemas must be reviewed and approved by a governance team. The need for collaboration includes additions or changes to the content data model, security model, and the blueprint.
Important questions to ask
Is this similar to anything we already have or anyone else intends to build?
As an example – if a development requires an XML page, can we reuse an existing page template rather than create a (named) specific instance where the functionality is likely to be the same? (i.e., write out a file with an extension of XML, with an initial XML definition tag and then just write out the component presentations)
What (re)development will this proposed solution require for an upgrade to the next CMS version?
There’s every chance that the GUI will have, at least some, elements rewritten. This creates the risk that development on custom GUI extensions cannot be reused directly. Consider this the cost to compare and contrast with the benefit of such extensions.
What’s the impact of using this functionality within an inline editing context?
Not all content editing is best suited for inline editing, but we should understand the implications or at least ensure it doesn’t break any functionality that we may have at that point in time.
For inline editing, it’s fair to anticipate that we may need to rewrite anything we do in the current version, as CMS upgrades often introduce new frameworks (allowing for shifts in technology/security and UX improvements, etc.) and will likely need to be treated as small projects in their own right.
What’s the impact for the editor?
Does this break standard/existing editing methods/patterns? And, contrarily, does it work towards improving any identified weaknesses or annoyances for the editors?
Will all editors be affected or just editors of a specific group/area?
Will editors require specific training or will the supplied documentation and notes be sufficient?
How does this functionality affect other CMS Tools?
Often times the CMS comes with additional tools to assist other processes, such as Content Porter for Tridion Sites to facilitate the DTAP process.
An example of this is when there is a solution in a rich text field that uses a tag instead of a link to refer to components. Although custom rich text field rendering will usually utilize the link when publishing a page, the specific tool (in this case, Content Porter) will not acknowledge this as a component link. Therefore, it will not map the ID in the source environment to an ID (or WebDAV URL) in the target environment, nor will these specific dependencies be taken into account. So, a neat solution of using editor-friendly tags to associate content visually can result in breaking the standard process of moving that content (and its dependencies) between environments!
When does this kick-in?
When there’s an idea …
There are lots of ideas floating about. Or at least we would hope there are. As users – both business representatives and vendors alike – present their ideas, we need to try and keep abreast of the many ideas out there. We need to identify themes and opportunities for shared development and reuse.
When there’s a design …
In between the idea, requirement agreement, and design, there will be other parties that have introduced other ideas, requirements, and designs. This is the last chance to ensure the design fits in with our general principles and offers an opportunity to bring this design to view of other parties that may benefit from it.
When development commences …
When the development begins, we may be working with the same templates or related code (schema or elements of the BluePrint). We need to coordinate development within the WCMS environment to avoid conflict and plan to take advantage of any opportunities for shared roll-outs/testing.
When development is complete …
Confirmation of completion allows us to assist in the continued coordination of all aspects discussed here with other parties. This confirmation is also our last chance to assess if we can take advantage of any opportunities for shared roll-outs/testing.
When rolled out …
After the exercise is complete, it allows us to see the final step of the efforts.
Our aim is the same as the aim of the businesses, in that we want to see practical solutions out there in the hands of our customers.
Our aim is the same as vendor developers, in that we want these solutions to be presented internally as cost-effective, reusable solutions.
In conclusion
When introducing a governance model, we’re often met with comments that “it’s overkill” or “it’s designed just fine”. The truth is things change, your organization should be changing, and you can bet the sourcing, utilization, and delivery of content has changed too.
It’s likely that you went through a thorough implementation phase to get your CMS in place. Before that, it’s likely there was a lot of design, a lot of discussions with relevant stakeholders, and a lot of agreements.
A governance model will ensure all that hard work and good practice continues to serve you well and that the decisions that still hold are recognized, while choices that would be different now can be reviewed with the benefit of reflection.
If you’re having problems with your CMS or the content models you use, come and talk to us – it’s never too late.
