Raquel Rodriguez is Neoteric Design’s summer 2015 apprentice, working on product development, design, and front- and back-end development.
“Future-ready” entails a framework for thinking about, creating, storing, and distributing content.
Modular content: layout flexibility
Recently, in preparing for a review and presentation of a few drag and drop CMSes, I did a bit of reading around the concepts of modular content and future-ready content. As explained in Christopher Butler’s The Way You Design Web Content Is About To Change, modular content is a way of creating content that allows for greater flexibility than what is usually supported by CMSes that pre-determine what goes where. Instead of a content template where content is plugged into its assigned box, the modular method supports a greater variety of combinations of content.
Future-ready content: device flexibility
Related to modular content, the idea behind future-ready content is that content should be prepared in such a way that it maintains meaning and purpose regardless of how it is accessed. Devices for displaying content will continue to change in the future. As described by Sara Wachter-Boettcher, getting content ready for the future means that we consider the framework by which we make decisions about content. She proposes a framework where understanding the purpose, core elements, and meaning of your content is paramount to future-readiness.
Using the example of a recipe, a content creator would first want to be clear about why a user would want a recipe, or how a recipe supports the site goals. Deciding on the content type is not an accident, but informed by the goals of the site. Furthermore, the content creator should identify the core elements of the content type and understand how those elements relate to each other and the content type as a whole.
Wachter-Boettcher’s framework also includes working with the people who create CMSes to help them understand how the goal of having future-ready content is impacted by the tools they create. Providing specific direction as to what type of content and core elements are needed, for example, can help outline tool requirements.
Finally, Wachter-Boettcher’s framework includes the need to structure the content elements. She offers a variety of possible structures (XML, Schema), but does not suggest that one is superior to the other. Instead, the decision of what structure to use should depend on the needs of the project.
Content APIs: publishing flexibility
While the last two pieces of the future-ready framework themselves depend on tech tools (working with CMS developers) and data structures (deciding what structure to use), it seems the core of the framework is its focus on content purpose and meaning. Just as the goal of future-ready content is to have content that is device-agnostic, the fundamental process of creating future-ready content is itself not reliant on a particular device or technology. Understanding the purpose, meaning and relationships of the content is what makes the meaningful distribution of it across different technologies possible.
A content API that can store and distribute all the necessary content elements is, perhaps, the primary method to consider in the context of creating and distributing future-ready content.
Future-ready content, then, entails a framework for thinking about content, creating, storing and, finally, distributing content. There is a great example of the latter stages of the framework when Wachter-Boettcher describes how National Public Radio developed a methodology called COPE (Create Once, Publish Everywhere) as a means of creating and publishing stories. COPE allows a content creator to enter a story into discrete fields in the CMS and the story can then be distributed via Application Programming Interface (API) in a way that allows for different platforms to publish the most relevant combination of story elements.
Besides the specific use by NPR, what this example suggests is that a content API that can store and distribute all the necessary content elements is, perhaps, the primary method to consider in the context of creating and distributing future-ready content. Assuming that the content creator has considered the rest of the framework and understands the purpose and meaning of the content, an API fulfills the remaining need to publish to different platforms quite well.
Have a comment or question? Send us a note. It won't be shown here and email isn't required, unless you'd like a