Discussing a planning application - note how the location of the site has been drawn out

About three weeks ago we opened up Cyclescape to a test group, Cambridge. Their Committee have been using the system instead of the e-mail list they used to use.

On the right, you can see a planning application being discussed, with the location of the site marked out, and a list of the discussions.

In this three-week period there have been:

• 78 issues (problem reports and things to work on)
• 108 discussion threads (discussions connected to the issues)
• 789 messages (individual replies within the threads)
• 61 user locations (areas that people have set to be informed about changes in)
• 22 campaigning deadlines and dates
• 34 library items
• 151 pieces of feedback about the system, some of which are about tiny fixes, others about more substantial issues (most of which we know about)

Although there are unfinished areas (which have caused some user confusion) and some missing features, the testing has given us plenty of useful feedback, which we’re working through before we open up the system for wider use.

Organising a group ride

How are people using the system?

My locations

We’ve seen discussions on, for instance:

• Various local planning applications – on which it’s been useful to see the location on the map
• Smaller issues around a city
• The Times “Cities Fit For Cycling” campaign
• Administrative discussions (organising day-to-day things)
• Organisation of a cycle ride – which again the geographical location provides useful context
• Addition of some items to the resource ‘library’ which will be useful for future discussions

Items from the library (here 20mph guidance) have been automatically matched, and a user has added some to the discussion

There are signs that the ability for people to subscribe only to things they’re interested in, based on geographical location(s), should work well – so that people can be involved in things they care about – but not overwhelmed with issues.

We’ve seen some confusion over the difference between ‘issues’ (problems) and ‘threads’ (discussions of those issues), which further interface work will address.

Key themes

Some of the key themes, on things we need to fix, are:

• The need to reorganise the various listings screens, which are currently not in their final positions. This is an area we knew would need quite a bit of iteration work.
• Making sure that maps are viewable in a few places where they’re currently omitted.
• Reducing the ‘friction’ between issues and threads. We want to encourage people to locate issues geographically when possible. To some extent this will be improved naturally as the listing screens get reorganised and as we fix up parts of the design that were not finished when we went live.

• Various layout fixes to add some more polish and improve usability.

Some of the areas are quite Cambridge-specific, partly dealing with the unusually heavy level of correspondence and involvement that the Cambridge group has. Others, as shown above are more generic.

• Further work on e-mail integration. Many areas work, but some kinds of notifications can’t be replied to by e-mail yet, and it’s not yet possible to start a thread by e-mail.
• Very active campaigners have asked for an ‘opt-in to everything by default’ setting, so that they get told about everything, and can opt-out when not interested (rather than merely getting told about something new in their area). This would save them having to subscribe to each issue or discussion thread as it comes in.
• How to deal best with city-wide issues, and the question of a neighbouring Local Authority (South Cambs) whose issues also particularly affect the area in terms of different planning policy.
• There have also been some compatibility problems with a certain web browser... Internet Explorer!

An example problem that we need to fix - city-wide issues are overlapping and obscuring others, so a fundamentally different approach for city-wide issues might be needed, e.g. a separate listing screen or maybe a button to show these:

Usability testing

We’ve also done some individual usability testing, which has thrown up 35 actionable issues. Around half of these were things known about and planned to be fixed, but the others provided useful insight.

Next steps

We’re busy working on fixes for the above, as well as creating more guidance on installing the system for coders who want to get involved. Technical people can watch progress in our Github repository.

Stay tuned to the blog in the coming month as we talk about the latest changes and showcase the system’s features. We’re working as fast as we can, within the available funds, to get the system ready for wider use!

We've created a new Frequently-asked questions (FAQ) page about Cyclescape.

Have a read!

Here are some of the designs for three of the main areas of the site: reporting an issue (problem), viewing it, and discussing it.

At present there are two parallel streams of work going on: feature coding (by our coding team of Andy and Andrew), and design work (by the designers we've appointed, Supercool). We’ll be talking more about how this design work is being developed in another blog post soon.

1. Report an issue

We all know that there are many infrastructure problems in the UK that act as barriers to getting more people cycling, or improving the safety and convenience of existing cyclists. Each of these we call an issue. Examples are:

• Lack of cycle parking at a destination (i.e. a single point location)
• The absence of a cut-through route that would shorten journeys (which you could draw on a map as a line)
• A large hostile roundabout that has no cycle provision (basically a whole area!)

Cyclists will be encouraged to use the site to report these problems, locating them on a map.

When adding an issue, you can show it on the map as a single point, a line or an area. You can also add some tags (keywords) that help categorise it. And if you have a photo, you can add that too.

2. The issue page – showing a reported issue

Each reported issue has a page of its own. These issue pages are public. They describe the reported problem, showing its position on the map, as well as other details.

Note how the different types of things – areas, routes and points are shown.

On the right hand side is a list of discussion threads that a group is having about this issue.

3. Threads: individual discussions of a particular issue

As shown above on the issue page, for each issue there may be one or more threads of discussion.

For instance, getting our hostile roundabout fixed will require a lot of discussion. There could be discussions on:

• alternative routes that could be created;
• how cycle lanes or cycle tracks could be added;
• how a similar problem has been solved in another area;
• potential funding sources that could be tapped into;
• what the planning office at the Council has been saying about the area; and 
• a proposed solution that someone has come up with.

These discussions are specific to each cycling group using the system, and can be public or kept private to the group - we know that different groups work in different ways, as results from our survey are clearly showing.

Below, we show the page for one such discussion.

We’ll cover the thread page in more detail in a future blog post, but the key things are that it shows us a clear title, a description of the issue, the location, recommended resources that might be useful to bring into the discussion, replies to the discussion, your prioritisation of the issue, and a list of who is following it.

The button in the top-right lets you subscribe to an issue, so that you only get notified about things you actually care about, rather than every discussion.

If you use e-mail a lot, you can opt to receive updates by e-mail as well - again, another thing that our survey has shown is likely to be needed.

Here's a quick report prior to the downing of tools for the Christmas holiday.

Since our last report two weeks ago, the following items have been implemented:

• Library notes and document upload implemented.
• Thread messages can be replied to by e-mail.
• A user can set the locations and areas they are interested in, such as their home or route to work.
• Tagging of issues, threads, and library items is possible.
• Users can submit feedback from the site.
• Issues can be voted up and down to indicate popularity.
• Users can prioritise individual threads (each of which is a discussion on an issue, and an issue may have many threads).

Those with technical interests can see the great progress our developers Andy and Andrew are making, in our codebase, which is open source.

Our developers have documented bugs and contributed patches to other open source projects that we use. This includes submitting a crash bug report to the core Ruby language implementors (now fixed), a minor patch accepted by the Phusion Passenger team whose software powers many Rails deployments, and several bugs with fixes for the Chef deployment system.

New design work from Supercool has continued to come in, and we are plugging this into the code as fast as we can - though there's lots of other things to sort out too!

Here's some of the design latest work, though we are continuing to iterate work on the design and its implementation:

These are the latest design templates from Supercool that we’re now busily hooking into the code!

Report an issue page:

Thread discussion page:

Issue page – each thread of discussion on issue:

And an icon set under development for the map markers:

We’re approaching our beta phase now, with testing of a closed early beta starting today by members of one of our stakeholder groups.

Our designers, Supercool, have been working hard on the overall design and page templates, which we’re merging into the code this week.

Thanks to the hard work of our developers Andy and Andrew, core functionality is pretty-much all in place now, and it is being hooked into the design work that is now flooding in. (Some of the more ancilliary areas, such as importing of existing Photomap data, haven’t been started yet so we can get testing going more quickly.)

They've also been adding a lot of tests and other deployment infrastructure which ensures that the system is robust and easy to deploy.

Our timescale has slipped about one month, due to the amount of functionality going in and some questions on some of the assumptions we made earlier on (see below), but progress remains good. More technically-minded people can follow our code repository to see changes each day.

What’s in place now?

Lots! Most of the core concepts and functionality is now in place:

• Logins and user profile
• Users and group management
• Issue submission (though not photos yet)
• Core geographical basis (limitation of issues to specified areas)
• Issues
• Listing of threads to issues
• Point/line/polygon basis of issues
• Thread discussions
• Deadlines
• Multiple message types (e.g. comment/photo/link/deadline/library)
• Subscription
• Subscription by e-mail
• Replies by e-mail (mail-to-web gateway)
• Resource library (though not all types done)
• User location management (e.g. ‘my areas’)
• Dashboard
• Listing of issues by ‘my areas’, by subscription, by involvement
• Privacy (public/private) for groups and per-message
• Tagging
• Thread discussion context (group-based, ungrouped)
• System feedback

These will need tweaking during the integration of the design templates and the results of testing.

Innovation: testing assumptions

What the early beta testing programme, and work until Christmas, will deal with, are testing and refining the key areas of innovation.

There have been interesting debates amongst the development team which has challenged some of the assumptions in the spec. Some of the differences have boiled down to how much users want to be involved with campaigning issues. We've resolved this into three general levels of involvement:

• The light user, who wants to browse discussions, and perhaps is only interested in something that directly affects them
• The involved user, who perhaps has certain specialist knowledge (about their local area or particular technical knowledge on certain infrastructure themes)
• The super-campaigner, who is perhaps a Committee member and wants to view and be able to comment on almost everything

For instance, the spec assumed that people would be automatically subscribed to everything in their area, meaning that if their main profile settings enabled e-mail delivery they would get a huge amount of stuff. That would definitely suit the super-campaigner profile, but for the light user that would be information overload. So we are considering more fine-grained, but still user-friendly, ways in which ‘subscription’ as a concept is defined.

The other big area of discussion has been about the group basis and how this conflicts with a user-centric approach. The system has always been intended as a toolkit for campaign groups, not a general UK-wide discussion forum. The social context here is that cycle campaign groups act as a corporate voice for cycling issues in an area, and people working together with a group structure and norms helps the long-term basis of campaigning.

But people are sometimes members of more than one group (as the spec recognises) and different groups want different kinds of privacy in their discussions. By contrast, a user just wants to see things they’re interested in, whichever group is discussing them. So in the coming weeks we’ll be working through exactly how the interface can resolve this tension between user-centric and group-centric perspectives.

The three areas that we’re working through are:

• What subscription means exactly (just a listing, or actively seeing discussions?)
• E-mail subscriptions (auto-subscription, receive replies, and how threads get started)
• Group basis (how this affects the user interface and subdomain URLs, and how people can be sure who they’re talking to).

Thankfully, we’re using Ruby on Rails, which is designed to assist with agile development issues like these!

Design screenshots

Stay tuned for news on design screenshots..

Last week we reached the alpha phase of our project.

An alpha (which comes before a 'beta') is the stage of development where the fundamental concepts and much of the underlying structures of the system are in place, but the interface isn't ready and many features aren't in place or finished.

In the coming weeks as we move to the beta, we'll have screenshots and more details.

We've submitted our Alpha progress report which describes process in more detail. There are a few screenshots, but they should not be taken as in any way indicative of the final system - they just have some basic layout to enable code testing.

• Alpha progress report
• Latest version of the spec (v5, v6 changes will be merged in shortly)