Our WhatDoTheyKnow.com service makes it really easy to request information from public bodies: all you need to do is describe the information you are seeking, send your request, and the authority provides it to you.
At least, that’s what happens when everything goes smoothly.
The default case
When you request information, the authority generally has two duties under the FOI Act:
- They must confirm or deny whether the information is held
- If they do hold it, they must disclose it.
But, there are circumstances – called exemptions – where the authority can withhold the information, or where they might not even state whether or not they have it at all.
Understanding which exemptions have been applied will also help you to understand what to do next.
The authority have confirmed they hold the information, but refused to release it
Why have they refused?
If your request is refused, the authority must say which exemption/s allow them to do so — have a good read of their response, and find out which one/s have been applied.
You’re looking for a section number that refers to the part of the Act that explains why they can refuse. You can check on FOIwiki’s handy table for the full list of exemptions.
Generally, when citing an exemption, the authority will also include the relevant text from the FOI Act, but if not, you can check it for yourself in the actual wording of the Act.
They did not cite an exemption
Authorities must say which exemption applies to your request — so, double-check that they haven’t done so (look in any attachments as well as in their main email), and once you are certain that they haven’t, write back and ask them to confirm which exemption they are using. Here’s an example of that in action.
If you want to, you can quote the part of the FOI Act which says that they must do this: Section 17 (1)b:
A public authority which, in relation to any request for information, is to any extent relying on […] a claim that information is exempt information must […] give the applicant a notice which—
- states that fact,
- specifies the exemption in question, and
- states (if that would not otherwise be apparent) why the exemption applies.
They did cite an exemption
Once you know which exemption has been used, you are in a good position to examine whether it has been correctly applied .
FOIwiki’s table lists all the exemptions that an authority can use, and includes some technical details about how they can be applied.
Some exemptions have very little room for appeal and the decision to apply them is obvious: for example, the Ministry of Defence won’t release plans for an upcoming battle in a time of war, making a request for this type of information pretty futile.
Others rely much more on the judgement of the authority who’s dealing with your request. Under Section 38, for example, a request can be turned down because it might ‘endanger the physical or mental health of any individual’– but in many cases, assessing how someone’s mental health might be affected by the release of information must require a certain amount of prediction.
Some exemptions allow an authority to use additional tools for assessing whether or not to release information:
- A public interest test
- A prejudice test
They said they’d applied a Public Interest Test
Some exemptions, known as ‘qualified exemptions’, require the authority to apply a Public Interest Test. This may give you more opportunity to ask for a review.
You can check the details of your exemption, and whether it’s qualified, in FOIwiki’s table.
In short, a public interest test sees the authority trying to weigh up the benefit to the general public of the information being released against the safeguards that the exemption is trying to provide, and decide which has more weight. The ICO provide good information about Public Interest Tests, with several examples of how they have been applied in the past.
If you think you can demonstrate that the Public Interest Test has come down on the wrong side of this weighing up exercise, you may want to ask for an internal review — see the end of this article for next steps.
They said they’d applied a Prejudice Test
Some exemptions, called ‘prejudice based’ exemptions, require a prejudice test. Again, this might also give you more opportunity to ask for a review.
You can check the details of your exemption, and whether it’s prejudice-based, on FOIwiki’s table.
Generally speaking, it’s applied to exemptions which seek to protect certain interests — for example, Section 29 of the Act allows exemption where release might do harm to the economy.
The prejudice test is a way for the person dealing with the request to check that the perceived threat is ‘real, actual or of substance’, and that there’s a reasonable risk that the release would cause the harm that the exemption is trying to protect against. There is a good explanation in the ICO guidelines.
As with Public Interest Tests, if you can demonstrate that the Prejudice Test has come up with a decision that is arguably misapplied, you may want to ask for an internal review — see the foot of this article for next steps.
They didn’t apply a Public Interest test
This probably means that the exemption is “absolute”, which makes it hard to challenge.
First, check on FOIwiki’s table that the Section the authority is using is an absolute exemption.
If it is:
- You might like to consider how cut-and-dried it is that the information falls within the class that the exemption protects. If it is clearly covered by the exemption (for example you have asked for information that is self-evidently provided to the authority by Special Forces) then there isn’t much point in going any further. But suppose you have been told that, under Section 21, the information is accessible via other means. Section 21 is an Absolute exemption but may be open to a challenge if, for example, there are circumstances which prevent you from accessing the information.
If it’s not:
- Ask the authority what public interest test they applied (or more details of how they applied it).
The authority won’t confirm or deny whether they hold the information
Why won’t they confirm or deny?
If confirming or denying whether the information is held would actually reveal exempted information in itself, then the authority may refuse to do so.
You can read more about this in the ICO’s guidance.
Can I do anything if they ‘neither confirm nor deny’?
Yes — you can challenge this stance if you have reason to believe that confirming or denying that they hold the information would not reveal exempted information in itself. However, it can be a time-consuming and potentially difficult route to take, and even if you are successful in getting the authority to confirm that they have the information, you may then find that an exemption is then applied, taking you practically back to square one.
If you still want the information you’ve requested, there are some general tactics you can use when faced with an exemption:
- Reduce the scope of your request: Check the exemption cited and, if possible, modify your request to circumvent it.
- Ask for an internal review: if you think the exemption, public interest test or prejudice test has been wrongly applied, you can ask for another member of staff to assess your request and whether you should have received a full, or partial, response.
- Appeal to the ICO: If you’ve had an internal review and still think the decision was wrong, you may make an appeal to the Information Commissioner’s Office.
Read more about all of these routes on our guidance page.
And here are some other useful links from the Information Commissioner’s Office:
- Guidance to authorities on when requests may be refused
- Guidance for writing a refusal notice
- Guidance on the public interest test
Finally, for now
The ideal is, of course, to submit a request which does not trigger an exemption, as clearly this saves everyone’s time. You can see our advice on writing responsible and effective requests here.
That said, full or partial refusals are not an uncommon occurrence — it’s totally routine for FOI responses to have some material removed (usually personal information such as names and roles of junior officials, or material identifying members of the public), or to turn the request down completely.
There are just over 25 exemptions listed in the Act (the exact number depends on how you count subsections and variants), removing the obligation for bodies to provide information in categories as diverse as any and all communications with members of the Royal Family, to commercial interests and trade secrets — and all sorts of things in between.
We’ll be examining the various exemptions available to authorities and suggesting ways in which you can avoid them. Keep an eye on our blog — and we’ll also link to posts from this post as we publish them.
Image: Scott Warman
The Universal Credits system is replacing many other welfare benefits… but slowly. Its roll-out won’t be complete until 2022, meaning that many are, understandably, confused about just what applies within their own local area.
Now Lasa, in collaboration with the Low Incomes Tax Reform Group (LITRG), have launched a tool to help with that problem. Just input a postcode, and it displays information about which benefits apply — and, crucially, where to go for advice in your area.
It’s part of a suite of offerings, also available as widgets that can be placed onto any website. All fall within Lasa’s remit to support organisations in the delivery of social welfare law advice to the disadvantaged communities they serve.
We’re always glad to see MapIt used in other people’s projects, especially those that make a complex system easier to understand.
Apparently advice workers are already expressing their gratitude for the fact that they can have this information at their fingertips — so hats off to Lasa.
No matter where you are in the world, if you run a Freedom of Information site, you’ll come up against one common issue: how to get people to use it.
It’s not just the usual hurdle that any new website faces, of getting publicity. There’s often a lack of knowledge among the general population about the whole concept of Freedom of Information, and the rights that come with it. Not only do users have to know about the site, but they have to understand why it might be useful for them.
The Freedom of Information conference, AlaveteliCon, was a great place to share ideas on how best to counter that. Here are ten strategies you can put into place right now.
1. Make FOI concrete
Freedom of Information can be rather an abstract concept to the average person, so your tweets, blog posts and press releases might not be getting through to them.
Instead of asking people ‘what would you ask under the FOI act?’ or ‘Isn’t freedom of information a valuable right?’, try asking more concrete questions like ‘what would you like to know about government spending?’ or ‘if you could ask one question about nuclear defence, what would it be?’
You might make a cheap, fun and informative video by going out onto the street and asking such pre-prepared questions to passers-by.
2. Use SEO to your advantage
Alaveteli is built so that it naturally performs well in search engines: the title of any request also becomes the title of the page, one of the main things that Google will consider when deciding how to rank a page for any given search term. And when useful or interesting material is released as a result of a request, that will attract inbound links and again, will be reflected in Google rankings.
The net result of this is that many users will come to your Alaveteli site because they’re interested in a specific topic, rather than because they want to make an FOI request. They may never even have heard of FOI, but they surely want to know about hospital mortality rates or cycling accidents in their local area.
A request on WhatDoTheyKnow, about the faulty brakes on a VW Passat, is one of the consistently most visited pages on the site. Even though the request itself remains unanswered, the page has become a place for Passat drivers to exchange knowledge and experiences.
Pages such as these may even be more frequently visited than your site’s homepage. Look at request pages as a first-time viewer would, and ask yourself if it’s clear exactly what site they have landed on, and what it is for.
Also: once you have created a community of people with a common interest (like the faults in the VW Passat), what could you do with them? Maybe post on the page yourself, offering to show how they could take a similar request to the next stage?
3. Make passive users into active users
The previous point leads to a further question: how can we turn users who land on our sites into active requesters (if indeed that’s a desirable aim)?
One answer might be to explain the concept of FOI somewhere within the request page template, so it’s seen by every visitor.
Another would be to build a user path that encourages readers to make their own request or—perhaps more likely to bear fruit, since making an FOI request tends not to be an impulsive action—include a newsletter sign-up button for people who want to know more.
Alaveteli already includes some actions in the right-hand menu on every request page, but so far they have concentrated on asking the reader to tweet, or to browse similar requests.
If you have ideas on how to encourage users to make requests, you could discuss them on the Alaveteli mailing list, or, if you’re a coder yourself, you could make the changes on your own branch and then submit it to be merged so that everyone can benefit.
4. Contextualise FOI
In the UK we are fortunate that when a news story is based on an FOI request, that’s usually mentioned within the story. It leads to a certain level of understanding of the concept of FOI within the general population.
Whether or not that’s not the case in your country, you could keep an eye out for stories that were clearly researched via an FOI request. Where FOI is commonly mentioned, setting up a Google alert may help.
You can then highlight these stories on a regular basis: for example, on a Facebook page, or on your blog. There was also talk of feeding a Facebook stream onto the homepage of one Alaveteli site.
5. Create a community
Sharing stories is one thing, but communities are a two-way endeavour. Facebook pages, blogs and Twitter accounts all need regular attention.
Post often, reply to users’ comments and queries, and soon you may find that you have a responsive community, and can even ask your followers to do a bit of advocacy for you.
A newsletter is also a useful way of getting your message directly into your supporters’ inboxes.
6. Write about interesting requests
Some requests just appeal more to human interest than others do, and they’re obvious candidates to be blogged/tweeted/Facebooked about. You might also consider putting out a press release.
There was a bit of discussion at the conference about the unfortunate phenomenon of ‘comedy’ requests which are of great interest to the press, but could actually harm the case for FOI. Examples given were:
- Is the New Zealand Prime Minister actually a shape-shifting reptile?
- A series of requests about the zombie apocalypse
In the UK we’ve generally taken the decision not to run these kinds of stories, though the press sometimes pick them up on their own anyway.
Such publicity can lead to ‘FOI is a waste of public money’ campaigns, and it was suggested that it is useful to have a list of the good things that have come from FOI that you can provide in return: here’s one that @FOIMonkey produced in 2012.
A middle ground between publicising ‘silly’ requests and trying to promote dry ones is to identify the stories that are in the middle ground: of great human interest, but with a serious point. Make the relevant requests yourself, if necessary.
As an example, a request such as the menus for food served in prisons can have an underlying political point if framed correctly.
7. Conduct outreach
NGOs and campaigning groups can find FOI a useful tool, and the fact that Alaveteli publishes out the responses can also help them with getting their cause known. A mail-out to likely organisations, or even face-to-face visits, may help.
Here in the UK, we have visited colleges to talk to trainee journalists. While most are aware of the FOI act, many do not know about WhatDotheyKnow and how it can be used not only to make requests, but to subscribe to keywords or authorities of interest.
However, such visits are fairly inefficient: they take time and only reach 50 or 60 students at a time. A better way may be to create and promote materials that colleges can use for themselves.
8. Paid ads
Although Alaveteli sites perform well in organic search, paid ads can give them an extra swathe of visitors.
Both Facebook and Google are potential platforms for ads, and you may be eligible to receive a Google Grant if you are a not-for-profit: these give you Google Ads for free.
mySociety are happy to share our experience in this area, and we will possibly put materials together if there’s enough interest.
9. Friends in high places
Some Alaveteli practitioners found it useful to partner up with a newspaper or online news source. The benefit runs two ways, since Alaveteli can be such a useful tool for journalists.
Dostup Pravda in Ukraine is a part of the country’s most popular news site, and perhaps one of the most expert Alaveteli sites at getting publicity. Pre-launch they ran a sophisticated campaign with celebrities hinting, but not saying explicitly what the forthcoming project would be. Their t-shirt was even worn by an MP on national TV.
For the solo activist, such promotional activity seems almost impossible, but news outlets have the contacts and resources in place to make it almost a routine task for them.
10. Create your own buzz
The press love lists and awards. One FOI site puts out an annual award for the best, the worst, and the most ridiculous requests made in the previous year.
This is a great idea for publicity, because as well as bringing the name of the site into the public consciousness, it also encapsulates a little lesson about how to use—and not abuse—FOI.
Now go and do it
So there you are: ten ideas to promote your site. Do feel free to add more in the comments below. And good luck!
mySociety’s Freedom of Information website WhatDoTheyKnow is used to make around 15 to 20% of FOI requests to central government departments and in total over 160,000 FOI requests have been made via the site.
Occasionally, in a very small fraction of cases, public bodies accidentally release information in response to a FOI request which they intended to withhold. This has been happening for some time and there have been various ways in which public bodies have made errors. We have recently, though, come across a type of mistake public bodies have been making which we find particularly concerning as it has been leading to large accidental releases of personal information.
What we believe happens is that when officers within public bodies attempt to prepare information for release using Microsoft Excel, they import personally identifiable information and an attempt is made to summarise it in anonymous form, often using pivot tables or charts.
What those working in public bodies have been failing to appreciate is that while they may have hidden the original source data from their view, once they have produced a summary it is often still present in the Excel workbook and can easily be accessed. When pivot tables are used, a cached copy of the data will remain, even when the source data appears to have been deleted from the workbook.
When we say the information can easily be accessed, we don’t mean by a computing genius but that it can be accessed by a regular user of Excel.
We have seen a variety of public bodies, including councils, the police, and parts of the NHS, accidentally release personal information in this way. While the problem is clearly the responsibility of the public bodies, it does concern us because some of the material ends up on our website (it often ends up on public bodies’ own FOI disclosure logs too).
We strive to run the WhatDoTheyKnow.com website in a responsible manner and promptly take down inappropriately released personal information from our website when our attention is drawn to it. There’s a button on every request thread for reporting it to the site’s administrators.
As well as publishing this blog post in an effort to alert public bodies to the problem, and encourage them to tighten up their procedures, we’ve previously drawn attention to the issue of data in “hidden” tabs on Excel spreadsheets in our statement following an accidental release by Islington council; one of our volunteers has raised the issue at a training event for police FOI officers, and we’ve also been in direct contact with the Information Commissioner’s office both in relation to specific cases, and trying to help them understand the extent of the problem more generally.
Some of our suggestions:
- Don’t release Excel pivot tables created from spreadsheets containing personal information, as the source data is likely to be still present in the Excel file.
- Ensure those within an organisation who are responsible for anonymising data for release have the technical competence to fulfil their roles.
- Check the file sizes. If a file is a lot bigger than it ought to be, it could be that there are thousands of rows of data still present in it that you don’t want to release.
- Consider preparing information in a plain text format, eg. CSV, so you can review the contents of the file before release.
This is the second part of a two-part blog post about some of our work on making it easier to deploy FixMyStreet and MapIt in new countries. This part describes how to generate KML files for every useful administrative and political boundary in OpenStreetMap.
The previous post on this subject described how to take the ID for a particular relation or way that represents a boundary in OpenStreetMap, and generate a KML file for it. That’s much of the work that we needed to create MapIt Global, but there are a few more significant steps that were required:
Efficiently extracting boundaries en masse
The code I previously described for extracting a boundary from OpenStreetMap used a public Overpass API server. This is fine for occasional boundaries, but, given that there are hundreds of thousands of boundaries in OSM, ideally we don’t want to be hitting a public server that many times – it puts a large load on that server, and is extremely slow. As an alternative, I tried parsing the OSM planet file with a SAX-based parser, but this also turned out to be very slow – multiple passes of the file were required to pick out the required nodes, ways and elements, and keeping the memory requirements down to something reasonable was tricky. (Using the PBF format would have helped a bit, but presented the same algorithmic problems.) Eventually, I decided that a better approach was simply to set up a local Overpass API server, and to query that. This is a great improvement – it allows very fast lookups of the data we need, and the query language is flexible enough to be able to retrieve huge sets of relations and ways that match the tags we’re interested in. It also means we would no longer have problems if connectivity to the remote server went down.
Another question that arose when scaling up the boundary extraction was, “Which set of tags we should consider as boundaries of interest?” On the first import, we considered any relation or way with the tag boundary=”adminstrative” and where the admin_level tag was one of “2”, “3”, “4”, … “11”. At the time, there were about 225,000 such elements that represented closed boundaries. Afterwards, it was pointed out to me that we should also include elements with the tag boundary=”political”, which includes parliamentary constituencies in the UK, for example. For later import purposes, I gave each of these boundary types a 3-letter code in MapIt, which are as follows:
- O02 (boundary="administrative", admin_level="2")
- O03 (boundary="administrative", admin_level="3")
- O11 (boundary="administrative", admin_level="11")
- OLC (boundary="political", political_division="linguistic_community")
- OIC (boundary="political", political_division="insular_council")
- OEC (boundary="political", political_division="euro_const")
- OCA (boundary="political", political_division="canton")
- OCL (boundary="political", political_division="circonscription_législative")
- OPC (boundary="political", political_division="parl_const")
- OCD (boundary="political", political_division="county_division")
- OWA (boundary="political", political_division="ward")
Importing Boundaries into MapIt
The next step in building our service was to take the 236,000 KML files generated by the previous step and import them into MapIt.
The code that creates the KML file for an element includes all its OpenStreetMap tags in the <ExtendedData/> section. On importing the KML into MapIt, there are only a few of those tags that we’re interested in – chiefly those that describe the alternative names of the area. We have to pick a canonical name for the boundary, which is currently done by taking the first of name, name:en and place_name that exists. If none of those exist, the area is given a default name of the form “Unknown name for (way|relation) with ID (element ID)”. There are also tags for the name of a country in different languages, which we also import into the database so that localized versions of the name of the boundaries will be available through MapIt with their ISO 639 language code.
Another tricky consideration when importing the data is how to deal with boundaries that have changed or disappeared since the previous import. MapIt has a concept of generations, so we could perfectly preserve the boundaries from the previous import as an earlier generation. This would certainly be desirable in one respect, since if someone is depending on the service they should be able to pick a generation that they have tested their application against, and then not have to worry about a boundary disappearing on the next import. However, with quarterly imports the size of our database would grow quite dramatically: I found that approximately 50% of the boundaries in MapIt Global had changed over the 5 months since the initial import. Our proposed compromise solution is that we will only keep the polygons associated with areas in the two most recent generations, and notify any known users of the service when a new generation is available for them to test and subsequently migrate to.
For reference, you can see the script that extracts boundaries and generates the KML files and the Django admin command for importing these files into MapIt.
The end result: MapIt Global
The aim of all this work was to create our now-launched web service, MapIt Global. As far as we know, this is the only API that allows you to take the latitude and longitude of any point on the globe, and look up the administrative and political boundaries in OpenStreetMap that surround that point. We hope it’s of use to anyone trying to build services that need to look up administrative boundaries – please let us know!
Photo credit: Hadrian’s Wall by Joe Dunckley,
We use Google analytics to understand how people use, and find, our sites. This blog post is a summary of one deceptively simple way we use this information to get more people to use TheyWorkForYou, our UK parliamentary tracking website.
One technical term: landing pages are the pages on a website that a user first arrives on from a particular link or search result. In this case, we created explicit landing pages. That is, we made these pages solely to be the target of search results. They serve no other purpose in the structure of the site; they are like super-focussed homepages. If you’ve read the blog post about minimising clicks on the homepage you’ll see that this is a clear example of that principal in action.
We added two specific landing pages to TheyWorkForYou — here’s one of them: http://www.theyworkforyou.com/parliament/
This page exists for a simple reason: we know that someone who uses the word “parliament” when searching on Google is probably looking for something that TheyWorkForYou can help with. By creating the “parliament” landing page, we are able to offer a page that is more likely to serve them. Incidentally, we try to make sure that searches lead to the landing page by using Google Adwords, and encouraging the Google bots to associate the page with the keywords, and other things too — but those are not the details this tip is about. Instead, look what we’ve put on that page. You’ll see it includes a set of useful explanations about parliament (it’s very common for people not to know how their parliament works), as well as a search box.
That search box is the same one that appears on every other page on the website, in the top right-hand corner.
But on this landing page, we’ve changed the prominence of the search box by putting it right in front of your eyes. And we added the caption: “Search for any word or phrase – see if it’s been mentioned in Parliament”.
Yes, there’s no technical magic here. No special code. It’s our regular search box. The difference is that on this page we know the user is thinking about parliament, and that search box does indeed search extensive records of what’s been happening in parliament. If we didn’t do this, we could leave the user to figure it out for themselves. They might of course… or they might give up. As you’ll have noticed if you’ve read the previous design tips, we don’t want users to give up, ever.
We did it again for “Hansard”. What’s Hansard? It’s the name of the transcript of all UK parliamentary debates, published by Parliament itself. Someone who knows about Hansard might be searching for it (on Google, say) and not realise that TheyWorkForYou has the entire transcript available for search. So we added another landing page. Again, it’s the same search that’s on all the other TheyWorkForYou pages, but now — for a user who’s already identified as someone who knows that Hansard exists — it’s clear that the search will do what they expect.
One of the common elements you will find across mySociety’s sites is that they have features designed to reduce duplicate messages or reports being sent to politicians, governments or companies. We often do this in quite a subtle way, so it is worth spelling out here how we do this across several sites:
- If you start to report a broken street light or pothole on FixMyStreet, you’ll see local problems before you start to type in your own details. This means if the problem is already there, you can see before you waste any effort.
- If you use WhatDoTheyKnow to send a Freedom of Information request to a public body, we provide a facility which encourages users to search through other people’s requests before they type their new request in.
- If the 08:10 train you take to work is always late, when you go to report it on FixMyTransport, we show you all the other problems already reported on that route. If someone else has already set up a page, you can press the big green ‘join’ button, and show your support.
- If more than a handful of people try to use WriteToThem to send an exact duplicate of the same message to a politician, it will prevent it. This is because we know that politicians listen much, much more to individual messages from constituents than bulk mails.
This pattern – trying to intervene before people write identical messages or reports – is a design decision that makes a big difference to the way these sites operate. As usual with mySociety sites, this little feature seems like the sort of thing that would be quite tempting to skip when building a copy. But it really matters to the long term success of the sites. There are three reasons why.
First, there is a simple public benefit that comes from saving time. There’s no point us wasting your time if a report or request has already been sent, especially around minor issues. Saving your users time makes them happier and more likely to enjoy their experience.
Second, if you can spot that someone is about to send a duplicate message, we may be able to encourage that user to support the existing report instead of making a new one. For example, on FixMyStreet you can add an update to an existing pothole report (“it’s getting worse!”).
This feature is most visible, and most mature, on FixMyTransport, where users are clearly encouraged to ‘support’ pre-existing reports, rather than making new copies. By discouraging duplicate reports, we let people with a shared problem work together, even if this only means adding themselves as a “supporter” and doing nothing else. We know that many people search for, and find, problem reports which have turned into these little campaigns, which they then join and help. So even if they are only reading them (not joining them) that exposure can have some value to the people affected. This would be diluted if we created lots of similar reports about the same problem.
Third, we discourage duplicates for the benefit of the governments and companies receiving messages. We don’t think FixMyStreet is effective because it lets people moan: we think it’s effective because it helps local government to be effective by giving them good quality reports about local problems, in formats that area easy to handle. This good quality reporting increases the chance that the government will understand the problem and act on it, which leads to our main goal – citizen empowerment. Recipients are unlikely to help users if many of the messages they get are confused, inaccurate or duplicates, so we work on all these fronts.
So if you haven’t thought about this before, notice how the “work flow” through our sites makes you see similar problems before you’ve finished reporting your own. This is the implicit way to prevent duplication. We don’t have “Stop! Warning! Check this is a new problem!” messages, because we never want to discourage genuine users. But the careful design of the interface gently discourages, successfully, duplicate reports, and encourages supporting of other items.
It’s never possible to entirely prevent duplication. But we try hard, because it’s always better to join people together around common causes, than it is to let them struggle alone.
When a user on FixMyTransport tells us about a journey they’ve had, we ask them if it was on a bus, train, underground, or ferry. This is a simple question, but of course our lead developer Louise thought carefully about how to ask it.
As programmers, we sometimes approach collecting data from the user just like filling in a form — a paper form. So, we could ask the bus/train/ferry question by using a list to select from (in HTML, that’s a
selecttag) — perhaps spread out, or as a drop-down list — or maybe as a set of radio buttons. But in this case we have deliberately broken away from idea of the form.
Instead, FixMyTransport uses four big buttons. They look like this:
Effectively, this means we have a whole webpage devoted to one single question. That’s perhaps not what you’d expect if you’re building an online form. Often it seems easier not to break a task across several pages. But here we have a single page with a single question on it.
There are some important things to note about this page:
- the four buttons are big and colourful and beautiful (we can thank Supercool for this, who did the design work on the initial FixMyTransport site)
- it’s a very easy question, even though the answer is critical (because it affects the kind of data we need to ask next)
- it’s a reasonable question — the user isn’t surprised or confused to be asked it
This page has been very successful. We know this because we study our web analytics (that is, how people use our sites) as well as running usability testing. It’s true to say nobody gets stuck on this page, nobody drops out, and in fact most people don’t even think about it (that’s the “reasonable” thing, above).
After the latest session of FixMyTransport usability testing, run by our developer Mark, we had a discussion with other team members. We agreed this was one of our favourite FixMyTransport pages. It’s pretty, it does the job, it moves the user forward (see the earlier blog post about “why the FixMyStreet homepage asks one easy question”)… and best of all it shows that some of us were wrong to be cautious about introducing another step into the problem-reporting process.
Incidentally, Mark recommends the book Rocket Surgery Made Easy if you’re interested in running your own usability tests.
In summary, sometimes a super-simple choice is strong enough to be presented as a single webpage all by itself. Don’t fall into the trap of thinking web forms should be like paper forms.
When you report a problem on FixMyStreet.com, the site displays a map for you to click on to indicate its exact location. Of course, you can zoom in and out of that map, but when it is first displayed, FixMyStreet needs to use an initial ‘default’ zoom level. Ideally, this is a zoom level that reduces the number of clicks required before a user can pinpoint the location of their problem.
And here’s where we encounter a tricky problem. The world is a varied place – some towns are very dense with buildings and streets crammed close together. In these areas you need to default to a zoom that’s quite ‘close in’, otherwise it can be hard to locate your problem.
But out in the countryside, we have the opposite problem. You can have huge areas where there’s nothing but blank fields or moorlands. If the default map zoom is ‘close in’ here then users are likely to see a big map full of nothingness, or maybe just a single stretch of unidentifiable road.
So, what is to be done?
The answer is this – every time you search for a location in FixMyStreet the website does a check to see whether the location you typed is in an area where a lot of people live, or very few people live.
mySociety has been storing this population density data in a webservice which we call Gaze. If the area you searched for is in a densely populated area we assume that it must be an urban location, and the map starts with a helpfully zoomed-in map. But if you’re in a sparsely populated area then it’s probably rural, so FixMyStreet starts zoomed out, making it easier to get an overview of the whole area.
Where do we get the data from? Our late colleague Chris discusses this in a blog post from 2005 — the short answer is NASA SEDAC and LandScan. It’s an interesting example of how unexpected things can happen when data is made public — if population density wasn’t available to us, we wouldn’t have been able to put this small but clever detail into FixMyStreet’s interface.
When you report a problem on FixMyStreet, we ask you to click on a map to pinpoint its location. For example, if you want to tell the council a tree has fallen over, or there is a hole in the road, you can click exactly where it is. This is an easy way to provide the most accurate information in the report that we then send to the council.
If you’re a programmer then you probably think that it’s obvious to use a map for such problem reporting. We agree: maps are ideal for this, and it’s a shame that so many councils still aren’t doing it this way.
However, even though it’s very useful to have an accurate location for a problem, with FixMyStreet there are several reasons (below, we list just four) why someone might not be able to simply “click on the map”. In these cases, the map is no longer helpful — it’s a barrier. So we have to ask: is an accurate location so important that we should refuse to accept reports without one?
It turns out, for FixMyStreet, we don’t really need that accuracy. Sure, it’s best if we have it, and over 95% of reports do contain pinpoint locations, because most people do click on the map. But if we don’t have that location data, then we can still make a fair guess from the postcode or area name that the user has already provided (that’s how we knew which map to display, after all). So we allow the user to submit the report without clicking on the map.
Consequently, every time someone reports a problem without using the map, it means they’ve not given up, or clicked on the wrong place just to submit the form. In fact, they’ve reported a problem because we removed what would otherwise have been a barrier.
So, here are some reasons why we didn’t make clicking on the map mandatory in FixMyStreet:
- Map-reading isn’t a skill everybody is comfortable with
When you’re building and testing FixMyStreet, you tend to imagine people will be reporting problems in places they know well. It’s easy to find somewhere on a map you are familiar with. But FixMyStreet users could just as easily be reporting a problem they passed on their way to work, on holiday, or at a party. So if they can’t read maps well it might be difficult or frustrating to locate a unfamiliar road junction or building.
- Navigating a map requires more challenging user skills
FixMyStreet is easy to use, deliberately — in fact you can report a problem just using your keyboard. Zooming and panning a map element is much harder than any other part of the process. Remember that if you’re building a website like this yourself you are already comfortable with using complex controls that lots of people — FixMyStreet-using people — are not. This is true even before considering other limitations such as small-screen devices or visual disabilities.
- The map might not be helpful
We rely on third-party maps. Most of the time, they are excellent. But what if the map is out of date? What if the problem is on a new road which hasn’t been added yet? What if the user remembers that the pothole was outside a distinctive shop or remarkable tree, only to find such landmarks aren’t on the map?
- The problem might not have a location
Potholes are easy: they have a fixed position on the road. What about smells or flooding? These problems sometimes simply don’t seem to have an obvious pinpoint location.
In summary: we think clicking on a map is the best way to ask for a location from FixMyStreet users. But if we forced everybody to do it, some problems would never be reported, and some people would never become FixMyStreet users.
- Map-reading isn’t a skill everybody is comfortable with