DIY.mySociety.org
Currently viewing the category:
"Advice"
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,
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 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.
“In the middle of America” by Kathie M Ceballos (CC BY-NC-ND licensed from Flickr)
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.
If you’re building any civic or democratic website, we know that you’ll want to make its homepage beautiful and unique. After all, you want to make a good impression on your users, and first impressions are the ones that count.
Go ahead! Dive in and make it special… but also take our advice and don’t burn all your energy on building a perfect homepage. The reason why is that many of your users will come to your site without ever seeing your homepage.
The main reason for this is the influence of search engines, Twitter and Facebook. These have already changed users’ behaviour during the short history of the World Wide Web: there was a time when people could be expected to start on the front of your site and work inwards, clicking on the links you provided, step by step. But several things now work against this: search engine results link to pages deep within your website; links are easily and routinely shared (email, Twitter, Facebook, Pinterest, even QR codes); and people are becoming accustomed to simple URLs that they might compose by hand, such as mysociety.org/contact. Realistically you must expect a user’s first page to be any* page on your website.
This means that, on every page except the homepage, your users may have arrived without any context or history — and, importantly, without the benefit of all the fabulous design time you’ve put into that glorious homepage.
“Teleport” by mercurialn (CC BY-NC-ND licensed from Flickr)
Spend some time thinking about how you are treating those people. Imagine they’ve been teleported into a strange land; they know, roughly, what planet they’re on, but otherwise it’s all new to them. That’s how bewildering this could be to a user who’s clicked on a link that drops them deep into your website. It’s a common experience and it’s easy to get right, but if you get it wrong, they will just as easily teleport out again. And they will think: “that is not somewhere I want to visit again.”
None of this is very radical. But the point is that it’s very easy to overlook — especially because, if you’re one of the developers working on a site, you already know too much about how it works to be objective when you look at what you’ve made.
Here are some things you should consider:
- Do your pages instantly say what they’re for? A new user landing on an unfamiliar page will grope for some explanation – “This is a page about a politician”, or “This is a page about problems in this street”. You need to make sure you spell it out somewhere easy to see.
- Can the user easily take an action from this page? If the user was looking for more than just a quick hit of information, the chances are that they want to get something done. Don’t fall into the trap of assuming that, just because they’ve landed on this page, this is the page where they want to be. For example, if you look at any one problem report on FixMyStreet and you will find a big “Report a problem” link in yellow at the top of the page.
So you should of course create a beautiful, functional homepage, but you should never forget that almost every page on your website will be a homepage for someone.
* Technical note: as you’d expect, there are a few exceptions to this (admin pages and so on), but in general all our sites deliberately offer their data pages with URLs that allow such indexing.
“Clock of the long now (prototype)” by piglicker (CC-BY-NC-ND-licensed from Flickr)
One of the democratic software tools mySociety has built is an online petitions tool for use by governments. We built the first version for the British Prime Minister’s office, and now it is used by a variety of British local governments.
When a user wants to make a new petition, they fill in a web form, containing the petition details.
During this process, a user must choose when they want their petition to end.
The question we are exploring today is this: what’s the best way to ask for that information?
From a developer’s point of view, the end of a petition is obviously a date. This is because the petition software really needs to test whether or not today’s date comes after the petition’s end-date. So an easy — and accessible — way to ask for this data would be as a date input, which could even helpfully trigger a calendar pop-up menu or similar widget.
But we don’t do it like that, for a couple of reasons, both of which you might miss if you were to build this from scratch. Instead, we ask:
For how long would you like your petition to accept signatures? (e.g., “1 month”; maximum 1 year)
That’s not a date input. But why?
The first reason is that the user is thinking about running a petition as something they plan to do for a period of time. Put simply, if you’re asked about your next holiday, you’ll probably imagine what you’ll be doing (“I’m going to spend two weeks lying on the beach”) rather than the end of it (“I’m going to stop lying on the beach on the 25th of August”).
In terms of interface design, this means that users will tend to think about how long something lasts differently than from how a computer or a coder will tend to think about it. The general rule is: even for something as simple as this little web form, if it’s possible to create an interface that matches the way that a user thinks about the world, then it will be less confusing for them than one that does not. Usually this means the system has to be a bit more complicated to program, in order to convert what the user types to what the computer needs.
The second reason that we ask for a duration, not a date, is that in the case of the petition, the user doesn’t actually know when their petition is going to start. Although they’re entering it into the website right now, there will nearly always be a delay before the government approves it. So most of the time, by asking for a duration, we’re avoiding raising this issue at all, and the user simply says what they mean, and it works. A petition with a duration of “3 months” will run for three months, once it goes live. A date wouldn’t survive an unspecified delay like that.
So, we ask for a duration and parse the result to turn it into a date when it goes live… but there’s an extra twist. What if the user really does know the date their petition must end? Maybe it’s a petition about closing the main road for a New Year’s Party, and it’s got to be discussed at the council meeting that’s being held on the 5th of December. Well — OK! If the user puts a date into the duration field, even though we didn’t ask for a date… we accept it. We can do some validation to make sure it’s a sensible date, of course, but basically if someone does puts a date in there, then that’s fine too.
What we hope this has shown you is that even something as simple as asking a user for an end date can be done easily (just use a date input there) or thoughtfully. The system wouldn’t break if we did it the other way. But making things as convenient as this means that we are allowing users to focus on the thing we’re trying to let them do, instead of drawing attention to how we are making them do it.
Simple things are the most easily overlooked. Two examples: a magician taking a wand out of his pocket (see? so simple that maybe you’ve never thought about why it wasn’t on the table at the start), or the home page on www.fixmystreet.com.
The first thing FixMyStreet asks for is a location. That’s so simple most people don’t think about it; but it doesn’t need to be that way. In fact, a lot of services like this would begin with a login form (“who are you?”) or a problem form (“what’s the problem you want to report?”). Well, we do it this way because we’ve learned from years of experience, experiment and, yes, mistakes.
We start off by giving you, the user, an easy problem (“where are you?”) that doesn’t offer any barrier to entry. Obviously, we’re very generous as to how you can describe that location (although that’s a different topic for another blog post). The point is we’re not asking for accuracy, since as soon as we have the location we will show you a map, on which you can almost literally pinpoint the position of your problem (for example, a pothole). Pretty much everyone can get through that first stage — and this is important if we want people to use the service.
How important? Well, we know that when building a site like FixMyStreet, it’s easy to forget that nobody in the world really needs to report a pothole. They want to, certainly, but they don’t need to. If we make it hard for them, if we make it annoying, or difficult, or intrusive, then they’ll simply give up. Not only does that pothole not get reported, but those users probably won’t bother to try to use FixMyStreet ever again.
So, before you know it, by keeping it simple at the start, we’ve got your journey under way — you’re “in”, the site’s already helping you. It’s showing you a map (a pretty map, actually) of where your problem is. Of course we’ve made it as easy as possible for you to use that map (and, yes, we also let you skip it if for some reason a map doesn’t help you). You see other problems, already reported (maybe you’ll notice that your pothole is already there — and we haven’t wasted any of your time making you tell us about it, even though you probably didn’t realise we intended right from the start to show you other people’s problems before you reported your own). Meanwhile, behind the scenes, we now know which jurisdictions are responsible for the specific area, so the drop-down menu of categories you’re about to be invited to pick from will already be relevant for the council departments (for example) that your report will be going to.
And note that we still haven’t asked you who you are. We do need to know — we send your name and contact details to the council as part of your report — but you didn’t come to FixMyStreet to tell us who you are, you came first and foremost to report the problem. So we focus on the reporting, and when that is all done then, finally, we can do the identity checks.
Of course there’s a lot more to it than this, and it’s not just civic sites like ours that use such techniques (most modern commerce sites have realised the value of making it very easy to take your order before any other processing; many governmental websites have not). But we wanted to show you that if you want to build sites that people use, you should be as clever as a magician, and the secret to that is often keeping it simple — deceptively simple — on the outside.
Image by Bixentro
There are quite a few people around the world who are interested in running websites like FixMyStreet.com , TheyWorkForYou.com and WhatDoTheyKnow.com in their own countries. This high level of interest is why we have set up DIY mySociety – to make it an easier to get started running your own similar sites.
One of the most common barriers to launching a new website is the lack of technology skills. This post is about finding those skills in your city, country or region.
The Basics
You don’t have to be a web developer to run a website based on mySociety code, but you do need access to someone with developer skills if you’re going to launch your own successful site.
When people are thinking about setting up a new mySociety-style website, they often assume that it can’t be done, because they aren’t technical, and they don’t know anyone who is.
Even if you’re not a coder, you might still be the right person (or group of people) to run this project. Are you good at motivating people, communicating, and organising? Then you have invaluable skills for this kind of enterprise. But that doesn’t remove the need for technical skills.
Why do you need a web developer?
You need a developer because it takes specialist skills to set up a website based on mySociety’s software.
Our software helps by saving developers months or years of work that they would have to do if starting from scratch. But it does not eliminate all the technical work – you will still need someone who knows how to build websites.
You need a web developer to:
- Install the software on a computer
- Configure the software to work in your local language(s)
- Make changes to the wording and graphic design of the site
- To add or remove features that are important to users in your country, city or region
You will need a developer to work on the project not only at the start, but for regular maintenance and improvements once it’s up and running.
What are my options for getting a developer to help?
If you are not a developer yourself, you have three basic choices for getting hold of some help.
- Pay a developer to set up your website
- Pay a web company to set up your website
- Ask a volunteer to set up your website
Obviously the third of these options looks the most attractive, but please be aware that when you are asking somone to volunteer on a website like this you are asking them to work for days and weeks for free – this is not a question of helping our for an hour or two once a week.
Working with an individual vs a company is also a decision. An individual will normally charge less per day worked, but an agency may reduce your risk of hiring someone who just can’t do the work at all. It is a balance. If you find someone who you think might be good, but you’re not sure, please don’t hesitate to ask mySociety for help in deciding.
What are you looking for in a web developer?
Judging web developers thoroughly is a tricky, expert task. However, the following rules of thumb will help you:
1. Check that they care about using the internet to help with democracy or transparency. If they are excited then they are more likely to stick with the project, and make it succeed. Do not assume that just because they know about computers, they do not care about the rest of the world!
2. Ask them to show you some kind of website or mobile app that they build entirely or mostly on their own. If they can’t show you anything then that might cause you concern. If they have something good, that’s a good sign.
3. If they really keen to win your business or volunteer, they might be willing to try setting up a basic version of the website before you start working together. If they can do this then that’s a pretty good sign that they might be the right person to help you in the longer run.
4. If they tell you “there’s no need to re-use mySociety’s software – I can build this new website from scratch more easily”, this is a bad sign. Less good web developers often underestimate how hard it is to build a website like mySociety runs, and saying this is a common give-away that you are talking to someone who might not be very likely to succeed in launching your website.
Where on earth can I find someone?
Whether they are being paid or are volunteering, the question remains: where do you find such people? The answers might surprise you – it’s not as simple as ‘put an advert in the newspaper’.
Linux User Groups are found in many countries around the world, and often contain people interested in working on interesting projects.
OpenStreetMap is a global map that is made by normal people who live around the world. It has many local branches, and can also be a good place to mail or meet to find local people to talk to.
Digital democracy and transparency mailing lists are email discussion forums for people with common interests. Developers often join mailing lists that deal with their areas of expertise or passions, so emailing a message to see if people are interested in working with you is a good way of reaching out quickly to people who are interested in the same kinds of projects as you are.
To find such mailing lists, try searching the internet for phrases like ”Digital democracy mailing list” and “transparency mailing list” in your own language, or try one of the mailing lists below to see if there is anyone interested in working with you in or near your country:
- Transparency Tech Google Group – for anyone using technology to aid transparency.
- Open Government mailing list – for those interested in open government data.
- DoWire.org – international exchange on e-democracy and online news.
- Sunlight Labs - for software developers interested in open government, government transparency, and civic hacking.
- Alaveteli mailing list – for those interested in starting a Right-to-Know website.
- FixMyStreet mailing list – for those interested in starting a street problem-reporting website.
- mySociety dev public – our general mailing list.
The Open Knowledge Foundation is a network of regional groups which bring together people interested in open data, including developers. Joining your local group – or starting a new one – will help you meet people with common interests. You’ll find a list of all local groups at the foot of this page.
BarCamps are workshop-style events, often focusing on web applications, open source technologies and open data – and are a great place to meet people with the skills you need. They happen all over the world – search for ‘barcamp‘ + the name of your city or region. If there are none near you, you can organise your own.
CityCamps are a specific type of Barcamp. They bring together local government officials, municipal employees, experts, programmers, designers, citizens and journalists to share perspectives and insights about the cities in which they live. You can check whether there’s a city camp near you here – and if there isn’t, you can start one.
If you try all the above approaches, and try to meet with local people from all these kinds of group where you live, it will not be long before you find some sympathetic people who may well be interested in your project.
Lastly, Ask here
If you’re looking for developers or any other people to join your project, feel free to leave a comment at the end of this post – make sure you say where you are and what you’re hoping to achieve.
FixMyStreet.com is mySociety’s popular British site for reporting problems like broken street lights and holes in the road. It works because as well as recording reports online, it sends copies to the relevent local governments. It has inspired many ‘grandchildren’ around the world.
Today marks the start of a new era for FixMyStreet as we push out the start of a major design upgrade in Britain, aimed particularly at making the mobile web experience as good as the desktop web experience.
Simultaneously, we’re also launching a guide to using the FixMyStreet Platform as the basis for your website in other countries.
- We’ve set up a new homepage for the FixMyStreet Platform.
- We’ve set up a new mailing list which you can join if you want to talk with us and with other users.
- We’ve published a brand new guide, suitable for technical and non-technical readers, about how and why you should consider using the FixMyStreet Platform to build your FixMyStreet-style website
We’re also here, waiting and ready to give you a hand. So if you’ve ever thought about setting up FixMyStreet outside Britain, there’s no better time to start than today.
