Content strategy is concerned with an organization’s selection, creation, maintenance, and distribution of its content over the web. A triad of themes has been emerging among its thought-leaders: The emergence of diverse channels that convey content, the need to cleanly isolate content from format through self-contained fields or “chunks,” and a revolt against thinking of content in terms of the “web page.”
These themes deserve a brief elaboration. Reflecting on them might affect our perspective and approach toward Joomla as a CMS.
Once upon a time, actually not that long ago, having a presence on the web was relatively simple. Whatever content an organization wanted to share on the Internet, it was through the traditional web page. We never thought about the qualifier “desktop” because what else would one use to view a site? And we never thought about “channels” because being on the web inferred “web page,” period.
As the web evolves, we are acknowledging a proliferation of various channels that also would like to consume and distribute our content: RSS, email services like MailChimp, public news tickers, social media, smart TVs, digital magazines like Flipboard, Google Glass, high-tech watches, in-car systems, proprietary data centers, and even print. Over the coming years new channels and new types of data consumption will emerge – types that we are not currently anticipating.
Channels that would like to consume our content expand well beyond the various mobile versions of a website. Any of these channels might impose constraints and expectatons that differ from the traditional web page. For content to be distributed through these other channels, our content should be stored and managed independent from web page formatting. Today, "being on the web" can no longer assume "a web page, period."
“Chunks” versus the “Blob”
Because the web originated as static HTML pages that lived only in a website, we allowed ourselves to create content according to the familiar desktop publishing model – content, formatting, and layout are bound together, created and stored as a single field. Some content strategists are referring to this as a “blob.” As the web matured, we eagerly embraced the single-field blob as if it were a canvas and the WYSIWYG editor were our brushes. They allow users not only to add content but also to format that content as to how it will look on the web page.
Early in the web we recognized a problem when our formatting didn’t work consistently across browsers. The problem became more noticeable when the formatting was too presumptive and brittle to accommodate both desktop and mobile devices. As we enter the threshold of delivering content for channels that are even more diverse than a smart phone or tablet, we will need to rethink our “blob” approach. Content needs a clean separation from the formatting and layout that assumes a traditional web page. In a multi-channel world the paradigm of desktop publishing fails.
The alternative to a “blob” is to break its parts into a set of fields, or “chunks.” Together the chunks compose the same content as the single blob, but each field has its own semantic meaning. Format and aggregation of “chunks” are applied by each channel, not bundled with the content.
Think of the title, author, and date fields that are separated from the body of an article. Think of the various fields within a contact record (first name, last name, email address, phone, etc.). These are examples of “chunks” that contribute to the whole. Each can be formatted and positioned differently, or even ignored in some presentations. Alternative layouts can leverage chunks to display the same content in different ways.
Chunks help us resolve multiple issues. First, a well planned and structured set of chunks should alleviate our dependency upon formatting with a WYSIWYG editor – or at least to reduce the toolbar to a simple set of buttons that support semantics without imposing style or layout. A field can remain pure content as the CMS applies the needed format for any given channel.
Second, by chunking our data we can provide multiple versions of the same semantic piece of data. This allows any given channel the ability to select the appropriate version of any given field or digital asset. For example, fields like title or description can be represented with multiple versions each varying in length and wording. In the case of an image, a channel might benefit by being able to select from multiple versions that differ in how the image is cropped, by its file size, or by the depth of its color palette. (This approach to imaging is followed by Flipboard.)
Third, each channel might require a different set of fields. By breaking a blob into chunks we can deliver a the appropriate aggregation of fields – not the all-or-nothing “blob.”
Our work within the CMS is to craft content structures that allow content to be free of the assumptions made by any one channel. This liberates content so it can be distributed interchangeably across a variety of channels.
The Business of Content
Karen McGrane tells the story of TV Guide. Back in the ‘80s and before the web, TV Guide was a top publisher. But they realized they were not in the magazine business – they were in the content business. Rather than store their content in the formatted print version, the content for each television episode or movie was isolated into independent chunks. The editors who wrote the summaries produced them in multiple versions of varying lengths. Patterns of data such as year, actors, title, etc. were stored in their own field types with semantic meaning. Today, technologies unknown in the 80s (such as web sites, cable networks, and smart TVs) tap in to this database to display this content that was written decades earlier.
In contrast, several other publishers have delivered their content embedded in the formatting and layout of a targeted platform – the desktop and perhaps a second version for the tablet or smartphone. As a result these publishers are struggling to port their content to multiple and evolving channels. TV Guide was successful, McGrane points out, by realizing that their real asset was content and that content should be cleanly separated from format and layout.
Death of the “Web Page”
The historical perception of a “web page” leads us to accept (a) layout and formatting is naturally bound to content and (b) that content is targeted only to a the traditional web page (without regard to other channels). This leads to the CMS being seen as managing web pages, not managing content that can live across diverse channels. Any CMS that manages web pages instead of content is not ready for the multiple channels emerging across the Internet.
A true content management system manages content. The content might be displayed within a web page, but content is managed as independent and cleanly separated from the web page.
If we are to maintain our content so it can be used across multiple channels, we need to change the mental model held by authors and editors: The concept of a “web page” can no longer be equated to the content itself. We need to stop referencing “web page” as content. CMS users need to start seeing content as something separate from the web page. The old perception of the "web page" must die.
This is certainly a challenging task. It requires a change in the user’s mental model. Instead of authors asking “How does this look?” they ought to ask “How does this read?” How difficult will it be for authors and editors to let go of their control of formatting? How will they respond to creating content without knowing where or how it will be used?
Joomla! in All This
These three interlocking themes (channels, chunks, and the “web page” as dead) were consistently emphasized by presenters Karen McGrane, Deane Barker, and Jeff Eaton at the Now What? Conference held in April. During that conference I had lunch with Bryan Ruby of the CMS Report. He asked me how well Joomla is going to handle all this. It is a question begging to be asked, and I’d like to share some thoughts here.
- Joomla is already a true content management system
- Its architecture is designed for maintaining content separate from its channel(s) of distribution. As we know, the same content can live in multiple pages and through multiple layouts that are provided by the component and its modules. I suspect a common reason why some CMS users don’t appreciate Joomla is that they embrace the web-page approach and fail to see the wisdom of a CMS focused on managing content separately from navigation and web pages.
- Joomla’s MVC model is set up to allow us to export content into any format. The default view mode is HTML (implemented by view.html.php), but we can easily extend the view mode by creating a new types: RSS, PDF, print, etc.
- The ability to extend Joomla with third-party or custom components enables us to choose or build structured data types that breaks the “blob” into “chunk” fields. Further, our ability to customize Joomla’s WYSIWYG editors and its layout templates enable us to reduce or eliminate the need for authors to add formatting to content.
- The mental model of Joomla as a content-first management system is arguably challenged. (a) We have a deeply engrained practice of creating blobs of heavily-formatted content – even to the point of inserting fully-formatted modules within text fields. (b) Front-end editing, which many clients desire, can reinforce the user’s mental model that he is editing a web page. The user is left unaware that a change on one page can be reflected in other pages or in other channels. How can we best empower the front-end author while protecting her from misperceptions? (c) The Joomla Roadmap proposes to couple content to the web page and to merge the backend with the front-end. Will an awareness of other channels lead to a rewrite of these proposals? If the work continues as proposed... Will this couple Joomla too tightly to the website model at the exclusion of other channels? Can this be implemented so that Joomla will remain a true CMS – a system that manages content independent of layout and the assumptions of a web page?
- The success of Joomla being used for multiple channels depends upon the community of developers and site integrators.
- Site integrators are the ones applying Joomla to the client’s needs. A CMS cannot by itself deliver success. Each project is unique and requires custom attention from the site integrator.
- The old approach is deeply engrained in us. The site integrator needs examples and education emphasizing the importance of thinking beyond the “web page” and toward thinking about pure content that will live across diverse channels.
- Once the site integrators grasp this approach, they will need help in educating their clients to think in terms of content and channels instead of the “web page.”
- Site integrators need tools for building chunks and replacing blobs. They need some education as how to structure content so that it is reusable across multiple channels.
Some will be skeptical that there is a need to use Joomla for serving up content across multiple channels. After all, the traditional web page model has been working for years. One might be safe this year and next by sticking with a single-channel approach with Joomla. Perhaps most of our clients today are expecting only that. But we know that web expectations change rapidly. We know that if a successful technology does not keep evolving, it usually fades and become irrelevant. If these thought-leaders in content strategy are correct and the future of the web will expand beyond the web page and into multiple channels, perhaps Joomla and our community ought to evolve in that direction.
I ask you the question asked of me, "How well do you think we’ll handle this?"