The ubiquitous nature of the web and its foray into the world of mobile means that modern content management must advance beyond traditional web publishing.
During our Innovation session at this year's Let's Do Digital we explored the state of syndication across the web; publishing platform-neutral content to websites, mobile apps and social channels through one centralised workflow.
Context
When it comes to content we have to ask ourselves "are we thinking about it the right way"?
With the increasing number connections linking the increasing number of devices in our pockets (and now, on our wrists) are we managing content in a way which allows us to match the pace and leverage the opportunities?
As an example, when I add content to a website such as a blog (this article, let's say) am I really considering the device that it might be read on? Responsive design certainly helps us with regards to mobile phones, tablets or any other typical HTML-rendering device but what about the information contained within the page? Does it have value on other platforms or in other contexts, and how would it be presented?
If I was to publish a schedule of events (for Let's Do Digital, let's say) rather than writing the running order as text in the page, does that content have meaning and value in another context or on another platform? Is there more we could do with this information to enhance an experience?
When we think about it, each item in that list has a time associated with it. It's more than just words in a page. On what other platforms is time a big player? (hint, hint).
So we have to ask ourselves, if we could publish content in every way except as a web page, how would we do it? Is your CMS genuinely a content management system, or it is really just a web publishing tool?
This introduces us to the concept of C.O.P.E... Create Once Publish Everywhere.
Multi-channel publishing
In the first instance this is a discussion about publishing content to multiple channels. Even if you have the world's simplest website you have at least one channel. That channel is your website, which serves content stored in your content management system.
But we're talking about serving content to multiple channels. So in addition to a website's frontend we've potentially got content for other channels; Twitter, Facebook, or maybe an App. As you can imagine with the increasing number of connections available to us we have the opportunity to serve content across a number of new channels, and those channels may present further opportunities.
The arrows here represent the flow of content, and we should recognise as a results that web pages are not content. Pages are where content lives. The information we have must transcend these channels, and while we're still thinking about content as web pages and HTML we're potentially closing the doors to other opportunities.
In order to keep up with this inevitable scaling we have to separate content from presentation, because content that is bound to its context (in this case a web page) is locked in.
Channel imposter
There have been a couple of amusing examples in the past of context-specific content or terminology creeping into channels where they shouldn't be.
Take these two newspaper clippings for example, where the term "Click Here" (a web-specific instruction in this case) turned up in a couple of print advertisements.
These are good examples of where content writers only ever expected their content to appear on a device where you could click.
I take particular issue with the second example, where the editor wrote the term into the actual paragraph. Any UX designer will tell you that an action should never have to be explained. It should be explicitly obvious that an element is clickable. Had the editor made the word "compare" clickable (rather than explaining to the user that they need to click) then this particular example would have been avoided all together.
In this case the editor should have decoupled themselves from the channel and allowed the platform to describe how to interact, rather than the prose.
This begs two questions...
- Can content writers abstract themselves away from the presentation specifics of a channel?
- Is it realistically possible to product content without thinking about where it will be presented?
Mark Boulton commented on this issue particularly well:
“The question content people ask when finishing adding content to a CMS is ‘how does this look?’ and this is not a question a CMS can answer any more – even with a preview. How we use the web today has meant that the answer to that questions is, ‘in what?’"
Seperating content from presentation
So in practical terms what do I mean by separating content from presentation, and how do we ensure every channel understands the message?
Firstly, we need to think about how we currently create content with a CMS. In the case of many CMS's (but not all) you may be familar with the common WYSIWYG editor. By using this tool the content is saved as a mix of HTML (the building blocks of a web page which describe how it looks) and words (the content).
This means that historically we haven't been creating messages, we've been creating web pages. As we've learnt, in order to facilitate multi-channel publishing we can't tie ourselves into one channel and allow the message itself to be intrinsically HTML.
Content is made from chunks of information, and these chunks transcend presentation. They are properties of the content that have nothing to do with how the content should appear in any particular channel.
Therefore when writers are asked to enter content into a CMS it should be provided at the message-level rather than the presentation-level. This is of course a failing of the tool itself rather the writer.
It's essential for tools to offer this because what we used to call "the page" has now become a unit of business intent, and there is more value to be had of this unit than just the copy.
Instead we should be offering writers the opportunity to enter those properties without concern or control over how it might look. Options like 'styles' and 'alignment' should be taken care of by the channel. This is of course particularly important for brand guidelines or quality control.
Our particular CMS of choice, MODX, allows us to do this with a feature called 'Content Blocks'
Using this tool instead writers can add content to the CMS without storing it as HTML. The headline above is stored as text, and we know that it is a headline. Should this chunk of content require syndication across the web we're now free to do so knowing the context of the property and that it's not intertwined with (potentially) incompatible HTML. There is a styling option here but it is not bound to the copy.
This is more than just preventing writers from negatively affecting the layout or design of a web page, it's about allowing ourselves to safely publish content across the web free from HTML, either today or in the future.
Content has meaning
Describing the context of our content's properties will eventually become business critical in every instance, if it isn't already.
So, if you can, plan the pieces before the pages, because your content is more than just words on a page.
