Introducing GOV.UK Frontend Alpha

An early prototype of the GOV.UK Frontend site

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 andconvert 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