7 reasons I love the Summer in Hackney map

We launched the Summer in Hackney map this week. Here’s an ode to why it might already be my summer highlight.

1. It came from nowhere

I first heard of the Summer in Hackney project in its first weeknote. I was surprised and delighted: it’s not often we do something that I haven’t heard of beforehand. So it was liberating to read a weeknote and then see a Show & Tell. That’s why we ask the team to ‘fail in a fortnight’. 

2. There was more vision than definition

The project began with a vision for what we could achieve for users, rather than a clear definition of how we’d do this. We need to start more projects with a goal in mind rather than a thing we want to do. 

3. It was a team

The GIS team worked with user research, our designer and front-end developer to prototype and build a product. The team worked together, testing and re-using components (including our front-end patterns as well as things like the research pop-up banner). 

4. We did our user research

It would be easy to have done the Summer in Hackney map because we thought it was a good idea. We didn’t. The team did user research, together, to find out what users need.  

5. It blends tactical and strategic

The team described Summer in Hackney as a side-hustle, which sounds cool but is a bit unfair. It helped us learn about new ways of working and experiment with a different approach to delivering GIS data to users. 

6. The team delivered

We shouldn’t take for granted that a piece of work that began in July, delivered whilst it was still summer – and before the peak of summer. But we’ve also delivered a tangible improvement to residents. 

7. We’ve created components for re-use

The team did the work in a way that means we’ve learn about a pattern for how to provide maps and developed re-usable components for future maps – reinforcing how this project is a nice tactical intervention providing a strategic opportunity for change. 

From this:

Summer in Hackney - old

To this:

New summer in Hackney map

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. 

Love Summer map now live!

Breaking News! Now live at https://map.hackney.gov.uk/summer-map

Explore summer in Hackney with our map of playgrounds, pools, picnic areas, drinking fountains, walking routes and mhttps://blogs.hackney.gov.uk/hackit/wp-admin/media-new.phpore.
Explore summer in Hackney with our map of playgrounds, pools, picnic areas, drinking fountains, walking routes and more.

We’ve just finished a four week side-gig to get the best out of the fantastic resource that is Map.Hackney. While it’s a valuable tool for urban planning, it also holds hidden gems such as locations of drinking fountains, wildflower meadows, paddling pools and quietways. Which we want to shout about.

With an assembled team of a mapping expert, user researcher, developer, designer and deliverer, we kicked off our sandals and took the idea to the people. Our first stop was London Fields, where we interrupted unsuspecting bystanders to ask what they like to do in summer in the city.

Out of this research came four personas that we hoped would resonate with people. The one who likes to hang out with friends in the park and play ping-pong (‘Chilling’); the one who wants to keep the kids occupied for an hour (‘Playing’); the one who wants headspace while meandering through the streets (‘Wandering’); and the one who wants to create their own summer (‘Everything’).

With a wireframe best described as no-fi, the team was able to spin out a prototype faster than ice melts in a mojito. More research yielded great feedback: are the blue lines rivers? [cycle paths]; is that a bus route? [Hackney boundary]; can you see cafes in parks [heck, yes!]. All this was iterated back into the prototype. If you click on the slides, you can try it out for yourself via the QR code.

We all learnt something on this project. For some, it was the first experience of Agile working; for others, GIS was a whole new world; still more were introduced to GitHub. But the learning curve never felt too steep.

We’ve still got some end-to-end testing and colour contrasts to work out but we’re ready for our Monday launch. Let the summer begin!

When is an API Gateway not an API Gateway? – When it’s an API!

HackIT’s development team have some big ambitions with our API Hub and API Factory (our project which is refactoring of our Hackney APIs into a microservices architecture and delivering future APIs in the most effective and consistent way). The team has been steaming ahead with ideas to make our APIs so good people prefer to use them. But we know that this drive for innovation can’t be done without regular checks against industry standards and best practice. So with that in mind, members of the dev and security team sat with a team from Amazon as the first part of a “Well Architected Review” to sanity check what we were doing and ensure that our approach meets industry standards. Our HackIT manifesto states that we learn more “standing on the shoulders of giants” and Amazon are one of those giants we want to learn from.

We as Hackney team would like to thank AWS team for giving us valuable insights on the tech platform. We are really looking forward to the next session on 17th July.

Once everyone had settled in – with some of the Amazon team (comprised of Katie, Alice, Abir and Mani) very much looking forward to taking part in their first workshop from bean bags, Rashmi set about giving an overview of  why are we doing this, where we are currently and where we want to be.  

Well Architected Review

We then set about diving into the Well Architected Form which is built in to AWS’ cloud platform – albeit we had to switch our region to Ireland as it’s not available in the London region at the moment – but who doesn’t love Ireland? We began answering a series of questions over various areas such as what our priorities are, how we can understand the state of our application and how we can reduce defects. 

It became apparent as we were completing the form that at this point in the process it might be better to have a less structured discussion about what our questions and worries are. We were advised to complete the form at some point in the future but continued the meeting by talking more specifically about what we have in AWS and what we’re trying to achieve.

Amazon estate options

This led to “story time” starting with Alice (solutions architect at Amazon) telling us from her bean-bag that she felt like a teacher at story time. We broke out the white-board and Alice began explaining how many organisations set up their AWS estate (although she was worried as she’d been told that apparently drawing with red pens makes people angry subliminally).

Thankfully the red pen only seemed to engender rather a lot of excited faces amongst the dev team as we thought about the possibilities of building a more secure and easy to manage AWS setup.

We also discussed segregating our current landscape into master account, shared services (such as Active directory federation for example), workspace and multiple developer account model. The multiple developer account model would allow templated “scratchpad” areas for developers to effectively “mess around” and try things out. This would all use a product called Landing zone that would make managing this setup far simpler – providing advice on security, cost optimisation and performance.

Below is the sketch out of how the multiple account model along with Landing zone might look.

The above seems complicated – however this would potentially give us far greater security and a more resilient cloud setup. Specific accounts for specific workloads provides a modularised approach to the cloud infrastructure meaning components can be added and removed with less opportunity for error.  

Hackney specific question time

We then moved on to more specific discussions about our platform setup including our use of the API Gateway and how we would manage API Keys, as well as our strategy for migrating and synchronizing data in the cloud.

A lot of time was spent around the current setup within AWS (which consists of a single API Gateway and a single API inside it). Inside that single API all of the rest of our APIs are individual paths. A suggestion for the future was to split each API in to its own API Gateway. This discussion went to and fro for some time with much pointing at screens and hand gestures. Eventually we came to the realisation that we need 1 Gateway and multiple APIs (because this would make access management much easier) but we aren’t sure what that looks like until we’ve had enough time to think it through and design it accordingly.

We also discussed our current ecosystem with the team. One thing we specifically discussed was our current mechanism for logging. They recommended their tool ‘CloudTrail’ however they implied we should be more clear about what we expect from the logs. 

We also found out about a tool provided by AWS – ‘Config’. The tool tracks configuration changes and can be customized to include triggers which notify us when a change has occurred. For example, anytime someone changes our root user password, we could set a trigger to get a notification. We will look into the tool as we believe it could increase the security of our platform and applications. 

Another key take-away from this session related to a current concern we have around managing access to our APIs and that our current implementation would not scale very well.  After much discussion and consultation with our AWS colleagues we came across some really useful ideas that the team were itching to explore where we could really expand on the use of the API Gateway resource.

We discussed how we could we master our current housing dataset on cloud. We spoke about work previously done as a spike. We spoke about the Database Migration Service (DMS) approach we’d taken to extract the schema and data out from our legacy database and described how it had failed due to incompatibility of our legacy system with the tools on offer. The AWS team suggested we send them the details which they could review and provide further advice on it.

Our next steps

The meeting has left us with several areas for research, discussion and food for thought prior to our second conclusive meeting we have scheduled on the 17th of July. To conclude, we have identified several areas for further discussion and review:

  • Two new proposals for API access management that we have come up with and that will be reviewed by AWS team.
  • The feasibility of replacing our EC2 services (running Docker containers on hosted servers) with Fargate (running Docker containers in a serverless environment) and what would the benefits of that be in terms of performance and costs.
  • Possible data migration services provided by AWS to help us get our legacy data into the cloud.

Service assessments: treasure, dragons and a place to dry your socks

An unsuspecting vanguard 

The Hackney Spacebank team are looking at ways we can improve access to low cost or no cost meeting space in the borough for voluntary and community groups, micro businesses and residents. 

We’ve been squirrelling away for the last six months – give or take a couple of fire breaks – and we’re now ready to build our MVP. It feels like we’re at the bottom of a mountain, blinking into the sun, trying to get a glimpse of a hazy summit. We’ve got some navigation, our wits and a great team ethos. Like the best kind of adventures, there will be mysteries to unravel, treasure to be found and dragons to be tackled along the way. 

We’ve completed two service assessments on our journey thus far. These are like a bit Scottish Bothies – stone dwellings for individuals or small groups hiking in the mountains. A place of shelter to pause, unpack our bags, refuel and regroup. At Hackney, service assessments are an assurance, not a gateway. They are an opportunity to ask: are we doing the right thing, in the right way, at the right time? 

Our Spacebank team have been accidental pioneers of Hackney service assessments. We volunteered to do the first ever discovery phase service assessment back in March where we experimented with a self assessment approach and a couple of weeks ago we completed the first prototype (Alpha) assessment. 

A reluctant start

I didn’t feel popular when I broached the subject of prepping for a service assessment mid way through a series of five sprints. I understand why. The team were knee deep in the detail of prototyping a new service. I was asking them to step back and reflect. All the information we needed was in their heads and I had to find a way to extract it with minimal disruption. 

Over the next couple of sprints, I ran two 1-hour workshops. We took three or four service assessment standards and answered two questions: what’s the story we want to tell and how can we evidence this?* We looked at the good stuff and the not so good stuff, treating everything as valuable learning and identifying areas where the assessors could help us improve. 

For some of the team, completing a service assessment was new territory. I kicked the first workshop off with a short slide deck so that everyone knew enough** to join in. After we had bottomed out each service standard and assigned them to a team member, we agreed how to structure the assessment itself. We wanted the prototype to do the heavy lifting. We used a demo to walk through our proposed minimal viable product (MVP) and highlight some of our key messages. For example: our growing understanding of users’ needs, iterations as a result of testing, and tech choices.

On the day we were ready. There was a healthy dose of nerves, supplemented by caffeine and chocolate. After the demo, we broke into small groups each led by an assessor. This was the opportunity for an in-depth conversation on a smaller number of service standards. To wrap up we came back together and assessors fed back their thoughts and recommendations to the whole group. 

And at the end of it all, what did the team say: 

“The assessors were excellent and gave really useful, actionable feedback.” Emma, Developer

“I liked how we prepared by giving the assessors the information they needed for each service standard on Trello before the assessment. This allowed us to use the time with the assessors to get their feedback on things we could consider during the next phase of the project.” Sam, User Researcher

“I think the format in which we did an intro, a demo and breaking up into groups and playing back the highlights was a really good way of making the most of our time in our service assessment.” Joy, Service Designer

And our assessors said:

“Super interesting alpha assessment today at #HackIT. It’s always a privilege to meet talented committed teams doing the hard work to make things better for users.” Kate McCaul, Head of Digital at Acas

What are we learning?

Here’s what we are learning about participating in service assessments:

  • Preparation in bite sized chunks – little and often but involve the whole team
  • Take the lead (delivery managers/product owners) but share the responsibility
  • Give ownership of each standard to the relevant team member
  • Show “the thing” and practise showing “the thing”
  • Give assessors early sight of preparations
  • Structure the assessment to support conversations rather than questions and answers
  • Talk about the not so good – your best learning comes from this

Feel free to explore our Trello board and read our service assessment report. A big thank you to our assessors: Cate MacLaurin, Head of Delivery at Hackney, Kate McCaul, Head of Digital at Acas and Giulia Merlo, Service Design Lead at Cancer Research UK. Any tips on dragon handling are welcome. 

*The second question became redundant quite quickly as describing the story surfaced the evidence simultaneously

**What’s enough? A judgement call based on the personalities in the team and confidence levels. 

The hiking analogy of this blog post has been inspired by my long-time friend Shona MacPherson who lives in the Scottish Highlands. Today, she starts a solo hike of the Pacific Crest Trail, an epic 2650 mile walk from the U.S. border with Canada to the U.S. border with Mexico. She’s raising money for Mikeysline – a suicide prevention charity.