This is easier than hunting through the council’s website as that information is not grouped by locality, so you have to hunt through the entire borough’s applications to find ones near you.

Planning Alerts works for many boroughs, currently including Sutton and Croydon, but not Merton.

If you use an RSS reader, this information is also available as an RSS feed.

By filling out a form on TfL’s website or phoning their call centre, you can let them know about a street problem that needs to be fixed. The hope and expectation is that they’ll do so with appropriate haste and keep you informed as they do so.

One of its fundamental flaws is that if the reporter wants to track the progress of the fault, they must keep returning to the website and enter the lengthy fault code to see its status. If someone has gone to the trouble of reporting a fault, it’s likely that they care about it getting fixed. Providing a simple mechanism for keeping the reporter notified without making them do any extra work is the least the system should do as a “reward” for the reporter’s efforts. As Lynne Truss would say, “Why am I the One Doing This?”

I can think of four ways to notify the reporter when a fault’s status changes; two that are obvious, two less so.

1. Send emails

When reporting a fault, the system already asks for a full name, address, phone number and email address. A tick box that gives permission to send email notifications would be a good start. Each message could come with a unique unsubscribe link.

2. Send text messages

Likewise, a tick box that gives permission to send text message updates to a mobile phone. The downside to this is that it’d be hard to make an easy unsubscribe mechanism. At best, the reporter would have to reply to the text, but it’d cost them the price of sending a message. From TfL‘s end, the cost of sending text message notifications would be trivial against the entire cost of fixing a fault, but a mechanism for validating the reporter’s mobile number would be needed to prevent people maliciously or accidentally signing up other people’s numbers. This is a poor solution.

3. Create web pages

A fault’s status isn’t private information. Why not put updates on web pages that everyone can view, with an overall list of outstanding and recently closed faults, and each individual fault having its own page (and therefore a URL) that the reporter can check at their leisure? Then, keeping up to date would be as easy as sending the reporter a message like:

Thanks for reporting this fault. If you want to check its progress, visit:

http://streetfaults.tfl.gov.uk/faults/123456789

Someone who was keen could then bookmark that page and visit it as often as they wished.

4. Create an RSS feed for each fault

The last idea is an extension of the same principle: it’s public data so just make it available to anyone that cares to look. Give each fault its own RSS feed and let the reporter subscribe to the feed if they wish. RSS has none of the spam, privacy and virus problems of email. People can keep regularly updated without any extra effort. RSS has none of the complex usability problems with unsubscribe mechanisms. Tools to read and manage feeds are widespread and will soon be available in all mainstream web browsers. It just works.

The Sutton Liberal Democrats’ manifesto for the council elections on 4th May says that if returned to office,

We intend to look at making use of new technology to allow residents to use their mobile phones to send information and photographs about street scene problems directly to the appropriate council offices. (page 7)

Let’s hope that if they do it, they choose a system that gives people good feedback and encourages them to get involved in future.