In May 2014, Sarah Crane discussed the importance of structured content, APIs and the development of a “Create Once, Publish Everywhere” (COPE) strategy at USA.gov via a three part video series. After my recent post about a world without Web pages, Sarah and I connected and we discussed the challenges she has experienced during the COPE project at USA.gov and some lessons to consider whether you’re at the beginning or early stages of a similar project.
A Smarter Solution Needed
The decision to begin down the COPE path grew out of a fairly unique situation that exists at USA.gov: they have both a website and a fully-staffed call center to provide citizen services. Sarah found that instead of one content management system that fed content to both the Web and the call center staff, they had two separate systems:
- Two separate content management systems
- Two separate editorial departments
- Two separate sets of content
This created not only an inefficient situation, but also raised questions about the integrity of the data a citizen would receive from the Web versus the call center. To Sarah, it was clear they needed a smarter solution that would allow them to better integrate their processes and develop content that was easily sharable not only across the agency but also across multiple platforms and multiple sites. COPE would make this possible.
Structure First, Content Close Behind
From the start, Sarah and her team realized they were stepping into a different world. Instead of developing business requirements for a new CMS from the previous perspective of focusing on content creators or front-end design, they needed to look for something with a strong foundation in structure and metadata. This is a common consideration for anyone moving towards a more structured approach to content development, as many current content management systems are not well-suited to the COPE approach.
Aside from any of the technical considerations, one of the most important factors in a successful move to COPE is the work on developing your content models and taxonomies. USA.gov spent a year researching and developing their structure and then had to create or reconfigure over 200 pieces of content to align with that new structure. They also had to help their subject-matter experts and content creators begin thinking of content as individual pieces that needed to survive on their own and to always think content first.
The Challenges of Independent Content
Once the extensive process of producing structured and “free” content had reached critical mass and the time came to start reassembling this content on individual Web pages, a new challenge arose. Unrelated content was placed on the same page, some of the content was duplicative, and the pages were a bit of a mess. It seems it is possible to make your content so future-ready that when forced together on a Web page, it no longer works. A lesson that Sarah learned from this challenge is that at least at this stage, where Web pages still have to exist, having a final review of the whole is critical. You can’t always count on the concept of self-assembling content, at least not yet.
Finding Effective Metrics
Another challenge that Sarah and USA.gov are still wrestling with are establishing effective metrics for the independent pieces of content versus the final Web page. There is currently no effective method for measuring views of individual content assets, only the entire page (if you know of one, please share in the comments). Sarah has been using Crazy Egg as a cost-effective method of generating heatmaps to better gauge what content pieces are attracting the user’s attention the most, but that still feels incomplete, as Crazy Egg only measures Web views on the USA.gov domain and doesn’t capture traffic to content pieces that are syndicated to other domains.
It has also remained a challenge to measure content efficacy between their primary channels (Web and call center). For example, does information about UV protection seem to have more impact online or over the phone? Does prominent content on a certain topic online help reduce call volume on the same topic? A practical solution for measuring the relationships between these two significantly different content delivery systems is still in the future.
A final challenge Sarah discovered was not directly content-related but more about staffing and the API. When creating an API, you are essentially creating a service for the community to leverage and share. As with any service, consumers are going to have questions or need some form of support. APIs help automate and ease a great number of content related tasks and are the core of COPE, but they will still require some form of customer service and developer support.
For Sarah and USA.gov, the work goes on as they continue to make amazing progress on what was a significant undertaking. As with all projects, you learn and adjust as you go, and Sarah is already working towards solutions to the challenges she shared, including staffing and realizing the importance of final review in the content creation process. I hope the lessons she is learning are instructive for any of you heading down this road, and if you have additional experiences to share, please don’t hesitate to leave a comment. I might ask you for an interview next!
You’ve just finished reading the latest article from our Monday column, The Content Corner. This column focuses on helping solve the main content issues facing digital professionals, including producing enough content and making that content engaging.
Have feedback or questions? Send us an email at firstname.lastname@example.org