This post is about our work on the Publishing Platform, what we’ve done so far, what we’re going to do, and how that will all help simplify our publishing applications’ code base as well as helping us focus on building features that will support the content operating model.
The last time we wrote about the Publishing Platform, we talked about what benefits it will provide to publishers in the long term. In short, we’re consolidating GOV.UK’s publishing applications so that they use a single Publishing API.
It will make it easier to consolidate page templates across the publishing applications and help us make fundamental changes to navigation, orientation and search. It also allows us to build tools to support the content operating model, build new functionality in existing publishing applications much more quickly. Building new applications altogether will become simpler too.
We constantly review and update the priorities of the work we’re doing. Our priority is to finish moving all the page formats to the new Publishing API, so we’ve broken that work up into different stages, while making sure everything still works.
What we’ve already done
Our work on the Publishing Platform has focussed on completing stage 1 as outlined below:
Publication workflow
The Publishing API, which is the main application in the platform, already supports the basic workflow that is required by publishers such as creating/updating drafts, publishing and unpublishing. The most recent change is to ensure that content sent to Publishing Platform is valid - this means that publishing applications will be more consistent and reliable in the way they send data to the Publishing Platform.
Publishing apps that did not previously support content preview can benefit from the preview content functionality in the Publishing API.
Dependency resolution
Things like the navigational breadcrumbs will all be processed within the Publishing Platform too - this means that the publishing applications won’t have to grab page titles, metadata and so on individually. It all happens once in a centralised place, so we don’t have duplicated code, it doesn’t have to be rebuilt into new applications, and there are fewer things to maintain.
Simplified ‘Content Store’
The Content Store is a centralised place where the content for most of GOV.UK lives. That is why we need the Content Store to be fast, and to be fast it has to be simple.
The Content Store contained too much logic around dependencies, as it ensured that related page links are retrieved and processed every time a page was viewed - this created performance issues. Now it only has to be done once in the Publishing API, not every time the page is viewed - much more efficient.
What we’re doing now
Bulk republishing
As we move page formats to the Publishing Platform, all content using that format has to be republished. The most frequently used page formats took up to 60 hours each to republish! As we migrate more formats, that time soon adds up to slow our developers’ progress.
We’ve made some improvements which means republishing is now much faster, 6 times faster in fact.
Govspeak
Govspeak is our variant of Markdown (it uses simple punctuation instead of complicated tags and code). We decided to make the Publishing API render Govspeak into HTML instead of the individual publishing applications.
Doing it this way means that the publishing applications can send raw Govspeak to the Publishing API, reducing the load on the publishing applications, and means we don’t have lots of code doing the same thing.
Discovery on content history
Content history and logging is important to publishers and sometimes citizens to identify what has changed over time.
Publishing applications store change history for content items in a variety of different ways. We need a consistent way of recording this data in the Publishing API and providing it to editors in publishing apps and when appropriate, the way that we show it to users on the website.
What’s next
In the future, we’re going to look at:
- increasing reliability, future maintainability and documentation of the platform
recording and reporting performance data within applications - identifying anything new that will need to be built into the Publishing Platform to support Mainstream Publisher
- introducing more workflow steps in the Publishing Platform such as fact checking and second eye (2i) review
- the ability to schedule and un-schedule content publishing
- authorisation and permission-level security
Why this work is important
Our extensive technical work on the publishing platform this year will allow us to focus more on what comes out of the content operating model discovery.
We’ll be able to build tools that will make content auditing and the way we publish content possible across all the publishing applications as the data will be stored centrally.
This work will make it easier for our template consolidation team to start their work on reducing the 141 page templates we have across the different publishing applications. By consolidating templates, new features and functionality can be iterated consistently and more easily throughout GOV.UK.
The consolidation and API work will help us be more flexible in how we provide content change history to citizens.
We’re currently on track with our plans in the roadmap, but we’ll keep you posted on our progress with our future work as we continue to focus on making the publishing ecosystem more consistent and easier to improve.
Shilpa is a Senior Product Manager at GOV.UK. Follow her on Twitter.
2 comments
Comment by Dard Galle posted on
This sounds like you don't yet have a common services platform ?
Comment by Shilpa Acharya posted on
Hi Dard,
Thank you for your response. It will be very helpful if you can please elaborate more on this?
Thanks,
Shilpa