It’s a fair assertion that when interacting with a government service you’ll probably need to fill in a form. Here on the Digital Service Platform during our recent project for Biometric Residence Permits (BRP), we set ourselves a goal of trying to make the creation of forms as simple as possible.
Before we began development we identified that within the Home Office some great work had already been done with forms to report lost or stolen passports. So, instead of starting from scratch, we set about reusing this work with the goal of maturing and complementing it so that it can be applied more widely. The outcome of this work we called HOF.
What is HOF?
HOF is a collection of packages that were initially put together by a Home Office Digital team in Her Majesty's Passport Office and have since been developed to ensure they’re a good fit for a broader set of form goals.
The main packages within HOF are hmpo-form-wizard and hmpo-template-mixins. The wizard enables us to quickly build multi-stage form journeys, while the template mixins allow for the easy reuse of common form inputs, such as date pickers.
The hmpo-frontend-toolkit creates the chrome, which includes the styling assets that surrounds the form. This extends from the govuk_frontend_toolkit, which houses common frontend resources used across government applications. We also make available the i18n-future internationalisation tool, for page translations where applicable.
Refactoring to make reuse easiser
During the BRP development we generated some technical debt, which created extra complexity and made it difficult for someone new to the codebase to quickly grasp the principles on which we had developed BRP. Adding new forms was also tedious, due to long translation files and an organically grown application structure.
To address these issues we spent a two week sprint refactoring BRP to simplify the application layout and address the issue with lengthy translations files.
HOF-Transpiler
At the time of writing, for BRP we currently have 4 separate user journeys, each one with its own custom error messages and a large amount of localised copy. Originally, all the copy was held in within a single translations file, which had become cumbersome and unwieldy to update and understand.
As a result of the refactoring we created smaller, easier to understand translations files that are divided logically and local to the journey they serve.
The challenge that arises from having separate files for separate journeys, however, is the management of common resources. We decided from the very start that we would keep the architecture and codebase as DRY (Don’t Repeat Yourself) as is practical, so we put our common resources in a centralised location and built a tool that could not only merge the separate file content, but could also access the common resources.
The HOF-Transpiler is the tool we built to read the content from each of the separate files in the journeys and combine them into a single file to be used for translations. The HOF-Transpiler also enables the developer to put common resources into a shared location and include them in the build of each of the journeys’ translation files. This makes updating the applications translation content easier. The ultimate objective here was to make the editing of content straightforward enough so that someone without any development experience can do it, for example a content designer.
Application layout
Another outcome from our refactor was to split the journeys into logical sections. Previously we had a single point of entry for all controllers, views and fields, and much like the translations they were becoming more and more confusing as they continued to grow. Although some aspects were being reused, it was such a messy structure that it was difficult to understand what was being reused and where.
We decided the best approach would be to break the application down into sub applications, with each app representing a journey. This greatly simplified the application and ensured that new developers coming to the project would quickly understand the key parts.
To summarise, although application layout is not enforced, its adoption brings with it a number of benefits:
- Each sub-application is easily digestible and self-contained, making it easier for any developer to understand and make changes
- The breakdown of the translation content makes it more approachable to content designers with no development experience
- The addition of a common app brings with it a clear understanding of aspects that are being re-used
- It is now easier to add new journeys, and make changes to existing journeys
You can see how HOF is used in the wild by visiting the Biometric Residence Permits app on github.
What’s next?
We’re about to start a new project using HOF, which will give us the opportunity to develop the package even further. The team is also working on a simple example app that will walk new developers through the whole process and get up to speed quickly.
Let’s share
Do you have a different approach or thoughts on what we’re doing? We would love to get your thoughts, inputs and experience in the Comments section below or via twitter
Leave a comment