The Strategy for a Digital Public Service 2019 states that:
We will design and deliver an all-of-government framework, standards and tools that will allow the sharing of information across a variety of platforms, using open APIs and components.
In the All of Government Service Delivery team, within the Department of Internal Affairs, we’ve taken the first step down the road towards an all-of-government content API. We’ve been working with agencies to develop a structured content model, which is the first building block needed if we want to develop a way to share content across multi-departmental channels. Our next step was to develop a proof of concept to show how we would use the model to do that.
Government agencies generate vast amounts of information for public consumption every day. It’s published across websites, applications, intranets and knowledge bases. And it usually has to be kept up to date independently for each channel, which can involve multiple staff members and considerable time.
Plus, there’s the risk that something is missed, for example: the website is updated, but the knowledge base isn’t, meaning staff in the contact centres don’t have the most up-to-date information.
There has to be a better way to do this and APIs may be the way…
Proving the concept
Staff from All of Government Service Delivery, with the input of representatives from across over 30 agencies, are developing a structured content model concept. Three workshops were held late last year to work out how to:
- break down process content into standard components
- work out what components should prioritised.
Our goal was to take examples of prioritised components and show how we could technically share those chunks of content across different government websites, that use different content management systems (CMS).
Read more on the workshops in this blog post - Structured content — grouping and prioritising components. Workshop 3.
The first step was to create a content repository using a headless CMS. This allows us to store the content chunks independently. It also separates the content from the presentation layer of a website - so the chunks can be mixed and matched as needed.
We decided to use Contentful as our repository for the proof-of-concept as it’s relatively easy to set up and extract the content stored in it.
Using just the priority components decided at our workshops, we created a basic model and entered some sample data for testing. Content was entered using a 'page-like' structure, but the template contained defined sections: our prioritised components.
We used standard schema.org naming conventions for the components. Content labelled and 'tagged' in this way is:
- machine readable
- search engine optimised
- voice friendly.
Consuming the content
It was important to use an approach which was CMS agnostic to support a variety of agency content systems, so the proof of concept was demonstrated on both the SilverStripe and Drupal platforms consuming the content using a RESTful API.
Not only can both platforms consume an entire content page, but authors can select just the pieces of content they want, allowing people to pick and choose the content they need, for example a rates table.
This proof of concept also demonstrated that changing the content in the repository would automatically update both Drupal and SilverStripe instances.
We’re still in the early stages of this work but are currently:
- talking to other organisations (in New Zealand and overseas) who are developing or working with APIs
- investigating technical solutions for a content API
- discussing technical solutions further with agency stakeholders so the approach can extend to other content management systems
- creating a roadmap for this work and how it can be progressed
- analysing the workshop findings to further develop our structured content model.
If you’d like to be kept up-to-date about this work contact email@example.com.
22 January 2020