Against conventional wisdom, we’ve just published the staff manual for FixMyStreet Pro online, where it’s easy for anyone to access.
When we were putting this manual together, we thought we’d have a quick google round for other council SAAS documentation, to see if anyone was doing it particularly well.
We didn’t get very far, though — it seems there’s a culture of corporate secrecy amongst other suppliers, and a fear of publishing such materials in case of imitation.
Why so open?
We’ve gone our own way on this one for a few reasons.
First, because it helps our clients. We know that it’s far easier for customers to look online for materials than it is to remember where they’ve put a physical handbook.
We know we could have put it behind a password, but that just adds an impediment for our existing customers, as well as for anyone hoping to understand the service a little better before making a purchasing decision. Plus, who remembers passwords for something they might only be accessing a couple of times a year? It’s just extra faff.
This way, staff only need bookmark the documentation page, and they’ll always be able to find the most up to date version of the manual.
There’s another reason as well, though. Most mySociety codebases — including FixMyStreet — are Open Source, meaning that anyone who wants to can inspect or use the code for their own purposes. If anyone really wanted to know our ‘secrets’… well, they’re already out in the public domain.
We reckon there’s more to gain by publishing our instruction manual than there is to lose. Sure, competitors might see what features we offer, and they might even copy them. We’re confident, though, that our customer service, company culture, and our insistence on making our products as user friendly as possible, all give us an advantage that imitators are unlikely to be able to match.
So, if you’re from a council yourself (or if you’re just curious) please do go ahead and read the manual. We hope you’ll find it of interest, and that it might cast some light on what makes FixMyStreet Pro different from other offerings in the field.
We often talk about how FixMyStreet Pro can integrate directly with council’s existing systems, and how doing so can help councils be more efficient — but what exactly does that mean in practice?
Let’s take a look at our two most recent FixMyStreet Pro installations. Both B&NES and Buckinghamshire councils use the same asset management system, Confirm, and it gives us a great example of how FixMyStreet Pro’s ability to ‘communicate’ with such systems will make everything a whole lot easier for residents and for council staff, even with two very different types of local authority.
Saving time and effort
FixMyStreet has always provided the resident with an easy interface through which to file a street report. For many councils, however, such reports arrive in an email inbox and then have to be forwarded to the right location or typed into the council’s CRM, all adding to the sum total of time and effort dedicated to each report.
Now, using the Confirm API, Bucks and B&NES councils can access and work on FixMyStreet reports through Confirm’s standard ‘inspector module’, removing any need for this extra step.
Optionally, the information flow can go both ways, and indeed this is the case for both B&NES and Buckinghamshire councils. What this means is that for example, when an issue has been inspected and council staff change its status (perhaps from ‘report received’ to ‘repair underway’), this status change will be passed back to FixMyStreet, automatically syncing with the site, and notifying the report-maker with the update — again removing another mundane task from customer services staff.
If a highways inspector should come across a new issue while they are out and about on their rounds, they can raise an issue in Confirm just as they always would have. But now, that will also create a report on FixMyStreet which residents can view, keeping everyone up to date and ensuring that reports aren’t made about issues that the council already know about.
FixMyStreet Pro also allows for council administrators to create template responses — an invaluable timesaver when responding to one of the more common situations such as “issue identified and prioritised” or “issue now fixed and closed”. While Confirm also has its own template responses, FixMyStreet Pro offers more flexibility, as the same template can be reused across multiple report categories and status types. Buckinghamshire really saw the benefit of this: they were able to reduce the number of templates in use from around 450 to 46.
Assets such as streetlights, grit bins and gullies can be pulled through from Confirm and overlaid on the map. This makes it significantly easier for both residents and staff to locate and report issue, speeding up the issue resolution time — we’ll be delving more deeply into this in our next blog post, with a few more technical details for those who are interested.
Residents in these areas can make reports on the councils’ own websites, where they’ll find FixMyStreet as the street fault interface — or through the main FixMyStreet website and app. Whichever you choose, your reports will be published in all three places.
So far, so convenient for residents — but behind the scenes, there’s lots more going on that improves the efficiency of the whole fault-fixing cycle.
Both councils are users of the Confirm CRM system, with which FixMyStreet Pro can now be fully integrated. What that means in practice is that when you make a report, it drops directly into the council’s existing workflows, with no need for someone in the middle to retype or redirect your report.
Council staff can use the best of both systems’ useful tools for shortlisting, inspecting and updating the status of your issues — and when a report has been progressed to the next stage of the fixing cycle, you’ll be automatically kept up to date both by email, and with messages posted directly to your report page.
In another advance, both councils are now displaying assets such as bins, trees and adopted highways in context-sensitive areas of the report-making journey, so it’s easy to identify exactly which one you’re talking about when you make your report. That saves time for you, and for the council when they go out to fix it .
If you’re interested in the technical details, we’ll have more about both Confirm integration and asset layers in future blog posts.
This is part II in a series of blog posts about our work with Hackney Council to conduct a discovery and prototyping project to improve the public-facing parts of information request processes. Read the first part here.
With our experience of running WhatDoTheyKnow and Alaveteli, we’re big believers in the importance of information transparency laws in our democratic system. But at the same time, we understand the operational challenges of meeting the statutory requirements of these laws for public bodies.
The challenges of dealing with information requests
While many local authorities have dedicated information governance staff whose job it is to manage requests, finding and compiling the information is often done by hard-pressed staff within services, fitting in information-related work around their core responsibilities.
Requesters sometimes have the expectation that information is all carefully organised in a few databases, ready to be aggregated and extracted at the click of a button. In reality, the degree to which information is well-organised varies a lot between services in a council and between different councils, often because of procurement decisions and departmental priorities stretching back many years.
Working with Hackney Council
We’re part way through our project with Hackney Council that Mark wrote about a few weeks ago, helping them redesign the public-facing parts of their FOI and Subject Access Request (SAR) services, so we’ve seen these challenges up close. We’ve also seen how they can be made even trickier by legacy IT systems that are no longer fit for purpose.
— Rob Miller (@RobMiller31) February 28, 2018
At our ‘show and tell’ last week with Hackney, we shared findings from some of the research we’ve done, along with early prototypes of potential new FOI and SAR submission forms, both created collaboratively with Hackney Council staff.
Prototyping with the GDS toolkit
We decided to go straight from sketches to HTML-based prototypes for this project. We thought that moving in-browser with real interactive elements would make it easier to test out some of the more complicated interactions and conditional workflow of the SAR process in particular.
Prototyping is about quickly testing hypotheses, and not getting bogged down in implementation details. So it was a pleasure to use the GDS frontend toolkit to build our prototypes. Not only did the GOV.UK toolkit help us build something relatively rich in just a few days, but it also meant we benefited from GDS’s previous work on design patterns developed for exactly this kind of context.
Using public information to reduce FOI requests
When submitting a request via WhatDoTheyKnow, users are automatically shown previously submitted requests that might answer their question, and we know that almost 10% of requesters have a look at these suggestions in more detail.
As you can see here, we took this pattern from WhatDoTheyKnow, and enhanced it further in our FOI prototype.
Now, as well as prompting with previous FOI responses from a disclosure log that we’re hoping to build, we also want to include relevant links to other topical or frequently requested information, drawn from other data sources within the council.
If we can get this to work well, we think it could have a number of benefits:
- Helping the person submitting the FOI get their answer more quickly
- Reducing the number of requests that would otherwise have been sent to the council
- Encouraging more proactive, structured publishing of data by the council.
It’s this last point which we’re really interested in, longer term. We think using a common sense technology approach to highlight possible answers to FOI requests before they are made will get people answers more quickly, reduce the burden on responders, and reinforce efforts to proactively release commonly requested data leading to real transparency benefits.
We’ve been doing usability testing of these prototypes over the last few days, and will be looking very closely at whether our assumptions here stand up to scrutiny.
Reducing back and forth around SARs
Given our background, we’re inevitably very interested in the FOI component of this project, but the Subject Access Request component is no less important. And while there’s none of the same opportunity for pre-emptively answering people’s requests, there’s plenty of scope for making the submission process a lot smoother.
A valid FOI is just a written request and some contact details, but the information needed for a SAR to be valid is much greater and more complicated. For example, along with the specifics of the request, a solicitor asking for personal information on behalf of a parent and their 16-year old child would have to provide proof of ID and address for both family members, a letter of consent from the child, and a letter of authority from the parent, confirming that the solicitor is acting for them. Even the most straightforward SAR calls for the handling of personal data and confirmation of the requestor’s identity and address.
Given all this complexity, it’s easy for there to be a lot of back and forth at the start of a SAR: clarifying a request, asking for documents, arranging receipt of documents, and so on.
We’re hoping to build something that makes it much clearer to the person making the request what they’ll need to do, thereby taking some of that responsibility off the shoulders of the team managing the requests.
The sketch above was our first crack at something that could handle (most of) this complexity, and we’ve made a number of changes since then as our understanding of it all has increased.
Recruiting representative users to test SAR submission has proved challenging and wasn’t helped by the Beast from the East rearing its snow-covered head. But we changed tack and successfully ran some guerilla testing in Hackney’s service centre last week, and we’re hoping to do further testing later in the project that has more chance of benefiting from contacts cultivated by individual services.
Changing the conversation
The conversation around information requests often focuses on the burden of responding. And although the number of information requests local authorities receive is unlikely to decrease any time soon, we’re hoping that through our collaboration with Hackney, we can make handling them a whole lot easier.
If we do it well, we think we could eliminate a lot of the process issues created by poorly-designed legacy systems, while baking in a fundamentally more open and transparent way of operating that has the potential to benefit both citizen and state alike.
If you’re responsible for managing FOI requests or data protection in your own public sector body and you’d like to follow this project in more detail—or if you’d like to participate in some of the discovery work—then please get in touch at email@example.com.
Image: Sarah Palmer-Edwards
We created FixMyStreet Pro to help councils and city governments better manage inbound street reports and issues from their residents.
In the past few months we’ve rolled out the FixMyStreet Pro service to new customers including Bath & North East Somerset, Buckinghamshire and Rutland councils; each of whom are taking the opportunity to get rid of legacy software, simplify their operations and make use of a much simpler and intuitive way for their residents and staff to make and manage reports.
We’re now looking for input from councils to help us guide the next phase of our service development on FixMyStreet Pro.
Having spoken to dozens of councils we think we can help them save more money by extending FixMyStreet Pro to other areas like waste and environment services and we would like to explore how much development work that might entail.
Not just for streets
As FixMyStreet’s name would suggest our focus so far has been on handling issues related to highways like potholes, lighting and gullies (drains to me and you), but FixMyStreet Pro already handles reports for a whole range of issues beyond streets.
Typically council users of FixMyStreet Pro have around 13 to 15 different self-selected categories that they accept reports on – each of which can be directed to different teams or departments. Tree reports can be sent directly to the parks department, graffiti or abandoned cars can be passed along to the just the right team in street cleansing.
These ‘front end reports’ all have one thing in common: all we need to make the report is a location and description, plus a contact for the reporter, which could be as simple as an email address or phone number.
But once you get deeper into the glamorous world of bins and waste services for individual residents the situation gets a little more complicated.
Missed bin collections, requests for recycling bags, bulky waste collection – these all require the resident to be identified, the particular property to be checked with the UPRN (Unique Property Reference Number), and in some cases payments levied and collected.
FixMyStreet Pro doesn’t currently offer these additional waste services, although it doesn’t require a huge leap of imagination to see how we could add these adjacent features to the service, not least because we already do a lot of the pieces across our other commercial services.
Fortunately there has already been a lot of work done to define common standards, such as the Local Waste Service Standards Project from 2016 and more recent work by individual councils to apply some of this work – we also have a lot of our own research and experience to draw upon with numerous specific feature requests from our current local authority clients.
To make this happen we’d like to recruit at least two or three friendly councils available for interviews and possibly a workshop or two, to help us determine specific requirements and test out some of our early prototypes and hypotheses. From here we’d aim to develop these features into fully working aspects of FixMyStreet Pro over the summer.
If this is of interest to you, if you’re already grappling with this in your own council, or you’d just like to find out more, please get in touch with firstname.lastname@example.org and we can have a chat.
In the meantime you can always find out more about what FixMyStreet Pro can do on one of our regular Friday Webinars.
Work for a council? Tell us what you need
We’re making some pretty big improvements to the FixMyStreet for Councils service at the moment: improvements that will save councils both time and money, while giving them flexibility and insights into their fault report handling.
This has been our core focus over the last six months, working with our customers to design a new category of case management system, for local government, and by local government.
We’ve been working together with local authority insiders because they’re the people who know best what they require from a piece of software they will use every day. If you also fall into that category, we’d love to hear from you.
We’ll be sharing early iterations of the improved service as we make progress. Your feedback will be part of that process, helping shape a service that does everything you need it to do.
As we add these new case management features, we’ve set three core principles:
- To lower the operating cost of highways, parks and streets management by improving the user experience for all involved, from residents to council staff
- To change the relationship between local government and providers like Skanska, Veolia et al from direct management and instruction, to one of monitoring and oversight
- To treat the asset management system as a data repository for asset information, not a case, customer or works management solution
If you are from a local council and you would like to find out more, or you would like to provide feedback on early prototypes, help with user testing and become a part of our development process, we would love to hear from you.
Those who want to find out more about obtaining FixMyStreet for Councils can do so by checking out our page on the Digital Marketplace.
Earlier this week we hosted our Open Standards in Local Government workshop at Newspeak House in London, with the aim of unpicking where open standards might be of benefit and what might be stopping us from making more progress.
We were joined by 20 smart people representing a bunch of local councils across the UK and it’s fair to say we made a good bit of progress. A number of consistent themes arose through our discussions.
It was widely agreed that Open Standards are key to getting the basics right, and standardising the ability of different services to speak to one another is a prerequisite for a sustainable local authority service strategy. The insistence on compliance with open standards at the procurement stage should place an imperative on suppliers to build-in interoperability and reduce the fear of vendor lock in – councils shouldn’t inadvertently replace one set of closed systems for another.
This link between adoption of open standards and the procurement process was fundamental.
In our opinion demanding compliance from suppliers to agreed open standards up front, is probably the single most important thing that central government could do to help local government.
Phil Rumens from LocalGovDigital introduced recent progress on the development of the Local Government Digital Standard. Notably, it goes further than the equivalent in central government, with an emphasis on reuse of existing data and services, and commitment to make more data open and reuseable.
Both the LGA through LG Inform, and GDS via standards.data.gov.uk already look to gather standards for use in central and local government; however adoption by local government often lags substantially behind. Simply put this is a conversation that doesn’t really happen outside a small number of web or digital staff within councils, and the wider group of service staff don’t yet understand the opportunity that open standards represent.
Indeed, Tom Symons from Nesta who introduced the Connected Council’s report, highlighted that the councils furthest ahead are those that have both put in the hours to achieve proper internal Governance standards, and have benefitted from leadership by the Chief Exec and Senior management team.
The biggest need we identified was to showcase great examples of how open standards can lead to better outcomes in practice.
Showing what’s possible, both with case studies and live services that can be adopted was seen as essential, especially when this leads to actual financial savings and better outcomes for the citizen. This is something we’re keen to put some time into in the future.
Sarah Prag and Ben Cheetham shared their experiences of collaborating on the DCLG led Waste Standards project. The most interesting thing for me was how a group of committed individuals just decided to get on with it and find some funding to make it happen – a proper coalition of the willing.
Practical Next Steps
The second half of the workshop looked at what we should focus on next.
We heard two contrasting experiences, firstly from Chris Fairs at Hertfordshire, who employ an extensive internal management system for issue reporting including individual definitions for fault types. They discovered that citizens are not so good at judging the severity of potholes – and through triage inspection, around 40% of reports are downgraded due to misreporting.
This contrasted secondly with the experience of Nigel Tyrell and his team at Lewisham who have recently adopted an Open311 enabled service, now linked into both FixMyStreet.com and LoveCleanStreets.
Perhaps the most surprising aspect of Lewisham’s experience is that well over half of reports actually come from their own internal staff using the system. This peer to peer approach has been transformative for them, with frontline staff motivated, more in control, more engaged with and connected to residents, and better able to integrate citizen reports into their own workflow – a very neat solution.
From this discussion we identified three specific actions that we’re going to help take forward;
- Identify local authority service areas that would benefit from the development of open standards
- Review output from the DCLG Waste Standards project, to determine how a similar approach can be applied elsewhere
- Feed back with suggested improvements to Open311.org for non-emergency reporting and update the list of UK Open311 endpoints
As with any such event the real value comes in the following weeks and months as we look for ways to collaborate together and opportunities to put into practice some of the things that we discussed.
We’ll certainly be planning follow-up events in the future, so if you’d like to get involved sign up for our newsletter, post a comment below or get in touch at email@example.com.
Public health teams, policy-makers, councillors and NGOs often need facts about a specific area. If they’re looking for data on things like the number of smokers, the demand for hospital beds, or the birth rate, they turn to their regional Health and Wellbeing Board.
These local authority committees are required to produce a document known as a JSNA (Joint Strategic Needs Assessment) every few years. It’s a snapshot of the demographics and healthcare needs of the local population, and is used by a variety of stakeholders including policy makers and strategy groups.
Like most local authority committees, the London Borough of Hackney and the City of London Health and Wellbeing Board have previously produced their JSNA as a simple read-only PDF document. But, in the digital age, they knew that there was more they could do to make this document accessible, useful, and engaging.
That’s when they called us in — not to build the final digital version of the JSNA, but to help them understand the possibilities and ensure that they were heading down the right path.
We’ve written up the whole process in a case study, so, if you’d like to know more, read on.
If you live almost anywhere in the UK, you can use FixMyStreet to report problems to councils.
The vast majority of councils have no problem with this, and they do a good job of responding to and dealing with reported problems. A bunch of councils even like the service enough that they’ve actually become clients, paying for customised versions that sit on their own websites.
But there have always been a small number of councils that have said ‘no dice’ to FixMyStreet: they either refuse to accept reports at all, or they tell FixMyStreet users to re-submit problems through another channel. Today the total number in the ‘no thanks’ column stands at ten councils – that’s out of about 430 in total.
Idealism versus Pragmatism
Recently we had a bit of a debate about what to do. On the one hand we want users to succeed in getting their problems fixed. But on the other we don’t want councils to simply opt out of the transparency and convenience that FixMyStreet offers.
We could digress into a long post with many other related issues, but today we’re simply talking about how we have decided to change the user interface for users trying to report problems to the minority of councils that claim not to be able to cope.
What to expect if you report a problem in the unlucky 2% of the UK
In order not to leave you high and dry, we’ll provide a link to the council’s own reporting system—because, irrespective of the platform, your report still needs to be made.
But we don’t think that this situation should be quietly accepted, by us or by our users, especially since it means some councils get to simply opt out of transparency about problem handling.
So at the same time we’re telling a user how to report the problem, we’ll also invite them to tweet about it, and/or contact their local councillors.
Why the situation arose
You may be wondering why some authorities won’t accept our reports. We do not, after all, ask councils to adapt or modify their internal systems in any special way, unless they actively want to adopt the Open311 standard.
The messages our users generate are just plain text emails, and they go into the same email inboxes as any other message to a council would.
These reports are carefully appended with lots of useful details, too, including the category of the problem, its exact longitude and latitude, and the postcode or street address where available. Users can also attach photos.
Generally the reason cited for not accepting such email reports (or the same reports made by the industry standard Open311 API) is that the computer system inside the council can only handle problems reported via the council’s own official web interface. Why this is only a problem in 2% of councils is a mystery that remains to be solved.
Does your council accept FixMyStreet reports? Input your postcode on the site, and see if you get the alert. If not – there’s no problem.
This is a problem we have been warning about for some time. Islington Council were fined £70,000 for a similar incident in 2012. In light of this fresh incident we again urge all public authorities to take care when preparing data for release.
As with the Islington incident, the information was in parts of an Excel spreadsheet that were not immediately visible. It was automatically published on 14th November when Hackney Council sent it in response to a Freedom of Information request, as part of the normal operation of the WhatDoTheyKnow website. All requests sent via the website make it clear that this will happen.
This particular breach involved a new kind of hidden information we hadn’t seen before – the released spreadsheet had previously been linked to another spreadsheet containing the private information, and the private information had been cached in the “Named Range” data in the released spreadsheet.
Although it was not straightforward to access the information directly using Excel, it was directly visible using other Windows programs such as Notepad. It had also been indexed by Google and some of it was displayed in their search previews.
The breach was first hit upon by one of the data subjects searching for their own name. When they contacted us on 25th November to ask about this, one of our volunteers, Richard, realised what had happened. He immediately hid the information from public view and notified the council.
We did not receive any substantive response from the council and therefore contacted them again on 3rd December. The council had investigated the original report but not understood the problem, and were in fact preparing to send a new copy of the information to the WhatDoTheyKnow site, which would have caused the breach to be repeated.
We reiterated what we had found and advised them to consult with IT experts within their organisation. The next day, 4th December, we sent them a further notification of what had happened, copying the Information Commissioner’s Office (ICO). As far as we are aware, this was the first time the ICO was informed of the breach.
From our point of view it is very disappointing that these incidents are still happening. Freedom of Information requests made via WhatDoTheyKnow are a small fraction of all requests, so it is very likely that this kind of error happens many more times in private responses to requesters, without the public authority ever becoming aware.
Our earlier blog post has several tips for avoiding this problem. These tips include using CSV format to release spreadsheets, and checking that file sizes are consistent with the intended release. Either of these approaches would have averted this particular breach.
We would also urge the ICO to do as much as possible to educate authorities about this issue.