Three of us from mySociety’s international team have spent the last few days in Yangon, Myanmar. We’ve come to visit people we’ve been talking to recently about some potential local projects, but we rushed the dates of our visit so we could be present at Myanmar’s first hackathon.

As he kicked off the final presentations, event organiser David Madden (representing Internews and Code for Change Myanmar) summed the event up in numbers:

• 76 hackers
• 17 teams
• 8 NGOs’ problems
• 48 hours

Events like these live or die based on the enthusiasm and energy of the organisers and the participants. In that respect, this Myanmar hackathon was best we’ve ever seen. The motivation of everyone present was palpable, driven by David’s seemingly unlimited supplies of energy. It’s also relevant that the problems the teams were working on were specific, real ones that had been submitted by local NGOs who genuinely want them to be solved. This didn’t happen in isolation: representatives from the NGOs were available throughout the weekend to ensure that each team understood the problem they had adopted and were building something that met their requirements.

It’s not uncommon to see scratchy or shaky products being lauded at the end of hackathons, but that was not the case here. The standard of the teams’ work was unbelievably high. Many produced complete Android apps together with websites and iOS versions too. And while it’s easy to be distracted by the technical achievements, David and his people had been clear about the importance of the three-minute pitches/demos (yes: just three minutes!) that were the culmination of each team’s weekend of work. Participants were coached by the extraordinarily astute Phil Morle of Pollenizer in a series of rehearsals — a form of preparation and refinement that frankly was as valuable to those of us who sneaked in to watch it as it was to the participants themselves.

As the final pitches flashed past — timekeeping was politely but sternly enforced — we were again and again astounded by the high standard of the apps, websites, and solutions that were being presented. The judges were considering five criteria:

1. impact: does this make you think “wow”?
2. practical: can the NGO actually use it?
3. creative: has the team done something unexpected?
4. execution: did the team implement it well?
5. pitch: how clearly was the solution presented?

(See Phil’s post about how to win the competition for more information — it gives a great insight into the attitude prevalent at the event, as well as pitching in general.)

The thoughtful organisers also provided other services: real-time English translations during the presentations (wonderful students from UCSY typed furiously into a google doc projected alongside the stage); buses to get back into town late at night; full meal catering; and caffeine that flowed freely from sponsors Red Bull and Nescafe.

We helped a little as mentors, asking the teams questions about their direction (we do know a little about user-centred design, after all) and providing enthusiasm and praise. But mostly we spent our time being impressed and inspired by these amazing people as they hacked away throughout the two days. Myanmar is deservedly famous for being a beautiful country of unrelentingly charming people — but in the last few days we’ve been shown that it has tremendous technical capability too. We will leave knowing how privileged we were to be here to see it being demonstrated so clearly and enthusiastically.

UKgovcamp14 took place at London’s City Hall last weekend — mySociety was one of the sponsors. It’s a great opportunity to meet people, many of whom are currently working inside local or national government, who don’t need further convincing that civic services can be improved by sensible use of well-designed online technologies. Furthermore UKgovcamp is an unconference, which effectively means people get to talk about what they really want to talk about, with a spontaneous agenda — ideal for sharing experience, suggestions, and enthusiasm.

City Hall is an intriguing venue: it looks like a giant spacewoodlouse getting ready to pounce across the Thames onto the Tower of London. The main chamber has unnervingly clear accoustics (ideal for an event like this) and a history-rich view (HMS Belfast, the White Tower, and Tower Bridge); and we set our stall up on a floor that was tiled with — what else? — a huge, detailed aerial view of London.

So this blog post is just a quick “hello” to all the people we talked to at the event, and a hearty “thanks” to the hard-working, grey-hoodied crew who made it all run so smoothly. Our Ben led a session at the end of the day on Open Standards. In the discussion that followed, we referred to two specific examples. When we built the new transcript tool SayIt, we decided it should initially work with transcripts in the Akoma Ntoso open standard for parliamentary documents — the SayIt site shows some examples of the subset we’re currently using. The point of course is not that transcripts need to be anything to do with parliament (see, for example, the plays of Shakespeare), but that the problem of structuring such documents has already been addresssed, shared, and adopted by others who happen to be in that field.

The other example was the Open311 standard, which regular blog readers will recall from previous blog posts.

We ended the day by getting soaked by an unexpectedly horizontal rainstorm the moment we left the sanctuary of City Hall’s glass carapace. Luckily we were able to dry out whilst continuing the networking in the pub just across the road. So, all in all, a splendid day.

Image credit: via Flickr from David J Pearson CC BY-SA 2.0

This month we released a new version of FixMyStreet. Amongst the new features, fixes, and thingamajigs were some small improvements added by two volunteers, Andrew and Andy.

Even though these are not core pieces of functionality — in fact, precisely because they are not — we want to draw your attention to why they were included, and why this is a Very Good Thing. And perhaps, if you’re a coder who wants to put something into an Open Source project but hasn’t quite found a way in, Andrew and Andy’s work will nudge you into becoming a contributor too.

One of the axioms of Open Source is that, because anyone can read the source code, in theory anyone can contribute to it. In practice, though, it’s not really as simple as that. Both ends of the “anyone can contribute” idea require effort:

• Before contributing to a project of any complexity (as we hope you want to do), there’s often a lot to learn, or figure out, before any work can even begin;
• Before accepting contributions to such a project (keen as we are to do so), there’s an overhead of testing, checking, and managing the incoming code.

The ugly real world

The basic issue here is that software is complex — no matter how well-written, tested and documented program code is, if the problem it’s solving is in the real world, it’s not going to be simple.

This is especially true of anything used by the public, because often you can only make things seem simple at the front (such as a clean web interface or “user journey”) by working hard behind the scenes with data structures and processes that handle the underlying complexity. It’s inevitably true of any projects which have been developed over time — programmers like to use the term “legacy code” to describe anything that wasn’t written then way they’d choose to write it now.

Often the problems that software is solving are not quite as obvious as they first appear. At mySociety we’ve got a wealth of experience and actual usage data that ultimately changes the way we build, and develop, our platforms. We understand the fields we work in well (technically, the nerds like to call these the “problem domain”), whether it’s governmental practice or civic user behaviour, and that’s often knowledge that’s not encapsulated anywhere in the program code.

Furthermore, any established platform must protect against the risk that new changes break old behaviour — something that regression testing is designed to catch. This is especially important on platforms like FixMyStreet or Alaveteli where the software is already running in multiple installations.

This is why we have a team of full-time, experienced, and (thanks to our rigorous recruitment process) talented programmers who can invest the time and effort to be familiar with all these things when they set to work coding.

But this builds up to an impediment: sensitivity to any of these issues is enough to make anyone think twice about simply forking our code and starting to hack on it for us.

How it sometimes works

In practice, then, how does anything get contributed? How come it doesn’t all get written by our own coders?

The answer is, of course, we do work with major contributors outside our own team (have a look at the activity on our github repos to see them) — but it always requires a period of support and on-line discussion both before and during the process. There’s also the business of testing, and sometimes politely pushing back on, pull requests (which is how code contributions are submitted). But the fact of the matter is that this is only possible for people who are willing to spend time familiarising themselves with the specific code, technologies, and practices that we’re using on that project. These tend to be hard-code devs, and — here’s the point — they’re always experienced Open-Sourcers: this will never be the first time they’ve worked on such a project.

Which is where the little features come in.

The joy of small

We noticed this problem — that contributing code to our projects is simply not easy for us or for contributors. Importantly, it’s not just us: it’s Open Source everywhere. But we can’t simply dismiss the opportunity for contribution. We want to encourage coders to do this, because we believe that Open Source is intrinsically a good thing.

We do two things to make it easier to contribute:

• We identify small features that a coder can approach without a full understanding of the code and the problem domain;
• We help people (like you!) get started by opening up a laptop at our weekly meetups.

The first of these seems obvious now: when we add issues (an idea for a new feature, or maybe a bugfix) to our github repos, if we think they’re candidates for manageable, isolated work, we tag them with the label: Suitable for volunteers (like this).

Often these turn out to be “nice-to-haves” that one of our full-time devs can’t be pulled off more pressing problems to add just now. (Case in point: Andrew added a date-picker to the FixMyStreet admin stats page, and three of our own staff had stumbled upon and applauded the difference it had made within a week of it going live).

It means it’s much easier for you to get involved, because often it’s a little, isolated piece of code. And it’s much more manageable for us, because the change you’ll be submitting is also isolated.

So if you’re looking for something to tackle, pick one of those issues, and let us know (just to check nobody else has baggsied it already). Fork the repo, cut the code, write the tests, submit a pull request!

But wait — if that last paragraph made you gulp, here’s the second thing we do: meetups. Of course, this is less helpful if you can’t make it to London on Wednesdays, but the concept is sound. Put simply, if there is a barrier to entry to diving in, and if one-on-one time with a dev, and some pizza, is what it takes to overcome that, it’s time well spent for you to come and see us.

Not 100% confident with git? Not sure when db/schema.sql gets used or how we like to handle migrations? No problem: we’re happy to guide you.

You?

If this has struck a chord with you — you’d love to be an Open Source contributor one day, and you think mySociety projects make the world a better place — perhaps you should take a poke in our repos, or come along to a meetup. Start small, but do start.

Oh, and Andrew and Andy — thanks guys 😉

More about volunteering for mySociety

Photo by Matt Katzenberger (CC)

We’re good friends with the people at Mozilla. Every Wednesday, they welcome us into their London Moz space for our weekly meet-ups. They are champions of empowering possibilities of the web through Open Source software (a world we’re part of too). And they’re all so smart and lovely. So of course we’d been looking forward to this year’s Mozilla Festival for some time.

We had a table at the “Science Fair” on Friday night, where we literally had buckets of sweets (OK, they were little plastic buckets). Tom, our director, and Dave, from our international team, talked about mySociety’s work with anyone who came close. Perhaps people were drawn in by those sweets, or the FixMyStreet demo on the monitor, or even the (new!) stickers we had to give away… but regardless of the lure, we think they all learned a little bit more about how our platforms help empower people’s civic lives: from something as simple as reporting a flickering streetlight, to holding a public authority to account, to monitoring a whole parliament. (That’s FixMyStreet, Alaveteli, and Pombola, if you were wondering).

The Mozilla Festival’s venue was, once again, London’s astonishing Ravensbourne, right next to the O2 Millenium Dome. The setting magnifies the wonder of the event. Those big round windows make it feel like being in a spaceship made of Swiss cheese. The place is so open, and so vertical, that the activity and enthusiasm doesn’t just spread out, it spreads up. There is making and teaching, learning and sharing, going on across nine floors, and it’s easy to drift up and down from one themed space to another.

We met old friends. We got to hang out some more with our Chilean brothers-in-code from Ciudadano Inteligente, and the excellent Gaba from Uruguay’s DATA, together with the good people from the OKFN. We made lots of new friends too. And all this didn’t just happen at the sessions. A lot of serendipitous encounters took place by the Alchemy coffee stations. Or on the stairs (khun Toy and khun Hui — hi!). Or in the Alphabet City party venue, afterwards.

So a big “thank you” to that Fiery Fox, and an enthusiastic high five (yes, there was an unLondonlike amount of enthusiasm on show — possibly because quite a few of the attendees were over from the USA — which it is impossible not to be caught up by) to all the people we met at the event. Dave grinned his way through a wonderful Scratch tutorial from Code Club, met a whole array of cool people, got answers to some nerdy coding questions, and learnt about the awesome Hive learning networks… and lots more things besides. That already describes a great weekend. But beyond that, we hope we might see a few new mySociety-powered sites spring up elsewhere in the world due to sparks that were sparked at mozfest last weekend.

The Open Democracy Advice Centre (ODAC) in South Africa will be using mySociety’s Alaveteli software in their latest project – and, with a bit of match-making from mySociety, the preparation period has been rigorous.

Alaveteli is our open source Freedom of Information platform. It underlies our own UK-based WhatDoTheyKnow, and right-to-know sites around the world. Alaveteli sites make it easy for citizens to ask questions of those bodies who operate under Freedom of Information law and, significantly, they automatically publish all responses.

Before any coding or implementation began, we got ODAC together with the “Governance Collaboratory”, an initiative from the d.school in Stanford University that seeks to apply the “design thinking” approach to projects that intend to make government more open, more effective, and more accountable. We’ve observed quite a few Alaveteli installs, but while we’re always on hand to offer support and answer development queries, we’ve never prepared the ground quite like this.

Gabriella Razzano of ODAC welcomed Jeremy Weinstein and Jenny Stefanotti, both from the d.school, to Cape Town for an intensive few days of assessing how the design thinking approach could shape the project. Two staff from mySociety also went along — Paul (our Head of International Projects) and Dave (one of our developers) — because we’re keen to understand how the d.school’s approach might improve the way we go about building our new projects.

Now, at mySociety we already know a thing or two about building civic systems that engage with the public, because we have considerable experience in the field. We are expert at combining user experience and current tech to create simple, usable interfaces. We conduct usability tests, we apply A/B testing, and we think hard about what our analytics tell us. But actually much of this is reactive, iterative design: it’s being applied after the core product has already been built.

Design thinking challenges this approach by suggesting that the user on which initial designs are often based is purely imaginary. As a result, the site inevitably includes the assumptions and prejudices of its creators. This won’t necessarily lead to a bad design — especially if the creators are benign and experienced — but it must fail, by definition, to account for the unexpected things that may motivate or concern actual users. The design thinking process attempts to change this by approaching the initial problem in a prescribed way and following a process that isolates genuine, existing requirements. This includes, in design thinking terms, processing the initial interviews into empathy maps from which requirements emerge, and which themselves become features that are rapidly prototyped in isolation from other parts of the system.

This is uncomfortable for those of us used to building loose iterations from the bottom up and refining them later. It means introducing empathy and rapid, offline prototyping much earlier in the process than we’d normally expect. Certainly in the commercial world it’s common for a company to prototype against their target consumers early on. But for civic projects such as mySociety’s, it’s often much harder to identify who the users will be, for the impressive yet overwhelming reason that often we are building our platforms for everybody. This can lead to generalisations which may miss specific issues that could make a huge difference to some users.

The d.school advocates a “learning by doing” way of teaching, so the days we spent in Cape Town were a busy mix of practice as well as theory. We interviewed people who had a variety of reasons to want to make Freedom of Information requests, including an activist who’s already used South Africa’s Freedom of Information legislation to make requests regarding housing projects, the head of a rape crisis centre, and law students who may well become a nation’s most empowered activists. From these interviews we isolated specific needs, which at this stage were nearly all unconnected to any digital or web requirement. Jeremy and Jenny then led us through the process of rapid, analogue prototyping intended to address those needs.

Inevitably we could only scratch the surface in the few days we had available, but we hope ODAC will be able to apply the process to the development of their project, just as we aim to use it to benefit the work on ours.

Image credit: Procavia capensis (Rock-dwelling Hyrax or Dassie) by Arthur Chapman, released under CC BY-NC-SA on Flickr.

They tell visitors that dassies such as these live atop Table Mountain. We went up there and saw none. Similarly, Freedom of Information requests exist in South Africa under the Promotion of Access to Information Act 2000 (PAIA), but most people have never seen one — fewer than 200 PAIA requests were made nationally in 2012. This tenuous comparison allows us to illustrate the blog post with a cute picture of fuzzy mammals.

This is the third of our recent series of Open311 blog posts: we started by explaining why we think Open311 is a good idea, and then we described in a non-techie way how Open311 works. In this post we’ll introduce our proposed extension to Open311, and show how we use it in FixMyStreet.

The crux of our suggested improvement is this: normal people want to know what has happened to their problem, and Open311 currently isn’t good enough at telling them whether or not it has been dealt with. To be more specific, our additions are all about reports’ status change, by which we mean something like this:

That’s robot-311 from the previous post, if you’ve dropped in here without reading the previous posts. Once again we’re blurring the distinction between client and user (the girl you’ll see below) a little, to make things simpler to follow.

Create→send→fix→update

Every month in the UK, thousands of problems are reported on www.fixmystreet.com and, moments later, sent on to the councils who will fix them. Here’s what happens with a problem report for something like a pothole or a flickering streetlight:

1. You create the report on FixMyStreet.
2. FixMyStreet sends that report to the right department at the right council.
3. That body puts it into its own back-end system.
4. Later, when the council fixes the problem, FixMyStreet is updated, and everyone knows it’s fixed.

On the face of it, you might think we need only care about 1 and 2. But really, FixMyStreet isn’t just about dispatching reports, it’s about helping to get things like potholes actually fixed. And neither citizens nor local governments benefit if work gets done but nobody finds out about it – which is part 4 on the list above.

What do we mean by “status change”?

The example at the top of the page shows the robot effectively changing a problem’s status to “fixed”.

Actually, statuses can be simple, such as either OPEN or CLOSED, or more detailed, such as “under investigation”, “crew has been dispatched”, “fixed”, and so on. But since we’re only concerned here with the status changing, that specific vocabulary deployed doesn’t really matter – it can be anything.

In situations where FixMyStreet is not integrated with council systems (i.e we just send email problem reports) FixMyStreet problems still frequently get marked as fixed, because anyone can change the status of a report just by visiting the page and clicking the button.  Obviously, though, we prefer to have FixMyStreet directly connected to the local government back-end databases, so that news of a fixed report can be automatically bubbled from the back-office up into FixMyStreet and out onto the net.

And here’s where the problem lies: Open311 doesn’t quite support this business of getting problem updates from the back office out to the public. So first, we’ll show you how it can be done today, using Open311, and we’ll explain why this isn’t a good option. Then we’ll show our preferred solution, which we’ve proposed as an extension.

Looking at everything just to spot one change (bad)

One way to notice if any problems’ statuses have changed is to use Open311 to ask for every single service request, and see if any of them have a different status since the last time you checked.

Obviously there are some problems with this. Even though Open311 lets you ask for quite specific service requests, you have to ask for all of them, because by definition you don’t know which ones might have changed. Remember, too, that problems can potentially change status more than once, so just because it’s been marked as CLOSED once doesn’t mean it won’t become OPEN again later. This exchange is very wasteful, very slow and ultimately (with enough reports) may become de facto impossible.

Asking for just the changes (good)

So here’s a better way of doing it. We’ve actually been doing this for some months, and now seems the time to share.

The client asks the server for just the updates on a regular basis, so any requests that have recently changed get updated on FixMyStreet automatically, usually just a few minutes later.

Or, more practically for keeping FixMyStreet up to date:

This is handled by our extension to Open311, GET Service Request Updates. There’s also an optional equivalent call for putting updates into the server (POST Service Request Update), which would apply if the client changed the status after the service request had been submitted.

Note that the server identifies the problem with its own reference (that is, 981276 is the council’s reference, not a FixMyStreet ID, for example). This is important because not all these requests necessarily came from this particular client. Remember that all service requests are available through the Open311 GET Service Requests call anyway (as shown above). So the server doesn’t send each service request back in its entirety: just its ID, the new status, when it changed, and a brief description.

In practice the client wouldn’t usually ask for “today”. In fact, we typically send a request asking for any updates in the last 15 minutes, and then at the end of the day ask for the whole day’s updates, just to check none were missed.

The technical bit

From a client’s point of view, this is simply an extra call like others in the Open311 API. So it’s just a request over HTTP(S) for XML (or JSON, if required).

We deliberately make the client poll the server for updates and pull them in, rather than expecting the server to push updates out. This frees the server from any obligation to track which clients (for there may be more than just one) care about which updates. The requests themselves are sent with unique IDs, allocated by the server, so the client can dismiss duplicates. It’s also robust in the event of connection failures, so if there are timeouts or retry logic, that’s for the clients to worry about, not the server. Basically, this is all to make it as light on the server as possible: the only real issue is that it must be able to provide a list of updates. This usually means adding a trigger to the database, so that when a problem’s status is updated a record of that update is automatically created. It’s the table of those “service request update” records that incoming requests are really querying.

We have published our own recommendation of this mechanism, which FixMyStreet already implements, alongside the FixMyStreet codebase.

Is that it?

Yup, that’s it.

This extension is in addition to the Open311 specification — it doesn’t break existing implementations in any way. Obviously this means FixMyStreet’s Open311 implementation is compatible with existing Open311 servers. But we hope that others working on Open311 systems will consider our extension so that clients are kept better informed of the status of the problems being fixed.

Why are statuses so important that it is worth extending the Open311 spec?

mySociety didn’t originally build FixMyStreet because we wanted to get potholes fixed. We built it because we wanted nervous, politically inexperienced people to know what it felt like to ask the government to do something, and to be successful at that. We wanted to give people the buzz of feeling like they have a bit of power in this world, even if the most tiny amount.

If the government fixes a problem and the citizen doesn’t find out it’s a double loss. The citizen becomes disillusioned and weakened, and the government doesn’t get the credit it is due. Everyone loses. We think that Open311 is a key mechanism for making large numbers of people feel that the government does respond to their needs. It just needs a bit of an upgrade to do it better. We hope very much that the wider community tests and endorses our extensions, and it can be folded in to the next official version of the Open311 standard.

Find out more about FixMyStreet for Councils

In the previous blog post we explained why we think Open311 is a good idea. In this post we’ll explain what it actually does.

Open311 is very simple, but because it’s fundamentally a technical thing it’s usually explained from a technical point of view. So this post describes what Open311 does without the nerdy language (but with some nerdy references for good measure). At the end there’s a round-up of the terms so you can see how it fits in with the actual specification.

We’re using an unusual example here — a blue cat stuck up a tree — to show how applicable Open311 is to a wide range of problems. Or, to put it another way, this is not just about potholes.

So… someone has a problem they want to report (for this discussion, she’s using a service like FixMyStreet).

There’s one place where that report needs to be sent (in the UK, that’s your council). That administrative body (the council) almost certainly has a database full of problems which only their staff can access.

In this example, FixMyStreet is an Open311 client and the council is an Open311 server. The server is available over HTTP(S), so the client can access it, and the server itself connects to the council’s database. In reality it’s a little bit more complicated than that (for now we’ll ignore clients that implement only part of Open311, multiple servers, and decent security around these connections), but that is the gist of it.

Although it’s not technically correct to confuse the client with the user, or the server with the council, it makes things a lot easier to see it this way, so we’ll use those terms throughout.

Service discovery

To start things off, the client can ask the server: what services do you provide?

Until the client has asked the server what problems it can fix, it can’t sensibly request any of them.

FixMyStreet can use the response it gets from such a service discovery to offer different categories to people reporting problems. We actually put them into the drop-down menu that appears on the report-a-problem page.

In the Open311 API, this is handled by GET Service List. Each service has its own service_code which the client must use when requesting it. Note that these services and their codes are decided by the server; they are not defined by the Open311 specification. This means that service discovery can easily fit around whatever services the council already offers. The list of services can (and does) vary widely from one council to the next.

Service definitions

Some services require specific information when they are requested. For example, it might be important to know how deep a pothole is, but it’s not relevant for a streetlight repair.

In the Open311 API, this is handled by the GET Service Definition method. It’s not necessary for a simple Open311 implementation. In fact, it only makes sense if the service discovery explicitly told the client to ask about the extra details, which the server does by adding metadata="true" to its response for a given service.

Requesting a service

This is where it gets useful. The client can request a service: this really means they can report a problem to the server for the body to deal with. Some submissions can be automatically rejected:

If the report is in good order, it will be accepted into the system. Open311 insists that every problem has a location. In practice this is usually the exact position, coordinates on planet Earth, of the pin that the reporter placed on the map in the client application (in this case FixMyStreet.com).

In the Open311 API, this is handled by POST Service Request. You need an API key to do this, which simply means the server needs to know which client this is. Sometimes it makes sense for the server to have additional security such as IP address restriction, and login criteria that’s handled by the machines (not the user).

Listing known requests

The server doesn’t keep its reports secret: if asked, it will list them out. The client can ask for a specific report (using the ID that the server gave when the report was submitted, for example) or for a range of dates.

In the Open311 API this is handled by GET Service Request(s). The client can indicate which requests should be listed by specifying the required service request id, service code, start date, end date or status.

Does Open311 work?

Oh yes. On the Open311 website, you can see the growing list of places, organisations, and suppliers who are using it.

The technical bit

In a nutshell: Open311 responds to HTTP requests with XML data (and JSON, if it’s wanted). There’s no messing around with SOAP and failures are reported as the HTTP status code with details provided in the content body.

You can see the specification for Open311 (GeoReport v2). It doesn’t feature blue cats, but if you look at the XML examples you’ll be able to recognise the same interaction described here. And remember the specification is an open standard, which means anyone can (and, we think, should) implement it when connecting a client and server in order to request civic services.

Coming next…

In the next blog post we’ll look at how FixMyStreet uses Open311 to integrate with local council systems, and explain why we’re proposing, and utilising, some additions to the Open311 specification.

Find out more about FixMyStreet for Councils

Illustrated especially for us by René Carbonell.

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 select tag) — 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.