On Metadata and Help Content
At the recent Drupalcon conference, Karen McGrane gave an awesome keynote titled Thriving in a World of Change: Future-friendly content with Drupal. (Although I didn't attend the conference, the talk and her slides are online.)
In her presentation, Karen emphasized the 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.
Karen said that 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 writes:
Because future-friendly content requires true separation of content from presentation. We have to support too many different outputs for content to assume that we can couple content with presentation. Do you have any idea what a huge shift this is in the way we think about content? For most of human history, it was impossible to produce a document without considering meaning and appearance together. All of our semantic cues as to priority, weight, relationships in content come through visual styling. But now we need new tools, new processes to achieve that.
Personally, I talk all the time about the limitations of what I call blobs, of giving content creators a big bucket into which they can dump whatever they want, style their content with tools that work “just like Microsoft Word,” add tables and custom bullets and make the text purple Comic Sans and float it to the right. Blobs are limiting, because all of this formatting, all of this meaning doesn't translate when you try to take it to another platform.
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.
The web liberates us from the constraints of the physical world. Content doesn't have to be in one place at one time. The chair or bed you're probably sitting on can only exist in one place at one time, but your web content can exist in multiple places simultaneously.
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.
In my opinion, liberating content from a static, single position in a table of contents is probably the most relevant, immediate benefit of moving content to the web. But until we start enriching our content with metadata and semantic cues, we can't push or pull it in interesting ways.
That's why I'm so floored about Drupal lately. I've never had a tool at my disposal that allows me to do all of this.
I also think the clean, structured content model that Karen describes is essential for building a sane authoring to publishing process. 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.
Instead, 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.
About Tom Johnson
I'm a technical writer / API doc specialist based in the Seattle area. In this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, visual communication, information architecture, writing techniques, plain language, tech comm careers, and more. Check out my API documentation if you're looking for more info about that. If you're a technical writer and want to keep on top of the latest trends in the field, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.