Versioning
This is our current thinking on how we might handle versions in the GOV.UK Forms product. This originated as a spike in February 2022, but we intend to iterate it as we learn more.
We are fairly sure we will need a way to handle versions at some point but exactly what form this takes, and when we implement it, is a question we think is best answered during private beta.
graph TD
B(Draft)
B --> |Submit for review| C(Review)
C --> |Edit after review| B
C --> |Publish reviewed form| D(Live)
D --> |Manually unpublish| E(Unpublished)
E --> |Edit form| B
This flow has no native way to update a form without unpublishing it. This would mean that updating a form would be tricky - have to make a new form, get the link on GOV.UK changed, then unpublish the old form. Clunky, but guarantees that the change goes through the GOV.UK publisher, so it introduces a degree of quality control. This implementation would make it easy to handle users who are filling out a form when the form changes (they’ll stay on the old form by default), but creates a few issues:
-
Old forms will hang around until they’re unpublished, which will require some manual management
-
No clear way to tell which forms on our platform are unique and which are multiples of the same form
-
More work for GOV.UK publishers
This is unlikely to be a long-term solution, but maybe this is enough for the initial release during private beta.
graph TD
A[New version] --> B(Draft)
B --> |Submit for review| C(Review)
C --> |Edit after review| B
C --> |Publish reviewed form| D(Live)
D --> |Manually unpublish| E(Unpublished)
D --> |Publish another version| E
D --> |Edit form| A
E --> |Edit form| A
Here we’ve added the concept of ‘versions’ within the platform. These are created when someone tries to edit a Live or Unpublished form. This would make it easier to roll back to previous versions of the form, or to abandon an unwanted draft. In this model we don’t bother creating versions when a draft or review form is edited, in order to reduce the number of simultaneous versions of the same form - we assume that a version is only worth taking a snapshot of when it goes live. This model could work well with the comment-based reviewing in the publishing prototype - if we attach the comments at version level then we can avoid the situation where long-lived forms have years worth of comments, and make it easier to see what changes the comments apply to.
A simple interface for managing versions might look something like this:
Editing one of the older versions would create a new draft version, and make it the current item:
Whitehall has a concept of versions (which they call ‘editions’). It seems to work similarly to the ‘simplish versioning’ flow detailed above. After a form has been published, users can create new versions.
It looks like only one draft edition can exist at a time - so once a draft edition has been created editors are expected to either edit it or discard it and start again.
They do have a way to compare versions - this is a nice feature, and probably something we could do, but could easily get complicated when not using plaintext and markdown content.
‘Create new edition to edit’ button creates a new draft version of the item:
Comments (‘remarks’ in Whitehall) are attached at version level:
Whitehall has a diff tool for comparing versions:
We ended up implementing an even simpler form of versioning, without the review steps or the ability for users to manually un-live a form. This is roughly how versioning is presented to users in the platform:
graph TD
A[New form] --> B(Draft)
D[New draft version] --> B(Draft)
B --> |Make your form live| C(Live)
C --> |Make the form unlive with rake task| B
C --> |Create a draft to edit form| D
This document provides a broad overview of our possible approach to versions, but we intend to iron out the details in Private Beta with real users. Things we're interested in experimenting with include:
- Where is the right point in the form lifecycle to save a version? In the 'Simpleish' proposal we're assuming that it's when a document gets published, which feels like a reasonable starting point, but users may want it to happen at other times.
- Do we preserve the comments on older versions, or should these be considered temporary?
- How transparent should the versioning process be? Is it something users will want to be aware of when they're working on (as it is on Whitehall), or should it be something that happens in the background?
- What happens for an end user when a new version is published? Do they continue filling out the old version? Are they redirected to the beginning of the new form? Would we want to vary this depending on whether the change is minor?
There will be lots of interaction and content design concerns not thought of here.