Structured Content in Five Steps
As federal government websites have grown over time, vital content has become trapped in aging content management systems. For many agencies, digital content exists largely as unstructured ‘blobs’ created via WYSIWYG editors: these blobs lack essential tags, such as informative titles and descriptions, that are essential to content delivery via new tools and services. Content management platforms like Drupal can help transform content to make it more accessible, but only if the content is “structured” in a manner that allows for that flexibility.
This sets the foundation, and impetus, for future-proofing your content. If you can’t easily lift your content from one system to another as technologies evolve, or repurpose your content for other systems, it becomes more difficult for users to find the information they need. For example, the U.S. Digital Services Playbook and Open Data Projects are supported by content that is groomed for a range of delivery mechanisms (i.e., social media) with components that can be read and organized in many ways.
Sadly, for many digital managers, making the upgrade from a blob-based system to a content management system that requires structure seems as impossible as putting toothpaste back in a tube. Don’t despair, it can be done!
Making improvements to content to prepare for a system upgrade is critical. Too often website designs support the needs of publishers and content creators, with navigation based upon office hierarchies or paper-based filing systems and not on user needs. Digital consumers today want to find data easily, using an array of digital tools – from smart watches to tablets and mobile devices: searches need to be deliver relevant results across multiple platforms.
So how can an agency revise digital assets to future-proofed content? We have detailed the five steps digital managers must take to prepare and structure content ahead of a platform migration or system upgrade.
1. Define the End Game
First, define the goals that equal success. What does “done” look like for each step of the process and for the ultimate result? For any project, a shared strategic vision, coupled with defined success metrics and milestones, is essential. Although secondary goals often vary across agency offices and content owners, having a well-defined and prioritized list of “must-haves” accepted by all stakeholders is essential for a successful migration or upgrade.
If a platform migration is looming, determine what amount of existing content (pages, assets, images, etc.) must be revised: all of it, or only top-level, prioritized content? What is the destiny for unstructured items? Will it be left behind, moved as-is, or refined and transitioned during a future work cycle?
As the content preparation begins, revisions to governance models and publication lifecycles will need to kick-off as well. Change management across the digital enterprise is an often overlooked—and underestimated—effort, but is paramount and digital transformation success.
2. Deconstruct the Data
Here is the real crux of the content preparation: taking a high-level view of ALL digital content while deconstructing each asset into core elements. For all of the content residing within the WCMS, details have to be examined and defined.
Survey the kinds of content available on the website and the delivery platform. A great way to approach this is in workshops with content managers and publishers. Distill the shared data elements: title, description, publication date, and author might be included. After defining global elements, turn to the unique items. What fields are required elements for one kind of content versus another? Content about events or locations, for example, contains many unique attributes.
Do not forget the non-HTML assets like files, images, and videos, as this content will also need structure. Consider current outputs as well: what emails or social media posts are connected to website publication? Are data streams like APIs or RSS feeds supported? Are there additional systems supporting the website, i.e. backend databases?
3. Design the Model
Once you have core content types defined, create a content model. This model must include relationships between content types and the fields that can be utilized cross-system; relationship modeling is essential to developing robust functionality and delivers on the promises of an improved WCMS!
The content model will evolve as types and data elements care are refined throughout the structuring transformation process.
4. Define the Elements
Structured content is the intersection of a functional model, discrete data elements, and organized relationships. Data is created and managed in the back-end for delivery to multiple front-end displays, and for processing by various services and tools (like Google Search). For any WCMS, dozens (or hundreds) of system fields are necessary to support true end-to-end delivery.
While it seems an overwhelming task to define every field, it is necessary work. When using a system like Drupal for content management, relationships can be built between any number of entities: content types, fields, and even specific values within taxonomies. A digital taxonomy is simply a way to organize items for optimum storage and retrieval.
To define the data elements you should:
- Identify the content types and fields (see Step 3)
- Determine the structured data formats and schemas to utilize:
- Will content support metadata, microformats, and/or rich snippets?
- Will data follow schema.org, Dublin core, or other conventions?
- Spec out the details for each field, noting:
- Default values and types,
- Visibility in front and back-end systems,
- Default values, and
- Mappings for fields to things like Google cards and other specific delivery mechanisms.
- Develop the supporting vocabularies – pre-defined sets of terms for organizing data
5. Deliver Results (Rinse and Repeat)
Once the content model, types, and fields are finalized, you can test the approach to ensure the back-end systems are usable, functionality is supported, and all key elements are identified.
Test workflows by allowing content editors, creators, and publishers to input and publish actual content using the WCMS. Strive for a simplified, user-focused creation and editing process. Assess whether additional data is required to enable review and unpublishing processes: review dates, expiration dates, editor and publisher approvals are essential fields.
Next, test the data delivery mechanisms and outputs. Do fields display as planned in Twitter feeds and Google Cards? Can APIs successfully pull the data elements? Is metadata supporting content findability as designed? If the agency website is the primary engine for delivery, is the structure supporting the front-end displays as desired? Can data-consumers retrieve the content they need in a useable manner?
As with any new functionality, you must build, test, and refine. If you are upgrading your WCMS, there will be many additional factors to consider; if your agency is migrating to a new WCMS, there will be a LOT of additional factors to consider! Either way, you will likely need to add content types, refine both global and unique fields, and create additional supporting taxonomies.
As structured content is refined and managed in the system, new requirements will come to light that you will *now* be well equipped to address. Continue to evaluate delivery against goals, conduct usability testing, adjust through iterations, and refine as necessary. As your revamped content begins to deliver on the promises of structure, share your success story with colleagues across the agency, the federal government, and the digital community!