Rendering Content in the Manner It Deserves

The following is a guest post by Don Day, sometimes called the Father of DITA. Don was inspired to write this post to complete the thoughts in previous two articles about managing content (Friends don’t let friends manage content like data and Managing content in the manner it deserves).

———————

In Rahel’s previous post, Managing Content in the Manner It Deserves, she pointed out the unique features of document-oriented repositories over data-oriented repositories. She covered the particular scenarios of Creating content, Updating content, and Deleting content, which, along with Reading comprise the so-called CRUD behaviors of persistent storage tools.

I readily caught that she did not get into the Read/Render behavior of content repositories. That’s necessarily because creating, updating, and deleting tasks are all in the domain of authors and content owners whereas rendering the content is more outbound in nature, addressing the requirements of the reader.

When I asked if I could talk about adding the R part to her CUD discussion, Rahel didn’t hesitate: “Yes, please, let’s talk CRUD!” Given permission to be forthright, here goes!

CRUD swim lane diagram

The inbound things you do with content typically require different levels of authorization or permissions. The most basic policy is Non-Access, usually invoked for export compliance for intellectual property. Next up in scope, Subject Matter Experts and reviewers are typically assigned to roles that enable them to start new content (Create) but usually not to modify or delete the comments or initial content they’ve created. Editors are at the next level, able to create and modify content (Update). Writers are at the highest level, Creating and Updating content and having the additional authority toDelete content as needed, whether for housekeeping or in following retention policy. That leaves the role of Reading the content–getting it out to the user.

Once a particular document has been published, the Content Repository changes gears and starts providing functions that are specific to the outbound nature of the Content Repository: serving up resources in response to requests from readers.

The Complex Nature of Content Delivery

A typical “swim lane” chart of how readers interact with content usually starts with a request–someone has clicked on a link or typed an address into the location bar on a browser. The server parses the request to determine how to route it, and then calls on the Content Repository to obtain the requested item or search query. At the reader’s end, the interaction results in their seeing either a new page of content or a set of links or tools for navigating to more specific pages of content.

But it’s not always that simple!

  • Readers come to your site using a range of different devices, from desktops to tablets to smart phones to heads-up displays, so the content needs to be device-adaptive.
  • They come with a range of preferences or goals for how they want to interact with the content, so the content must be user-adaptive.
  • An individual reader may be a representative of a number of other potential readers whom you want to reach as well, so the content must be enabled for social roles (ease of sharing).
  • A reader may need audible or visually enhanced access to the content, so it must be enabled for assistive roles.
  • If the reader is accessing the content through an app on their phone or tablet, this happens through an API (Application Programming Interface) using specially encoded datatypes like XML orJSON.
  • And where publishing to additional formats is needed, such as to an eBook or PDF form of deliverable, the content should be presentation-neutral, enabling ease of reuse.

To provide these particular Read/Rendition services, the Content Repository needs to behave like a negotiator, balancing the special needs of content consumers against the ability of the content to meet those needs. And the form of content best suited for being adapted into all these Reading roles is structured content with rich metadata and semantic markup (which Rahel has demonstrated using DITAas an example).

There are easily dozens of talking points here for Rahel to cover in upcoming posts. Without adaptable content in a document-oriented content repository with rich publishing features, we’d be at the end of the comparison with data-oriented repositories. Vive la différence!