Breaking the tech language code

Here at HackIT we’ve had quite a lot of new starters recently as we’ve continued to expand our capability to undertake in-house delivery of digital services.

Some of those folks come with a strong background in the kinds of technology we use. For example, our developers are all up-to-date with all the latest techniques to do with APIs, AWS, Git and SaaS services.

However, some people come from a background where the above would just be a list of meaningless acronyms. For example, some of our excellent new Delivery Managers have been a little overwhelmed of the barrage of new tech-related phrases they have been barraged with as soon as they arrived.

In order to help new HackIT members prioritise which tech things to learn about first, we did the best thing to do in such circumstances – we asked everyone! We put this spreadsheet together to start collecting technical terms people either thought were important or that they were encountering for the first time. We then ask everyone to self-assign themselves as either technical or non-technical and then rate each of the terms as “critical” (things to understand in the first 1-2 weeks), “important” ( things to understand in the first 4 weeks), “useful” (things to understand in the first couple of months) or “not useful” (nice-to-have’s). When we then totalled up the votes this is when we found.

The top 15 terms prioritised by tech-folks.

  • Front end developer
  • Back end developer
  • UX designer
  • QA engineer
  • Front-end code
  • Back-end code
  • GDS
  • Git
  • Dev / test servers
  • Production
  • Cloud
  • UI designer
  • Github
  • Branch

The top 15 terms prioritised by non-tech-folks.

  • GDS
  • API
  • Local Gov Digital
  • Cloud
  • Server
  • AWS
  • Documentation
  • Front-end code
  • Back-end code
  • Digital Marketplace
  • SaaS
  • Github
  • MHCLG Local Digital
  • Time and materials
  • Dev / test servers

There are many more terms in the spreadsheet.

We’re not going to be providing definitions for these terms at this point. Partly because sometimes they differ between people and we don’t want to start any internal flame-wars! Really though, what we want to do is encourage lots of conversations where new starters discuss some of the topics they’re not sure about with their colleagues and hopefully pick up a lot of other concepts along the way.

We’re going to be updating this list on a regular basis and using it as part of our onboarding process for new starters so especially keen people can have a chance to start getting up to speed on things that may be brand new to them before they even start here at HackIT!

Autumn 2019 HackIT update

I’m starting with a confession… It’s eleven months since I did my last ‘quarterly’ HackIT update. 🙁

But I’m committing to getting this back on track and my latest update on the work we’re delivering across our team is now available to read here:

There’s lots going on and it’s always hard to include everything that different people across the team are working on. Some headlines from recent months include:

  • A small squad of HackIT digital ninjas have successfully delivered the Council’s new website, running on WordPress. This will provide simpler, more user friendly access, at dramatically reduced cost, with design that builds on the work of the Government Digital Service. The new website platform also makes it easy to connect the Council’s online content to mobile apps, Alexa skills, voice-activation technology, chatbots or any other digital product that our residents and businesses prefer to use in future.
  • Our work with colleagues in Housing Needs to respond to the Homelessness Reduction Act has opened up exciting opportunities to go even further in designing services that provide excellent support for vulnerable residents.
  • Work to refresh the Council’s computing equipment is close to completion, providing all of our users with faster, easier to use and more resilient devices. This has included the introduction of a new ‘Grab n Go’ service, making it easy for any officer to access a portable device when they need one. This new service has already been used by c 1,000 users on over 4,400 occasions, with 94% positive satisfaction.
  • Hackney won the Information & Records Management Society Innovation of the Year award for the Council’s work on a digital service for Freedom of Information requests and Subject Access Requests.
  • Our Data & Insight team have been doing great work which includes using data to help develop the Council’s poverty reduction strategy, support our property and asset management work, and provide easier to access insight for managers across the organisation.
  • Hackney’s ‘cloud first’ model for access and security has been highlighted as an example of good practice by the Government Digital Service PSN team:
  • The HackIT digital apprenticeship programme has continued to develop well and further opportunities for apprenticeships (including part-time apprenticeships and work placements) are being explored.
  • And through our work as a founder member of the London Office of Technology & Innovation (LOTI) we are working with other innovative councils across London to dramatically extend digital apprenticeships, provide seamless wifi across our offices, explore the potential for assistive technologies to help people live independently – and much more!
The organising themes for our work in HackIT

As well as delivering new work, it’s also essential to make sure that we are supporting our users well so that they can focus on delivering services for our residents. I’m very pleased to see that our users are continuing to report high levels of satisfaction and this was my favourite piece of user feedback:

I have made several calls over the last few months and have found the entire team to embody the Hackney values and I don’t say that lightly. I wish other teams could respond with similar verve and the obvious directive to resolve even the simplest of issues without making the caller feel small.

There’s much more that we need to do, and the update includes details of some of the challenges that we need to address. I’ll try to make sure that I report back in a more timely fashion next quarter to share details of how we are progressing.

Rob Miller, Director ICT

Want to find out more about the work we’re doing in HackIT and ways to get involved?

  • Details of the projects that we’re delivering are published on Pipeline
  • Opportunities to sell services to support our projects are published on the Digital Marketplace
  • Career opportunities in our team are published on
  • And you can follow our project weeknotes on our blog and Twitter

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”

Using local data to build a better picture of poverty in Hackney

In Hackney, our ambition is to be evidence-led in everything we do – this includes ensuring that our strategies, services plans and key decisions are informed by what we know about the borough and the people who live and work here.  The Strategy team are currently developing two key strategies around poverty reduction and fostering an inclusive economy and HackIT have joined forces with them to help build a picture of poverty in Hackney today.

The go-to data source on poverty for small areas is the Index of Multiple Deprivation (IMD) which combines 37 different indicators across 7 ‘domains’ of deprivation (income, employment, education, health, crime, barriers to housing and services, and living environment). Whilst this data offers valuable insight, it has limitations and doesn’t always tell the full story:

The first key limitation highlighted above is that the IMD is good for understanding how deprived an area is in relation to others, but not how deprived an area is in absolute terms. This means that if nothing changed in Hackney but other areas got worse, Hackney would appear less deprived even though the experiences of our residents had not improved. 

This relates to the second key limitation of the IMD: its relative nature does not enable us to see change over time, and this data is only published every 4-5 years. On top of that, the underlying data behind the index is generally 2-3 years old by the time it is released. We know that Hackney is changing quickly, so we need to make sure we have up-to-date information. We also need to be able to see whether poverty is increasing or decreasing to better understand whether our approach is working.

Over the past 6 weeks we’ve worked on a short data project to build a  prototype of a Hackney Poverty Index in an attempt to fill this gap. We wanted to learn from the concept and methodology of the IMD to build our own index that combine open data alongside data we hold within the Council.

We aimed to identify at least one good indicator from each of the 7 IMD ‘domains’ to include in our prototype. We compiled a list of possible indicators and evaluated these in terms of:

  • data quality – can we trust this data?
  • granularity – is it available for small areas below borough level?
  • frequency – is it up-to-date and refreshed regularly?
  • coverage – is the data missing key sections of our population?
  • access – is it easily accessible from our systems, or openly available?

We were able to go above and beyond the 7 indicators we set out to include in our prototype, and in the end included 13 different datasets. These ranged from an indicator which identified the proportion of households who were in debt to the council, emergency admissions to hospital, and air quality. We did, however, face challenges identifying good datasets for some areas (education in particular) and had to be pragmatic with our choices. 

We brought together these datasets in Qlik, our business intelligence tool to transform, analyse and visualise data. The Hackney Poverty Index dashboard is now available for officers across the council to test out and give feedback on.

Our prototype is already generating insights that we didn’t have before. The maps below show that our local data is able to provide a much more granular picture than is available in the IMD (this data can be mapped at Output Area level). Our local data also shows a different pattern of income deprivation than the IMD 2015, with more poverty in the north of the borough. It is difficult to say whether this is due to changes over time (the underlying IMD data is likely to be from 2012-13) or for methodological reasons. We’ll be exploring this more when a new release of IMD data is available in October.

This prototype is just the beginning of a Hackney Poverty Index. We know that there is a lot more work to do! We expect to start the next phase of this project in late September when we’ll be:

  • further refining the themes and indicators we use to measure poverty
  • bringing together these indicators into an index which provides a single measure of poverty in Hackney
  • researching what functionality users need to understand and analyse the data
  • making the next iteration of the Index available to the public
  • providing more analysis alongside the data to tell a story

How can we make open data work for our users?

For a long time, there’s been an established view that publishing more open data should encourage the proliferation of new applications and services across the public and private sector based on the availability of common datasets across local authority boundaries. 

Historically in Hackney, we’ve only ever dipped our toes in the world of open data and to be honest, we don’t know whether there’s enough evidence to prove that simply publishing as much as possible will realise these benefits – we just don’t know enough about the user need to justify a big bang open data offering.

That being said, we’ve been inspired by the ODI, Nesta and others who are keen to encourage greater transparency and common standards in data publication and we have reviewed some of the good practice of other local authorities who’ve experimented with open data portals in recent years. But our HackIT manifesto tells us to think big and act small – we don’t want to dive into the deep end of an expensive open data portal for publishing every non-personal data set we can find. Instead, we want to understand the kind of data users want to see, and work out the most simple and cost effective way of providing that data in a useful way.

Currently, we don’t proactively publish the data that is most commonly requested via Freedom of Information (FOI) requests, which results in a significant burden of resource spent re-actively responding to FOI requests. In his 2018 manifesto, the Mayor Glanville committed us to more transparency and this has helped shape a set of basic principles to help us experiment with user focused open data publication. We’re keen to open ourselves up to some challenge on this and share what we learn as we experiment:

  • Focus on releasing data commonly requested via FOI – We believe that concentrating our open data offering on the most frequently requested topics will release significant amounts of officer time and provide a better service for residents. Therefore, we will focus on these opportunity areas first.
  • Use common standards wherever possible – to be valuable for developers and organisations, we need to publish our data in a format that is easy to join across local authority areas. Where a standard doesn’t exist, we will try to match other Councils who are already publishing this data to maximise reusability. We will openly publicise our data structures to encourage reuse by other local authorities.
  • Automated with a focus on currency of data – to be of maximum value in reducing the FOI burden we face, the data included in our open data products should be as current as possible. To ensure we aren’t just moving the resource problem from FOI administration to open data publication, data updates should be automated and require a minimum amount of officer time to publish.
  • Adopt a flexible approach to the technology we use to publish our data – we don’t believe in being constrained by an online data portal for publishing open data. We will aim to use the best modern technology and data analytics techniques depending on the data involved to provide a data dashboard, visualisation and full download of the dataset. We are motivated by providing a great user experience that’s easily discoverable first and foremost.
  • Aim to meet GDS design standards – all of our products will be designed in line with modern, accessible design standards and we will always test our products with our users.
  • Understand our impact – we will always begin by understanding the baseline volume of FOI requests for the data set in question and monitor over time, the impact of publishing the dataset. We expect to see more exemptions (where an FOI is refused under the grounds that the data is already published) and over time, fewer FOI requests overall. If the data set isn’t reducing FOI demand, we will look for other areas where we can add more value by publishing new data.

Our first experiment is with Penalty Charge Notice (PCN) data (that’s parking tickets to you and me…) – it’s one of the most commonly requested datasets and we think publishing this openly will help residents answer their questions in a more timely way and reduce the time we spend responding to FOIs on the topic. We’re experimenting with providing a simple  app on the parking pages on our website, which will allow users to extract the type of information from the data that is often asked for in FOI requests. Our great User Research team are helping to keep us focused on delivering something simple and intuitive for residents. We’ll also be trialing a light touch open data portal which will allow us to curate our open data sets in one place on the website. We’ll share more as we develop our MVP over the coming weeks.