[ON HOLD] Technical approach for flexible pages

[andysellick]

Rendered version: https://github.com/alphagov/govuk-rfcs/blob/flexible-pages/rfc-182-flexible-pages.md

2025/04/30 We've decided to put this RFC on hold for now, as it proposes some ideas that we can't prove meet user needs - since we're still working to determine user needs. However we do have agreement on the MVP aspect of this RFC, so we will move forward with that and revisit the RFC once we know more.

[ChrisBAshton]

I'm going to open with perhaps a controversial opinion: I actually think the "Limited control" option is the way forward, at least for MVP. I suggest this RFC is reduced in scope accordingly (perhaps with a "Future thinking" section outlining what the "middle ground" solution could look like in a future iteration).

From what I’ve witnessed on the Brexit, Covid and “Landing Page” pages, stakeholders don’t want "flexible": they want "bespoke". It seems to me that we’re inevitably always going to have to hand-craft a page template for whatever the next high profile event will be. The biggest issue I can see with that is that there has been no way to allow publishers to update the content of the different bits of the page. When we distill the problem down to just "give publishers a way to update the content of the bespoke page", it makes it so much simpler: publishing's job is now to define some key/value pairs up front, and expose a basic interface for editing those values. The frontend's job is to take those values and plug them into the relevant bits of the page.

This shift in mindset isn't mutually exclusive from what you've proposed below. It is effectively what you're already proposing for your "Option 2: select a preset page type". I think we should start with just that, and we can always iterate to a more flexible "middle ground" option later once we've built that foundation.

Going with the "limited control" option will still give us:

• A dynamic rendering of 'flexible_sections' in the frontend
• A dynamic rendering of a publishing UI form, based on pre-agreed flexible_sections
• Quick turnarounds: spinning up a new 'high profile landing page' would be as simple as defining a new document type that uses the flexible_page schema, and defining which flexible_sections are allowed. You/we can develop new bespoke flexible sections to accommodate whatever the new thing is that's needed for the page.
• Crucially, publishers are given control over the content / copy, without having to touch YAML.

[andysellick]

I think "bespoke" has been the preferred option for stakeholders for a long time because they haven't really had any alternative. The advantage of the proposed flexible page for the next Coronavirus type page is that once we've got far enough down the road we'll have most of the functionality we're likely to need, it'll be quick to spin up, content editors can modify it with relative ease, and in the meantime developers can work on any new flexible sections that might be needed e.g. a new page header.

My concern with making this too limited (and I agree, it's a fine line to tread) is that from a content authoring perspective we end up adding more page types to an already over populated landscape. We also need to make sure that we provide enough flexibility to make this useful - otherwise people won't use it.

I think maybe what this document doesn't cover adequately (and this will be something to address maybe a little bit later) is the rules around content authors managing flexible pages - who is allowed to do what, different permission levels, any additions to the approval process, 2i, etc.

[andysellick]

@ChrisBAshton I think I agree with your suggestion on this, at least for MVP. I've updated the RFC to reflect this.

[ChrisBAshton]

I'm not sure I understand either option very well. Can you expand on them a bit?
Would it also be worth considering whether Content Tagger could be utilised for this? (I think it only currently allows tagging to mainstream content, but might be worth considering how to expand it for flexible pages)

Whitehall already has options for tagging pages to organisations, topical events, ministers and so on (example) so I'm hoping we can just reuse that as much as possible.

[maxgds]

I think the former is "find things tagged as X" which the PfC pages do - in that case we were able to create appropriate tags to tag things to as the missions deserve their own specific taxon. I think the latter is not adjusting the content, but having a local-to-flexible-pages solution where it could be somehow fed a bunch of content items or URLs to link out to. This would allow more creative control for publishers to curate their own lists of relevant things where the page subject might not necessarily warrant a taxon. For example suppose some of the history pages wanted to list all goverment building pages, and others wanted to list important positions in government as things to click out to the detail on. We probably wouldn't want to create a taxon that specific. Also, we've already seen in PfC that Number 10 wanted a link to something they didn't publish on their page - they couldn't go in and tag it appropriately because they didn't have editorial control, so we had to act as a go-between, asking the relevant party to add it. I suspect for different use cases we might want to have both mechanisms available.

[andysellick]

I've trimmed down this section after discussion as this is a future consideration and not relevant for now.

[ChrisBAshton]

This feels like a solved problem with the new Content Block Manager. But agreed, let's cross that bridge when we come to it (and just accept any duplication of content in the meantime).

[andysellick]

Looking forward to hearing more about the Content Block Manager, I think there's a session scheduled soon.

[ChrisBAshton]

This seems unnecessary detail to include in the RFC if we're not really proposing doing anything new.

Suggested change

	Page view and link tracking is handled automatically for all pages on GOV.UK. Tracking is also built into all relevant components by default, for example when details elements are expanded or collapsed, however some additional information may be necessary (for example the total number of details elements on a page). Future work on tracking for flexible pages could include:
	- the ability to enable or disable tracking on flexible sections through the publishing interface
	- the ability to add extra information into tracking for a flexible section
	- a toggle to enable/disable scroll tracking on a flexible page
	For MVP no tracking options will be included other than the default.
	Page view and link tracking is handled automatically for all pages on GOV.UK. Tracking is also built into all relevant components by default, for example when details elements are expanded or collapsed, however some additional information may be necessary in future (for example the total number of details elements on a page). For MVP, no tracking options will be included other than the default.

[andysellick]

@ChrisBAshton I've reduced the detail in this section as suggested.

[ChrisBAshton]

Again, this feels like a big headache that can be avoided if we stick to the "Limited control" approach (see my first comment). We would therefore just use the existing 'document_type' methodology, rather than relying on tags: so long as documents are using the same flexible_page schema, it'd still be very quick to add a new page type in Publishing API etc. E.g. document_type: history_page, as you've put in the example schema above.

[maxgds]

I think there might be two levels of category needed eventually. In a world of many departments and many use cases there are two considerations that you could label as microsite and document type. We need that microsite label to be able to contain specific sets of flexible pages for treatment, both in terms of giving access to the right editors and letting them see which things form a whole, and sharing things across them like design and shared blocks. For PfC for example, the microsite is PfC and the document types are something like "homepage" and "mission page" and at one point there was also going to be a "data page". Those things are different enough from one another that they probably want to be defined separately, but they need to be unified as a specific thing as well.

Likewise if a topical event could be split across multiple pages with different concerns, you'd still need to be able to group those concerns into distinct events.

[andysellick]

I've trimmed down this section considerably.

[ChrisBAshton]

IF we are to allow the "middle ground" solution (see my first comment):

I think there needs to be a section of the RFC outlining every constraint / assumption we're making about every flexible section in scope for the MVP, which we can use as a requirements spec when building the interface. For example, apart from "page title should always be first"...:

• Will we also limit to just one "page title flexible section" per doc?
• Will we mandate that there is at least one?

Probably best to use the "Required flexible sections" section for this.

[andysellick]

@ChrisBAshton I've updated the "Required flexible sections" section as suggested.

[ChrisBAshton]

All of the above looks great. And from a Publishing perspective, iterating on existing 'flexible sections' - rather than adding new 'flexible sections' when the tiniest deviation is needed - is also a good way forward. We have experience of taking a pre-agreed schema and then dynamically rendering a form for said schema, and we have experience of iterating the schema and form to allow for new features.

[ChrisBAshton]

It sounds like you're proposing a new workflow - but just to be clear, I think we can accomplish the above from our existing workflow.

1. Click New document
2. Choose a radio button option for general document type (e.g. Consultation, Publication...). It's at this point you would choose "Flexible page" or something like that.
3. When you've submitted your choice, you're taken to the general document type page (e.g. publications) where you can then specify a subtype (e.g. Policy Paper). I suppose at this point we could hook in and render the flexible sections form with JS.

Aside - are we proposing making the Landing pages document type the thing that folks will choose on step 2? Or are we making a new thing?

Aligning with Whitehall's existing workflows reduces code complexity and also opens up opportunities for making our existing types more flexible in future (i.e. all pages can be considered 'flexible pages' if you squint a bit). We could potentially migrate all of our existing document types to each have a preset 'flexible_pages' layout that matches their current layout, and therefore take the same consistent approach to managing all of our content 🎉

[andysellick]

If we can use an existing workflow then that'd be great.

Landing pages aren't part of this proposal (even though they share some common ground with flexible pages). We're going to be dealing with them separately in due course.

And yes, there's a possible far distant future where everything on GOV.UK either becomes a flexible page or is migrated to a flexible page.

[andysellick]

I've reworded this section to be shorter and not imply the creation of a new workflow.

[ChrisBAshton]

This all looks good to me. 👍 But do you have any thoughts as to how we share the definition of a specific flexible section between publishing and frontend? Are you picturing:

1. some sort of shared 'gem' that publishing and frontend can pull in?
2. some sort of contract / Pact test between Whitehall and frontend?
3. or perhaps a section of Whitehall that the Patterns & Navigation team would 'own' (describing a flexible section's fields & required/optional status etc in YAML)
4. or relying on the two teams being able to have a shared understanding of requirements by talking to one another?

(Same question also applies to "how do we share the definition of a preset layout of flexible sections")?

[andysellick]

That's a good question, one that I don't think we've thought through yet. I guess I was hoping we can make do with option 4, but maybe we need something more formal/structured?

[andysellick]

I've added a brief section about this based on our recent conversation, in future considerations.

[leenagupte]

or perhaps a section of Whitehall that the Patterns & Navigation team would 'own' (describing a flexible section's fields & required/optional status etc in YAML)

This is something that Content publisher experimented with to make adding new document types easier to add. The YAML structure would need very good validation.

Could content-schemas be used to define a flexible section?

Whatever solution is decided on, option 4 should always be a part of it.

[ChrisBAshton]

Good idea. Strong +1 for auto-generating from the content. That'll be on publishing to try to implement. 👍

[ChrisBAshton]

I'd like some more detail on this. Are we expecting quite a tightly scoped schema per page type/layout, or are we expecting one generic 'flexible_page' schema that effectively allows anything? The answer to that would affect how quickly we'd be able to roll out new page types in the event of 'the next big thing'.

For what it's worth, I've spent most of today trying to map out the work required in the publishing space to support this RFC. Please do take a look!

[andysellick]

I've reworded this a little so that this is an example of what it could look like, rather than what it should look like.

[ChrisBAshton]

Thanks for the edits, @andysellick ⭐ I have a few more proposed tweaks to descope the RFC a bit further in terms of just concentrating on preset layouts for now, as I understand there are still conversations happening about the need for a more pick-and-choose-flexible-sections middle ground. I don't think that should be baked into the RFC: it's enough that the proposed system explicitly allows for such a feature in future.

Happy to approve with those edits applied ✅

[ChrisBAshton]

I propose a rewrite based on recent conversations and a decision to go with preset layouts at least for MVP:

Suggested change

	Neither option is desirable. Limited control would defeat the point of a ‘flexible page’. Full control could lead to a loss of consistency across GOV.UK content, potentially create accessibility issues, and create a system that would be extremely difficult to edit and manage.
	Instead, we propose a middle ground, where users cannot control page layout but can construct pages from a series of pre-built flexible sections, into which specific content can be added. This will help to preserve and protect the GOV.UK brand, the consistency of GOV.UK pages and their accessibility.
	The former is undesirable, as allowing full control could lead to a loss of consistency across GOV.UK content, potentially create accessibility issues, and create a system that would be extremely difficult to edit and manage.
	The latter is what we're proposing implementing for the MVP (see [Candidate for MVP](#candidate-for-mvp)): 'flexible sections', dynamically rendered, but ultimately as a fixed preset layout.
	Longer term, the frontend implementation is agnostic of whether a layout is preset or not, so allows for a middle ground approach. It would be quite possible to build a system where users cannot control page layout, but can construct pages from a series of pre-built flexible sections, into which specific content can be added. This would help to preserve and protect the GOV.UK brand, the consistency of GOV.UK pages and their accessibility, compared with offering "full control" outlined above.

[andysellick]

I've added a bit into the MVP section to clarify this already.

Just to clarify - we're definitely not proposing that users have any control over page layout. Each flexible section will have its own pre-determined layout, and will occupy a full horizontal section of a page - and users will only be able to add content into them. It would be desirable to allow a variety of flexible sections to be added in different orders to allow more flexibility, but I think since no layout options are involved the interface for modifying this should be relatively simple (it's basically a reorderable list).

[ChrisBAshton]

I understand that each flexible section has its own pre-determined layout and that we're not proposing providing control over page layout 👍

What I'm suggesting is revising the wording around the ability to arbitrarily add/remove/reorder flexible sections, for MVP (but alluding to it being a possibility in a further iteration, as in the suggested text above). This is for a few reasons:

1. It isn't needed to deliver the MVP - which I take to mean, essentially, "moving hardcoded text out of a bespoke page and into a CMS".
2. That is potentially all that will ever be required. Conversations are still underway over what problem we're trying to solve exactly: allowing publishers to edit the content of predefined bespoke pages (albeit represented as flexible sections under the hood) arguably solves all past use cases for this work (Brexit, Covid, PfC etc).
3. There's a fair bit of added complexity in allowing a "pick-and-choose flexible sections" builder.
   • Using the reorderable list would be a sensible implementation for that, but it only manages one aspect of pick-and-choose, i.e. it doesn't handle add/remove functionality.
   • This functionality would also add complexity/restrictions around validating the schema, i.e. having to enforce exactly one page title and it being the first flexible section in the page, which we would otherwise enforce by rendering a fixed form based on the predefined schema for a history page.

I can certainly see us iterating towards such a system in the near future, but I think it should not be set as an expectation in this RFC, and that the scope should be made clear early on in the RFC (in this Proposal section).

[maxgds]

I'm not entirely convinced, Chris. If we take out the flexibility then what are we progressing/learning? In fact where's the flexibility of the flexible type? We know that Brexit and Covid pages were not identical. We know that people desire more flexibility in Topical Events. We know that campaign sites are not all the same. We might end up with a growing menu of page types for re-use that allow all that validation to be easy, but what about the point where we're building something new from the growing kit of parts? We already know we can put content in a CMS and make it appear on a website. The whole point of this proposition is to start figuring out the complexity of building moveable/swappable parts into pages, and how to overcome that complexity, isn't it? If we design a history page to a constrained model then all we've solved is not having that page type hard coded in a frontend app and we definitely know that this is only the first step.

[andysellick]

I agree with Max. I get that there are technical and other problems around designing and building the more flexible end of this proposal, but we have to work towards that. We don't know exactly what that will look like yet and there's a long way to go - I definitely agree this won't be part of the MVP - but we need to provide more to content authors than we currently have.

I've updated the text to emphasise that the MVP will not contain the ability to add/remove/reorder flexible sections.

[richardTowers]

This seems like the one outstanding controversial point on the RFC, so putting my thoughts here.

There's still flexibility in the way the frontend is built, even if the user doesn't control the arrangement of flexible sections. The frontend is flexible in the sense that it will render whatever the publishing app gives to it (by looping through the sections in the order it finds them, and rendering a partial for each one).

That flexibility could make it through all the way to the user, as the RFC currently proposes. But (as the RFC also proposes), we would want there to be some limits to that flexibility (e.g. history of building pages must have exactly one page title section, and it must be the first section in the list).

But the flexibility could also stop short of the user - we could make it so that it's extremely easy for our developers to create new arrangements of flexible sections, or to change the arrangements. That's still more flexible than what we have now, and I think Chris' point is that that may be all we ever need, depending on what needs we're trying to meet (which will hopefully crystallise as we do some discovery work).

If the RFC is intended to provide an MVP scope, then I guess the question is "is this idea still viable without the publishing user being able to add/remove/reorder sections?". I think the answer is "yes", particularly if it's scoped to history of building pages where publishing users won't choose or reorder sections.

If a product is Viable without a feature, then for it to be Minimal it shouldn't include the feature.

I do think there remains a question of "what are we hoping to learn from doing the history of building pages?" though. I think two main things:

1. That we can implement a frontend which renders a list of sections as it finds them in a content item
2. That we can implement a publishing system which can generate an content management interface for a list of section types as it finds them in a preset layout

We've already demonstrated (1) to my satisfaction in the PfC work, although the model is too flexible (e.g. with layout blocks permitting arbitrary content). So this would be an iteration on that, showing what the frontend code would look like for a structure we're happier with. I'm already 100% confident we can write this code, so we're not learning whether this is possible, but more "what would it look like / feel like to have code like this in the frontend".

We haven't demonstrated (2) in the PfC work (you'll remember that the "user interface" is just a YAML editor). We have done similar things with the specialist documents work, but I don't think we've conclusively proved that we can go from a configured layout of these "flexible sections" to a good user interface. So I think there's valuable learnings there.

To be clear, this isn't an argument against allowing users to add / remove / reorder sections in future. Only that we don't need that feature for an MVP. I think we should consider adding / removing / reordering sections as a probable (if not certain) future requirement, and try to write the code in a way that would allow us to add that functionality later.

[ChrisBAshton]

Suggested change

	A flexible section should be designed for a particular use and only allow content within its layout based on that use. Users should be able to choose a flexible section and add content into it, but have little to no control over how that content is positioned. Users should be able to change the order of flexible sections within a page.
	A flexible section should be designed for a particular use and only allow content within its layout based on that use. Users may be able to choose a flexible section and add content into it, but should have little to no control over how that content is positioned. The frontend should allow for flexible sections to be rendered in any order within a page.

[andysellick]

I've reworded this based on your suggestion.

[ChrisBAshton]

This is now covered by above suggestions:

Suggested change

	### Flexible pages preset layouts
	A further improvement to creating flexible pages would be to provide preset options for creating particular page types. Users would be able to either start from a 'blank' page (allowing the insertion and reordering of flexible sections) or choose an existing page type e.g. history of a building page (where the required flexible sections are automatically added and cannot be reordered).

[ChrisBAshton]

This is now supported in theory, on the Frontend: alphagov/frontend@8ea7bf8