An update on the Hackney pattern library

Today was an exciting day for front end at Hackney. We finished adding all of the current GOV.UK design system components (along with their Hackney branding) to our pattern library AND we were fortunate enough to have a great meeting with two GDS developers Nick Colley and Hanna Laakso who were kind enough to come to Hackney Service Centre and talk to us about many of the factors involved in maintaining a UI library.

A Work-In-Progress version of our pattern library can be seen here: It contains a lot of Hackney branded GOV.UK components (many of these have very small branding changes – tweaks to colours and spacing) and a couple of new Hackney components, such as the Contact Block and the announcements components. I have some tidying up to do and spacing to update. I also have documentation to write.

Beyond that my immediate priority is to work with one of our designers to develop a flexible and fit for purpose version of our header and footer for the library – a lot of our components so far have come out of our new design for the main Hackney website, but the site’s header and footer are quite bespoke and will need to be genericised / iterated so that our pattern library components can produce any combination of elements that we might require. These include things such as whether or not we have header navigation and how extensive that is, whether or not we have login and/or search in the header… Once we have the header and footer in place I’m excited about starting to use the pattern library in the wild and letting people’s experiences of it drive the work we do going forward.

Our meeting this afternoon with Nick and Hanna was a real reminder of how important it is to be thoughtful in the work we are doing. We discussed issues that we at Hackney have barely thought about, being in such an early stage of our journey, such as Semantic versioning and the responsibility around breaking changes / deprecation as well as an enlightening discussion around the importance and effectiveness of communicating those changes well. We also spent a while discussing accessibility and in particular accessibility testing tools (I point you in the direction of this blog post from GDS about Assistive technology tools you can test with at no cost). 

I was glad to be able to ask the experts about one of the issues I came up against while building our pattern library: including external libraries. Our new Contact Block Component requires the Leaflet.js library which adds a reasonably hefty chunk javascript and css to our compiled code. There is a big question here around whether the benefits of including Leaflet in the pattern library should be achieved at the expense of reducing page load times and increasing data usage on pages which don’t use that component. There’s not a simple answer here, but it was really great to discuss the pros and cons with Nick and Hanna and hear my own concerns validated. It provided plenty of food for thought and I have already made a change that will improve performance in the short term while I continue to investigate other possibilities.

It was also really great to discover that Nick and Hanna both started off as apprentices, since three of our digital apprentices Andrew, Liam and Miles were participating in the meeting. I asked them how the meeting went from their perspective and will leave you with their responses:

“Great meeting which helped my understanding on how to make applications more accessible to users while also giving me a clearer view on important skills such as communication is to the IT Industry”

“I found the meeting very valuable as it gave us the opportunity as apprentices to meet experienced developers from GDS who were more than happy to share their knowledge and expertise in web/frontend development. We discussed the technicalities behind developing the Hackney Frontend library and using the GDS Frontend as a dependency, the importance of web accessibility (especially in the public sector), the importance of working in the open and sharing your work with other organisations.

“We also briefly discussed our backgrounds and how we got into web development/front-end development, which was very interesting and inspiring to be able to get insights into how people got into to the work they do.”

“It was cool to know that both developers were also apprentices in the past”

Building a frontend pattern library

At Hackney we’re currently in the process of rolling out a new design for our website. This has involved designing a UI Library of components that can be shared across other projects. Now we want to take those components and build them into a frontend pattern library so that code can also be shared across projects. We want this to take the form of an npm package that could be included in all projects so that styles, scripts and potentially templates could all just be imported individually from that package when required.

The starting point for our UI Library has been the GOV.UK Design System and many of our new Hackney components build on existing GOV.UK components with Hackney branding applied, often through changes to colour, font and/or spacing. Because of this I am keen to utilise the GOV.UK Frontend components in our frontend pattern library to avoid unnecessary work, duplication of code and to make use of all of the research and development that has already gone into GOV.UK Frontend. But if we are going to do that it also makes sense to use the GOV.UK Frontend wider setup (the Node.js app, Nunjucks templates, etc) as a basis for our Hackney Frontend; again this minimises duplication of code and effort and ensures maximum compatibility.

So the plan is to create an LBH Frontend repository that is very similar to the GOV.UK Frontend repository but also consumes the GOV.UK Frontend package so that its components can be used and built upon. The LBH components will all be prefixed “lbh” and these will be what are used by developers working on Hackney projects. Some components will be completely original and unique to Hackney, others will build on the GOV.UK components but with changes to markup (in which case we would rewrite the markup but utilise some GOV.UK classes) or styling. In cases where the Hackney component is very similar to the GOV.UK component, a component template could be as simple as including the GOV.UK component using Nunjucks and including an override class. There is a question about whether or not this last scenario provides value since that is something we could do without a LBH Frontend, but I think that establishing a set of LBH Frontend standard components that don’t require any modification feels like it is worth doing.

As Hackney is also doing a number of React projects it will also make sense to make a React version of the pattern library, similar to the GOV.UK React repository.

As both of these projects will be utilising GOV.UK Frontend we will need to have a plan for updating GOV.UK Frontend. Updates could include important accessibility changes, desirable new components, or crucial fixes so will be important to include. I think largely the plan will involve making sure that we are aware of GOV.UK Frontend changes and understand what has changed so that we can anticipate how this will impact LBH Frontend and build it into resourcing plans. I also think a Visual Regression tool such as BackstopJS would be useful in this instance so that we can automatically see any unexpected visual changes caused by updating GOV.UK Frontend.

Do you have any thoughts about this plan? I’d love to hear what you think.