April 2019
Text by Joe Girling

Image: © yoh4nn/istockphoto.com

Joe Girling is business development manager at Congility. Congility (Content with Agility) is part of the Mekon group. Mekon has been in business for 28 years helping companies maximize the value of their content. Congility specializes in building dynamic delivery solutions.

joe.girling[at]congility.com


http://congility.com

Do you need a content delivery solution?

Two sides need to be considered carefully before implementing a content delivery solution: What content publishers need and what end users expect from a system. Here is a checklist of requirements that can help companies decide what’s initially important and how the solution might evolve over time.

In my experience, successful content delivery solutions evolve over time, with changing business needs and user feedback being the key drivers of the evolution. At the start of a project, you may have an initial expectation of functionality for your content delivery solution and use MoSCoW or a similar technique to prioritize, perhaps arriving at a minimum viable solution and some future releases. This evolution means it is very important to choose a platform for your content delivery solution that is both extensible and open.

Here is a list of typical functional areas to be considered when planning a content delivery solution:

 

  • Content
  • Accessing content
  • Delivery platform
  • Personalization/interaction
  • Integration
  • Reporting and analytics
  • Business and support
  • IT

In this article I will only focus on Content and Accessing content.

Content

Content can be broken down into two areas: Sources of content and publishing content.

Sources of content need to be identified. Many formats might need to go into a content delivery solution, each with its own requirements and each not necessarily as straightforward as you would expect. For most of us, XML/DITA, PDF, Word, Markdown, content from existing WIKI, HTML, developer documentation, etc. will be likely sources.

Is your content current or legacy content? If there is legacy content, can you simply link to it and focus on the current content? This would apply, for example, to old web help outputs that still need to be available.

Next, establish where the sources of content are stored and who owns them. You may need to engage with other teams to establish responsibilities and the right processes to access the content.

Do you need to migrate content sources from one format to another? If migration is required, is it a one-off process (e.g. for legacy content) or a repeat process needed each time content is updated?

Finally, ask yourself: What is special about your content? What are you doing with your content that is important to consider and make allowance for once it is delivered? Consider, for example: 

 

  • If you are working with metadata, what is it used for? What will be the expected outcome in the delivery system? Metadata requirements vary significantly between different organizations.
  • Are the specializations used in your content important in how content is delivered?
  • Do you have media files such as 3D images, videos, or interactive SVGs?
  • Do you plan to deliver API docs?

Publishing content. Having identified the types of content that will be used in a content delivery solution, consider how this content is uploaded, managed and updated.

A content management system (CMS) or GIT repository might give you the option to publish directly to the delivery system. But what features of those systems do you use that might be important, and how should they be reflected in the published content? When creating content, you might be using these types of features: branch, snapshots, versioning, languages and metadata. Consideration needs to be given to how these features are reflected in the delivery solution. As well as using metadata within the source content itself, there may be CMS-level metadata that you want to make use of in delivery.

Ask yourself: When the content is published, are XML/DITA type formats automatically converted to HTML and PDF? What degree of automation can be used? Some formats may need manual preparation and manual upload.

To create a dynamic solution, the content and metadata need to be indexed. This leads to the question of what needs to be indexed. It will probably be the full text, metadata in source content and, in many cases, also the CMS-level metadata. For example, some CMSs will use CMS-level metadata partly to facilitate searching within the CMS. Will you need to use this when delivering the content?

Updating is an important consideration, particularly when working with different versions of the same content. Find out how often content is updated. Also consider whether you just need to update a single version of a document and make it available to users, or if you need to publish multiple versions of the same content at the same time and allow users to select the appropriate version for themselves.

Image 1 shows a content delivery solution in which the user can select from multiple versions of a piece of content, where some of the older versions are legacy content in PDF format.

Image 1: Multiple versions of a piece of content: The newer versions in HTML, the older in PDF.

 

Finally, when publishing content, you will probably have a requirement to test updated content in the delivery solution before it is released. This means that you will need a space where you can experiment with new ideas without affecting the production of your content delivery solution. This means that, in addition to being able to publish into a production server, you may also need the ability to publish to staging and/or development servers. Typically, these servers need slightly different content. Staging content, for example, might come from a different branch in your CMS.

To give you an idea of how apparently simple publishing requirements can have hidden depths, let’s take a look at a requirement I often see: The solution must support PDF. However, you need to consider many factors regarding PDF content:

 

  • Does the PDF content need to be searchable and displayable in the browser?
  • Is PDF just a download format for other structured content (hence there is no requirement for searchability)?
  • When are the PDF files created? Manually in the CMS or automatically when content is published to the content delivery solution?
  • How are PDF files linked to their source publication? Manually or automatically when they are created? How is metadata applied that links PDF files to source publications?
  • Are legacy PDF files uploaded one by one or as a batch?
  • Do PDF files download or open in the browser window?
  • Do PDF files need to be watermarked in some way, for example, to indicate that they are an uncontrolled copy?
  • If using personal collections, should a user be able to create PDF files from their collection?

In the example above, the older “legacy” versions of the content are in PDF format and are linked to the newer versions of the publication by metadata that has been added to a library of legacy PDF files in a batch pipeline publishing process. This ensures the PDF files appear correctly when searched and displayed in the delivery solution.

Accessing content

Accessing content can be broken down into four areas: permissions, finding, viewing and interacting.

Permissions

Will your content delivery solution need to be public, private or both? Very often both are required. While delivery solutions themselves might only be public, there may still be a need for private content. This might include customer-specific content or test content that needs to be checked if it works correctly before it’s released.

Public content may differ from the versions that are available to authenticated users. For example, content might contain information on restricted intellectual property that you wouldn’t want to make publicly available, but those having agreed to your legal terms and conditions might be allowed to view it.

You also need to consider if there are groups of users defined in a User Authentication or Single Sign On application. You might need to check their information against an entitlement server to determine the content these users are entitled to access.

I also often see the need for different degrees of findability, where users might have different levels of access to content: full access to some and limited access to other content. Thus, a full text search will provide users with full access to some content, but only limited access to other content. Limited might mean that they can see that the content exists, but not be able to view it without appropriate permissions. Or, it might mean that they can view the content, but only see a small section of it – perhaps just the short description.

Finding

There are many ways in which users can find the content – it’s not just about search! I’ve broken them down into five groups that would typically require implementing more sophisticated techniques:

1. Support portal

A support portal or content delivery solution will typically offer the ability to browse for content and provide full text search and faceted filtering. This is really what you might consider to be the minimum viable product for your content delivery solution. While browsing through groups of content requires some form of defined hierarchical structures, faceted filtering relies on metadata and perhaps some form of taxonomy for your content. Full text search alone does not require metadata or taxonomy. However, it can benefit from metadata, boosting results when keywords are matched with metadata or a taxonomy.

Defining a taxonomy doesn’t need to be a complex and expensive task in its own right. In its simplest version, it might cover the basics that you need: Product groupings and tasks.

2. Contextual help

A more contextual delivery of content might be required: embedded content, context-sensitive help, barcodes. This will typically require extra effort. Each of these options relates to an integration with products in some way. This might be sharing content resource IDs with software developers so that context-sensitive help/embedded help can retrieve the correct content. It may also require liaison with your manufacturing team to ensure barcodes are added onto your equipment so that they can be scanned to trigger content delivery.

3. Suggested, recommended or mandatory content

This type of content requires the delivery system to offer content that the user might need. But what is this based on? Suggested content might be based on reading content with comment metadata. Recommended content might be a more tailored list of content based on some other positive enforcement. Users may be required to read mandatory content before they can proceed. This refers, for example, to safety warnings and legal statements. Mandatory content may also need to be acknowledged by the user before more content is displayed.

From a requirements perspective, the system might need to index metadata that you are using in content and store information about content usage. Mandatory content also requires appropriate metadata to know that one piece of content relates to another.

4. Visual navigation

Visual navigation can be particularly useful for navigating large machines. Users can drill down through a series of images until they get to the content they might need. The main issue with visual navigation is deciding who is responsible for creating these images. For complex product applications, they may be automatically created from a CAD system. For more simple products, marketing often supplies the images.

5. AR and chatbots

Lastly, Augmented Reality and chatbots provide methods that are becoming more popular and typically require integration with third-party specialists to support implementation.

Viewing

While online viewing of content across devices (laptop, tablet, mobile) is straightforward to achieve through a responsive website, a requirement for offline viewing needs more consideration. A degree of offline function can be realized through a browser’s ability to cache content. However, the standards for taking content offline using browser caching are deprecated, making this an unreliable technique. Another simple approach is to enable the user to generate and download a file of content to take offline (e.g. HTML, PDF, etc.). But this means that the content authors typically lose control of the content in terms of changes and updates, once the user has an "uncontrolled copy" of the content downloaded. The most robust method for taking content offline is to use native apps. Native apps can be engineered for desktop and mobile devices, which enable content to be downloaded onto the device for offline use, while also allowing changes/updates to the content to be automatically incorporated as the device moves between offline and online.

Most content delivery solutions will need to create multiple links between content items. This is often more than simple cross references. For example, if you are looking at content for Version 3 of a product, cross-content links should take you to the equivalent version. If you switch to Version 2, then the same link should also go to Version 2 content. It is important to consider how you define these links in your source content and ensure that the delivery solution interprets them correctly.

Another important consideration is the level of customization/control of the look and feel of the content delivery solution. Do you require simple skinning/branding of a standard look and feel, control of style sheets or a fully custom look and feel? Perhaps you have an in-house development team that needs control over the look and feel of the solution.

There are multiple other considerations for viewing content. Although many considerations might seem to be minor details, they are important to consider in your requirements to ensure they can be implemented correctly in the delivery solution.

Interacting

There are common features of a content delivery solution that enable users to interact with the content. These include:

 

  • Creating personal collections of frequently used content
  • Annotating content (e.g. personal notes, providing feedback or rating content)
  • Sharing content through different channels
  • Creating new content within the delivery solution (e.g. FAQs, erratas, new articles, etc.)
  • Acknowledging content (e.g. important safety notices/considerations)

Typically, public users can only view content, but logged-in users are able to further interact with the content.

Different types of users may need to interact with the content in different ways. A salesperson may need to assemble custom collections of content, then publish and share it. A field engineer or technician may need to pause steps of task-based content, perhaps video or simulations.

Interaction with the content often needs to be managed and tracked. New annotations and content created will need to be moderated. User acknowledgments of important content may need to be logged.

Letting it grow

In this article, I have covered some of the important considerations when implementing a content delivery solution. I would like to emphasize that most content delivery solutions evolve over time due to changing business priorities and user feedback. With that in mind, the most important consideration is to choose a platform for your content delivery solution that is both extensible and open.