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.

Remember how we put one simple question on the FixMyStreet homepage? This is possible because we know what most people coming to the page will want to do. So, because we’re confident about their intention, there’s something else we do too. We set the focus to that input. That is, we use JavaScript to put the cursor into that input box.

This means that you can go to www.fixmystreet.com and start typing your postcode straight away. There’s no extra click to put your cursor in the input box.

“Folk Andal. Castañuelas” by calafellvalo (CC BY-NC-ND licensed from Flickr)

Does it matter? On any single visit, if we didn’t do this, then probably this happens: you simply click in the box, and start typing, and do not even think about it. No problem! But sometimes you don’t notice that the cursor is not in the text box, and you start typing, and those letters do not appear. You look up, and you are a tiny bit annoyed; you click in the box and type it in again. That’s all.

But remember we’ve had well over one hundred thousand different users access FixMyStreet since it went live. On a site that gets that busy, even if we annoyed only 1% of those users on the homepage, it adds up to a lot of frowning. A user who is annoyed on the homepage is more likely to give up — and remember that the homepage often is not the first page they came to, so some users will already be getting tired of unnecessary clicking. This is why we do believe it is worth getting things like this right, and that it does matter.

In fact, in this case there are no other input boxes on the homepage: all the other interaction is by clicking on a link. This means that everything that page offers is just one click away (and yes, the way browsers handle forms means you can press Enter instead of clicking “GO” when you’ve finished typing, but we count that as one click).

This is a very small detail, and almost nobody would notice it if we did not point it out. But actually, that is one of the reasons we’re posting these design tips: good design, especially usability design, usually means you don’t notice when an interface is doing the right thing.

This tip is easy, and it builds on two earlier ones: don’t force your users to make any more clicks than absolutely necessary. Identify what they’ll probably be trying to do, and let them begin that as soon as possible, especially on the homepage.

"Click beetle (Agrypnus murinus)" by Rachel Scopes
(CC-BY-NC-ND-licensed from Flickr)

There are three things to think about here:

• Is there anything you can do to remove an extra click for a user? Do you really, really need that information from them? Or do you really need them to press ‘OK’ here?
• Too many clicks and users will abandon their task especially on sites where people are engaging with government or politics for the first time
• Most users began their task before they arrived at the site

The second point is especially relevant to users of civic sites like the ones we build. This is different from other websites. For example, if you go online to book a flight, or pay tax, or buy flowers because you forgot your mother’s birthday, even if the website is difficult or frustrating to use, you will stay on it until you have finished. The result is more important than the barriers: you need to finish. But people who are thinking about reporting a pothole they just missed on their bicycle that morning, or writing to their parliamentary representative for the first time, or making a freedom of information request — well, these people are already making an unusual effort. If you do anything at all to make that harder for them, then they can and they will give up. Civic sites must make the task so easy that nothing discourages users from finishing the mission they started.

The third point is more subtle. Earlier this year, Francis Irving explained how clicking on Google was part of the product. This means that, by the time a user has arrived on your site, they may already be many clicks and key-presses into the process. The more you prolong this effort, and especially if you prolong it with unnecessary or annoying extra clicks, the more likely it is that they will give up.

A user who gives up does not accomplish the task you wanted them to do.
A user who gives up might never bother to try again.
Civic engagement can be that fragile, especially for first-time users.

As we’ve already pointed out in a previous blog post, it’s likely that someone will arrive at your site on the “wrong” page, and so they will click again to get to your homepage. That click has already prolonged their journey. Click-fatigue starts to set in. You must help them to start doing something — instead of still clicking around trying to get to the place where they can start — as soon as possible. This is why you should think of the homepage as the centre of your website: it’s not the cover page or an introduction — it’s where people already on your site go to get things get done.

Or, to put it another way, by the time users have got to your homepage, perhaps they won’t have any spare clicks left.

Of course, we have to be pragmatic about this and make sensible guesses about what users will be trying to do — it’s silly to try to cover everything. We study our web analytics and do user-testing, but even if you can’t do that, it’s usually fairly easy to identify the key tasks. We don’t just think of the homepage as an introduction, or a cover page, or a portal (although it can also sometimes serve those purposes): ideally, for the most common tasks, it must be the start. The task does not need to be finished — that can be several pages further on. As we showed in an earlier blog post, we just need to get users started.

Let users make a useful click — even better, a successful click — and they stop thinking about giving up, and start getting things done.

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.

"Boundary Stone 1" taken by Tim Green (CC-BY-licensed from Flickr)

This is the first 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 for a given boundary in OpenStreetMap. Update: the second part is now available.

As mentioned in a previous post, we’re looking at ways of making it smoother to deploy FixMyStreet for a new country, city or use-case.  Essentially there are two fundamental bits of data that you need for this:

1. a mapping between a latitude and longitude (or postcode) to all the adminstrative areas that cover that point.
2. a mapping between problem type and adminstrative areas to an appropriate email address for reporting that problem.

The first of those is typically provided by a service called MapIt, an open source GeoDjango web application written by Matthew Somerville.  In the UK we are fortunate that official boundary data and the postcode database have now been released under an open data license from the Ordnance Survey.  However, in other many other countries similar data is unavailable, or not available under reasonable licensing conditions.  In such cases, though, all is not lost thanks to the extraordinary work of contributors to the OpenStreetMap project.  OpenStreetMap contains high-quality administrative boundary data for many countries of the world, and we know that data submitted to the project is available under the Creative Commons Attribution-ShareAlike license, so we can reuse it in a web service like MapIt.

The first step towards being able to build an instance of MapIt based on OpenStreetMap boundary data is to be able to generate a shapefile that represents a boundary in the project.  (In OpenStreetMap’s data model, boundaries are represented as either ways or relations, and those that we are interested in are tagged with boundary=administrative.)  Matthew had previously written code to generate KML files for boundaries in Norway in order to help to set up an instance of MapIt for Norway, which is used by FiksGataMi.  However, that script was quite specific to the organization of boundaries in that country, and it did not deal with more complex boundary topologies (e.g. enclaves), or different representations of boundaries (e.g. multiply nested relations).

So, Matthew and I wrote a new version of the code to extract a boundary from OpenStreetMap and generate a KML representation of it. The new version uses the Overpass API instead of XAPI, since it allows us to specify multiple predicates in the query and recursively fetch the ways and nodes that are contained in a relation.  Once all the ways that make up a relation have been fetched (ignoring those with roles like “defaults” or “subarea”), the script tries to join each unclosed way to any other with which it shares an endpoint.  We should end up with a series of closed polygons – the script exits in error if there are any unclosed ways left.  We can then directly create KML from these polygons, the only subtlety being that we need to mark certain boundaries as being an inner boundary (i.e., creating a hole in a boundary) if they had the role “enclave” or “inner” in an OpenStreetMap relation. For example, the South Cambridgeshire District Council boundary has a Cambridge City Council-shaped hole in it:

Similarly, the script has to cope with multiple distinct polygons, such as the boundary of Orkney.

If you want to use this code to generate a KML representation of a closed way or boundary relation from OSM, just clone the MapIt repository and run bin/boundaries.py:

$ bin/boundaries.py --help
Usage: boundaries.py [options]

Options:
  -h, --help            show this help message and exit
  --test                Run all doctests in this file
  --relation=<RELATION_ID>
                        Output KML for the OSM relation <RELATION_ID>
  --way=<WAY_ID>        Output KML for the OSM way <WAY_ID>

For example, to generate a KML boundary for the Hottingen area of Zürich, you can do:

$ bin/boundaries.py --relation=1701449 > hottingen.kml

In the next blog post in this series, we will discuss extracting such boundaries en masse and creating a service based on them.

DIY mySociety is all about making our code – and our experience – available to people who want to build similar websites in their own countries. We thought it would be helpful to list some examples of sites already using mySociety code, so you can see the variety of different possible outcomes.

It might seem like a simple task, but identifying sites in this way isn’t as straightforward as you might think – we don’t always know when people pick up our open source code! If we’ve missed any, please do comment below and we’ll add them.

There are also many sites around the world which were directly, or indirectly, “inspired by” ours. In these cases, the site’s owners have written their own code from scratch. That’s a subject – and a list – for another post. For now, here are all the international sites using mySociety’s code that we know about.

Alaveteli: our Right-to-Know Platform

WhatDoTheyKnow.com – our original Freedom of Information site
FYI.org.nz  – New Zealand Freedom of Information site
Pravodaznam – Bosnia and Herzegovina Freedom of Information site
Queremossaber.br – Brazil Freedom of Information site
Informatazyrtare.org – Albania Freedom of Information site
Tuderechoasaber.es – Spain Freedom of Information site
AskTheEU – Europe Freedom of Information site

Get the Alaveteli code here.

FixMyStreet: our fault-reporting Platform

FixMyStreet.com – our original fault-reporting site
Fiksgatami – Norway FixMyStreet
FixOurCity – Chennai FixMyStreet
FixMyStreet.br – Brazil FixMyStreet, based on both our code and FixMyStreet.ca from Canada

Get the FixMyStreet code here

Parliamentary monitoring and access to elected representatives

TheyWorkForYou – our original parliamentary monitoring site
WriteToThem – our original ‘contact your representative’ site
Mzalendo – Kenya parliamentary monitoring site
Open Australia – Australia parliamentary monitoring site
Kildare Street – Ireland parliamentary monitoring site
Parlamany – Egypt parliamentary monitoring site
Mejlis – Tunisia parliamentary monitoring site

A community of people, waiting to help

Inspired by the examples above? If you’re thinking of going ahead and building your own site, we’re here to support you with our easy-to-understand guidebooks and our friendly mailing lists. In our online communities you’ll find many of the people who built the sites listed here. There’s no-one better to ask questions, because they’ve been through the process themselves, from early conception right up to completion.

If you are one of those people who has been through the whole process of building, launching and running a site like these (with or without our codebase), and lived to tell the tale, please shout in the comments below. And especially if you’re open to people approaching with questions. Perhaps add a note to say where you prefer to have those conversations – whether that’s via your favourite mailing lists, Twitter, email or simply in the comments to this post.

One last thought – it’s interesting to see that our code can be used for areas as small as a single city (FixMyStreet Chennai) or as large as a confederation of states (AskTheEU.org). In short, it’s scalable! How will you use it?

Image by Windell Oskay, used with thanks under the Creative Commons licence.

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

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 Community – 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.