We’re working on a new project at GDS to create a simpler, better way of building user interfaces for government services.
Earlier this year we ran a discovery project looking at the tools and resources people in government use when designing their services. One thing we learned was how hard it currently is for service teams to implement frontend code.
There are multiple apps to integrate, the code is hard to understand and there’s no clear way for teams to contribute back. Consequently there’s a lot of duplication of effort, out-of-date styles and inconsistency between different parts of GOV.UK.
A single GOV.UK frontend
To fix this we’re going to replace those multiple existing resources with a single one. We’re calling it GOV.UK Frontend.
We’ve built a small team who are currently working on an alpha version of the product.
The alpha will explore the best way to deliver a single package of frontend code that supports multiple development environments and templating languages.
After alpha, we’ll refactor and move the existing codebase into the new package, so that it’s more modular and easy to use. Once we’ve done that we’ll be in a position to extend the product with more components and examples, and to start accepting contributions from service teams.
That’s the plan. Here’s how we got to it.
What we learned in discovery
We spoke to more than 80 developers from 13 government organisations to find out what technologies they use, what problems they face and what improvements they’d like to see.
We also chatted to people in other organisations who’ve been doing similar work (thanks @alicebartlett).
This is what you said you wanted:
• a single package to integrate
• code that’s easy to understand
• more modular CSS
• a library of accessible UI components
• lots of examples to copy
• much better documentation
• clarity around releases and how to contribute
Frontend development in government
We also learned a lot about how frontend development works in service teams in government.
We learned that a wide range of technologies are used to deliver frontend across government services, with no one technology dominating. Of the people we spoke to, 90% were using either Node, Ruby, Scala, Python or Java (in that order of popularity).
A majority of developers were using a templating language from either the Mustache, Jinja or ERB families.
Nearly everyone uses Sass, but 40% of people weren’t following any specific CSS architecture. Of those that were, the great majority were using BEM.
About a third of teams had their own style guide or were developing one.
About 80% of teams were using the existing frontend resources from GDS.
About 14% of you said that those resources were never updated. The rest maintained those resources periodically through a combination of build tools, package managers and manual copying.
The summarised survey results are here
What we're doing for alpha
Knowing all of this has been really useful and has allowed us to make some early decisions for the alpha phase of the project.
None of these decisions are final. We’ll use the alpha to test our assumptions, and change direction if we need to.
This is what we’re going to try:
A single package
We’ve chosen a single package rather than individually versioned components in multiple packages. We want GOV.UK Frontend to be simple, compact and stable.
Node and Gulp
We’ve chosen Node because it’s Javascript, which most frontend developers already know, so there’s one less barrier to contribution.
NPM, RubyGems and PIP
We want to make it as easy as possible to integrate and maintain GOV.UK Frontend in your projects, so we’ll make it available using these package managers.
Support for Nunjucks, Handlebars, ERB and Django
We’ve chosen languages that support conditional logic and parameters with defaults. We'll use Nunjucks as the default and convert automatically from it to the other languages.
An ITCSS-like architecture and BEM-style, namespaced class names
We’re going to follow ITCSS and BEM because they’re widely known and well suited to the development of very large websites with distributed teams.
Thanks
Thanks again to everyone who helped during discovery. We’ve got a huge amount of useful feedback, way more than I’ve described here, and we’ll be drawing on it throughout the alpha.
Massive thanks also to Gemma, David and Robin for all their hard work so far.
Next steps
We'd like to share our work more widely towards the end of November, so we'll be planning some show-and-tells in Leeds and London around then.
--
Tim Paul is head of interaction design at GDS
9 comments
Comment by Jude Robinson posted on
Hi Tim - I read this with great interest, having faced similar challenges, needing to develop and support a plethora of backend applications with shared branding/UI.
We took inspiration from this LinkedIn post (2011!) https://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates and ended up writing "Shunter", in order to decouple the frontend: https://github.com/springernature/shunter
Apart from meeting the primary goals of being able to better support multiple applications and reuse UI assets and easily maintain stuff across time (etc etc), I thought it might be worth me detailing a few extra benefits we found:
1. Decoupling brought an added point of collaboration between backend and frontend teams, in that we defined a JSON structure together, which ...
a. … forced us to quickly focus on the information contained in the page, which …
b. … tied in really nicely with progressive enhancement, and …
c. … often illustrated improvements that could be made to the design, before we even got to writing HTML/CSS/JavaScript.
2. It also allowed frontend and backend to produce work at their own pace, without having to wait for each other. Frontend could build pages based on mock JSON, and backend could work on producing JSON to that specification, without either being restricted by the pace of the other. This proved as helpful working alongside people as it was when working with people/teams in different locations.
3. It made moving frontend developers between teams much less traumatic.
4. It made recruitment and staff-retention much easier - it's such a big improvement over previous ways of working!
Comment by Tim Paul posted on
Thanks for this Jude - we'll check out Shunter. Glad to hear you've had success with a similar approach.
Comment by Dualta posted on
I work at a digital agency and we currently use a lot of the frontend resources you have for any GDS projects we do, it would be great to hear this from the guys who put it together.
Is this open to all or only Gov employees? I know myself and some of my colleagues would be very interested.
Can't wait to see some updates 🙂
Comment by Tim Paul posted on
Hi Dualta. It'll be available to anyone who's building UK Government services, including agencies. We're also planning to make it easy to remove the GOV.UK identity, so it could be used in other projects as well.
Comment by Dualta posted on
Thanks Tim, I now realise I wasn't very clear in my comment. I meant to ask would I be able to attend a show and tell in London in November?
Will be following your progress on GitHub 😉
Comment by Tim Paul posted on
Aah, understood. The November show-and-tells will be Gov-only I'm afraid, but I'm sure we'll be doing something more public in the new year.
Comment by James King posted on
This is great news. I've just started working on a new GDS project and have found it difficult to navigate the projects and documentation out there. Looking forward to seeing the ALPHA
Comment by James King posted on
Hi, is this project still going ahead?
Comment by Tim Paul posted on
Hi James, yes it is (although we've been pretty quiet about it).
You can access the project code on GitHub: https://github.com/alphagov/govuk-frontend