On Metadata and Help Content
Tom Johnson
May 27, 2013
idratherbewriting.com/2013/05/27/on-metadata-and-help-content/
We need to transform content management systems away from the “content goes here” type of blob to a CMS that separates content from format, one that allows users to embed metadata into their content and maintain the content in a clean, structured way so that it can be ported to another platform and re-used elsewhere. Structured content helps future proof the content, so that when you need to get your content into audio interfaces, digital signs, billboards, internet refrigerators, touch screens, watches, Google Glass, smart TVs, or some other platform, you can get your content out.
She calls for “new tools, new processes” to embed “semantic cues” into CMS content. Although the reuse examples mostly point to getting the content onto different platforms, I think there’s also a strong case for dynamic repurposing on the same web platform.
Many times we build a table of contents for our content, following the same methodology as a printed book, and leave it at that, forcing every reader, for nearly every situation, to follow the same rigid organization through the content.
Through metadata, you tag your content with terms from your taxonomy that describe the content’s purpose. You might have half a dozen vocabularies, some describing the content by its subject, others by function/task, others by audience, by subject, by format, by framework, by API platform, by component, and so on. You can then manipulate the metadata into myriad organizations to suit different purposes. The rules of your CMS govern where the content appears. The metadata can be exposed as facets in search results to determine how results get progressively narrowed.
Further, you can build sophisticated filters that combine the metadata in various ways. Say you want to find all content that fits the ACME API (a tool) and is used for configuring widgets (a function) and which suits a developer audience (a persona). Voila, either through a selection of faceted filters or pre-built queries, you can return this information to the audience immediately and dynamically.
When you’re developing content, you’re often working collaboratively with other authors. You also have subject matter experts (SMEs) review and add/edit content as well. You may go through countless revisions, edits, and other updates to your content before it’s ready to publish to the user. Trying to do all of that content development in a simple wysiwyg box in a web CMS is a recipe for frustration.
I think it’s more practical to develop content in a wiki-like environment, and then port that content into a web CMS when ready. How do you connect content from one system to another in a seamless way? If all you have are content blobs, which get hopelessly polluted by rich text editors that insert their own inline formatting code, or which trap their content into a non-portable format, you end up with a huge headache. For example, ever try converting a Google doc to HTML and then put it into Drupal? It sucks. Or try taking content out of Confluence and putting it into Drupal? Also not ideal.
The CMS should store content in a clean format that doesn’t infuse formatting elements with the content. When you’re ready to move it to another system, the structure should be processable by the other system in a seamless way. Export from one system, import into another, and so on. You can’t do that without a common structure to your content, or without tools to connect one system to another.
On Metadata and Help Content Tom Johnson May 27, 2013 idratherbewriting.com/2013/05/27/on-metadata-and-help-content/
We need to transform content management systems away from the “content goes here” type of blob to a CMS that separates content from format, one that allows users to embed metadata into their content and maintain the content in a clean, structured way so that it can be ported to another platform and re-used elsewhere. Structured content helps future proof the content, so that when you need to get your content into audio interfaces, digital signs, billboards, internet refrigerators, touch screens, watches, Google Glass, smart TVs, or some other platform, you can get your content out.
She calls for “new tools, new processes” to embed “semantic cues” into CMS content. Although the reuse examples mostly point to getting the content onto different platforms, I think there’s also a strong case for dynamic repurposing on the same web platform.
Many times we build a table of contents for our content, following the same methodology as a printed book, and leave it at that, forcing every reader, for nearly every situation, to follow the same rigid organization through the content.
Through metadata, you tag your content with terms from your taxonomy that describe the content’s purpose. You might have half a dozen vocabularies, some describing the content by its subject, others by function/task, others by audience, by subject, by format, by framework, by API platform, by component, and so on. You can then manipulate the metadata into myriad organizations to suit different purposes. The rules of your CMS govern where the content appears. The metadata can be exposed as facets in search results to determine how results get progressively narrowed.
Further, you can build sophisticated filters that combine the metadata in various ways. Say you want to find all content that fits the ACME API (a tool) and is used for configuring widgets (a function) and which suits a developer audience (a persona). Voila, either through a selection of faceted filters or pre-built queries, you can return this information to the audience immediately and dynamically.
When you’re developing content, you’re often working collaboratively with other authors. You also have subject matter experts (SMEs) review and add/edit content as well. You may go through countless revisions, edits, and other updates to your content before it’s ready to publish to the user. Trying to do all of that content development in a simple wysiwyg box in a web CMS is a recipe for frustration.
I think it’s more practical to develop content in a wiki-like environment, and then port that content into a web CMS when ready. How do you connect content from one system to another in a seamless way? If all you have are content blobs, which get hopelessly polluted by rich text editors that insert their own inline formatting code, or which trap their content into a non-portable format, you end up with a huge headache. For example, ever try converting a Google doc to HTML and then put it into Drupal? It sucks. Or try taking content out of Confluence and putting it into Drupal? Also not ideal.
The CMS should store content in a clean format that doesn’t infuse formatting elements with the content. When you’re ready to move it to another system, the structure should be processable by the other system in a seamless way. Export from one system, import into another, and so on. You can’t do that without a common structure to your content, or without tools to connect one system to another.