Embed Size (px)
Citation preview
1
Cycle campaign toolkit: specification – from CycleStreets, funded by GeoVation
Version 5, 19th September 2011
This document describes our plan to improve the effectiveness of cycling campaign groups
by the creation of a user-friendly, web-based toolkit that will enable groups and their
members to gather, discuss and make best use of dispersed geographical knowledge about
the problems faced by cyclists.
Further comments on this specification are warmly welcomed on an ongoing basis.
The specification below contains a few sections in yellow which are subject to continuing
discussion with particular groups. They will be cleared up during the code design process,
i.e. before coding starts.
This is a full specification, that includes all accepted ideas that have been identified. It is not
anticipated that the funding will cover every section, as only 16 weeks of development time
is fundable. The priorities for implementation are set out in the final section.
Section A: Background ......................................................................................................... 4
1. Context: The state of cycling in the UK ............................................................................................ 4
2. Who will be creating the toolkit? ...................................................................................................... 5
3. Funding of the toolkit project .......................................................................................................... 5
4. Cycling community support ............................................................................................................. 6
5. Project timescales ........................................................................................................................... 6
6. Name of the toolkit ......................................................................................................................... 7
7. Research aspect .............................................................................................................................. 7
8. A geographical basis ....................................................................................................................... 7
9. Comparison with other problem-reporting websites ........................................................................ 8
10. Outcomes ....................................................................................................................................... 9
11. Awareness of the toolkit .................................................................................................................. 9
Section B: Examples of how the toolkit will help ................................................................. 10
12. Example 1: Solving cycle parking shortages ................................................................................... 10
13. Example 2: Allowing two-way cycling in a one-way street ............................................................. 11
Section C: Overview of the toolkit ...................................................................................... 14
14. Overview of the toolkit .................................................................................................................. 14
15. Reporting a problem: a section open to anyone ............................................................................. 14
16. Managing and solving problems: for campaigners and groups ....................................................... 17
17. A one-stop-shop for campaigning ................................................................................................ 18
Section D: Group basis ...................................................................................................... 19
2
18. Respecting groups‟ autonomy ....................................................................................................... 19
19. Presentation of available groups upon registration ........................................................................ 20
20. Group identity ............................................................................................................................... 20
21. Website addresses for each group ................................................................................................. 21
22. Management of a group ................................................................................................................ 22
23. Who can take part in a group‟s discussions? .................................................................................. 23
24. Filespace limits ............................................................................................................................. 23
Section E: Users and registration ....................................................................................... 25
25. Registration and profile pages ....................................................................................................... 25
26. Types of users .............................................................................................................................. 27
27. Auto-invitation of users ................................................................................................................ 27
28. Status bar, at the top of the screen ................................................................................................ 28
29. Help and documentation ............................................................................................................... 29
Section F: Dealing with issues: campaigning ...................................................................... 30
30. Getting an overview of campaigning issues ................................................................................... 30
31. „Threads‟: core concept for discussing and managing issues ......................................................... 30
32. What threads (issues) does a person see when they log in? ............................................................ 31
33. How can threads (the issues) be accessed? .................................................................................... 32
34. Flagging of important issues by Committee members ................................................................... 32
35. Summary of information shown at the top of each thread .............................................................. 33
36. Types of replies in a thread: advancing the discussion ................................................................... 34
37. Using e-mail instead of a forum view (mail-to-web gateway) ........................................................ 38
38. Viewing and managing threads ..................................................................................................... 40
39. Committee-only threads ............................................................................................................... 41
40. Thread prioritisation ..................................................................................................................... 41
41. Search facility ................................................................................................................................ 42
42. Deadline management .................................................................................................................. 42
43. Info blocks .................................................................................................................................... 43
44. Library .......................................................................................................................................... 45
45. Galleries of best practice examples ............................................................................................... 45
46. Document management ................................................................................................................ 45
47. Thread branching and splitting ..................................................................................................... 45
48. Thread grouping ........................................................................................................................... 46
49. Polls .............................................................................................................................................. 46
50. Petitions ........................................................................................................................................ 47
51. Dealing with disputes .................................................................................................................... 48
Section G: Integrating different source of data ................................................................... 50
52. Linking with a group‟s public e-mail address ................................................................................ 50
53. Planning applications .................................................................................................................... 50
54. Importing data .............................................................................................................................. 51
55. External data layers ....................................................................................................................... 51
3
Section H: Sharing information with others ........................................................................ 52
56. Sharing best practice between groups ........................................................................................... 52
57. Engagement with Local Authorities ................................................................................................ 52
58. Publishing ..................................................................................................................................... 53
59. Exporting data .............................................................................................................................. 53
Section I: Event management ............................................................................................. 55
60. Event management ........................................................................................................................ 55
61. Deadline management .................................................................................................................. 55
Section J: Privacy and security ............................................................................................ 56
62. Privacy .......................................................................................................................................... 56
63. Security ......................................................................................................................................... 56
Section K: Ongoing management of the toolkit .................................................................. 58
64. Ongoing management of the toolkit by CycleStreets ...................................................................... 58
65. Costs ............................................................................................................................................ 58
Section L: Technical matters .............................................................................................. 59
66. Data sources ................................................................................................................................. 59
67. Browser compatibility .................................................................................................................... 59
68. Relationship with the CycleStreets Photomap API ........................................................................... 60
69. Developer API and source code ..................................................................................................... 60
Section M: Priorities for implementation ............................................................................ 61
70. The specification: priorities for implementation ............................................................................. 61
71. Potential expansion ....................................................................................................................... 62
4
Section A: Background
1. Context: The state of cycling in the UK
Cycling has great potential for solving many of the transport problems we face. It is an
efficient form of transport, requiring little space. It is environmentally-sound and improves
health, and offers an inexpensive transport accessible to a wide variety of people.
However, cycling rates are very low in the UK by continental standards, with few areas
reaching into double-figure percentages, and none approaching the 40% levels seen in some
parts of the Netherlands for instance.
The barriers preventing higher cycling rates are several. As well as cultural factors, the
paucity and low quality of cycle-friendly infrastructure is a key problem. Cyclists often have
no option but to use congested roads, shared with fast and hostile traffic. The legal
environment often fails to protect cyclists and pedestrians. Furthermore, cycle theft is rife,
often due to lack of secure cycle parking.
A range of government, commercial and third-sector initiatives exist to campaign on these
issues and effect change on the ground.
Key amongst these is the large number of cycle campaign groups around the UK and
Ireland, who work hard to improve conditions for cycling by a variety of campaigning means.
Well over 100 groups exist, as part of Cyclenation, the CTC and London Cycling Campaign
and the new Cycling Embassy of GB.
Local cycle campaign groups often face typical problems experienced by many local
campaigning organisations. As well as having limited funding and being subject to
shortages in volunteer time, they lack IT knowledge which could help enormously in
managing information about the local cycle network and its problems.
These groups have varied relationships with Local Authorities. Some work in partnership
with officers in a productive yet still independent way, supporting (and actively promoting)
council initiatives when these are in line with policy, and working through stakeholder
meetings to encourage good practice, but campaigning – in a constructive manner – against
decisions which are seen to affect cyclists negatively. Other groups have a more negative
relationship with Local Authorities, for a variety of reasons.
With cutbacks to national budgets, with transport expected to be particularly badly hit, there
will be renewed emphasis by Local Authorities on smaller-scale solutions and resolution of
smaller infrastructure problems rather than „grand schemes‟. As such, better tools for
campaigners to campaign on these more localised issues will be needed in this new funding
environment, as well as ways to encourage partnership working where possible.
The toolkit aims to provide solutions to the above, providing a platform for reporting,
campaigning, discussion and constructive engagement with decision-makers, whilst fully
retaining the autonomy of local groups and their policies.
5
2. Who will be creating the toolkit?
The toolkit is being created by CycleStreets, who run the UK-wide cycle journey planner (at
www.cyclestreets.net), run „for cyclists, by cyclists‟. As well as the cycle journey planner,
which has planned almost a million routes in the UK, the CycleStreets website includes a
Photomap campaigning tool used by cyclists to report problems and good practice, by
locating photographs on a map.
CycleStreets is now set up as a social enterprise, CycleStreets Ltd, run on a not-for-profit
basis for community benefit, with all income generated being invested back into the project.
CycleStreets started as an initiative of Cambridge Cycling Campaign, a local voluntary group
(now a Charity) working for better, safer, and more cycling in and around Cambridge.
Both of the lead developers of CycleStreets are active cycle campaigners in Cambridge and
have links with local groups around the country as well as strong links with the main
umbrella cycling groups mentioned above.
Facilities on the CycleStreets website are modelled around two core ideas: (i) journey
planning from user-specified points (whether arbitrary or based on existing locations), and
(ii) marking of locations on a map for campaigning and utility uses. Combined together
these are providing an increasingly powerful set of tools.
We have long wanted to develop the Photomap side of the system into a more useful set of
tools so that we can fully realise its original vision of being a useful campaigning tool, and
the toolkit aims to do just that.
3. Funding of the toolkit project
CycleStreets proposed the development of a cycle campaigner toolkit to GeoVation, which is
an initiative run by the Ordnance Survey, running challenges to address specific needs
within communities, which may be satisfied in part through the use of geography.
Funding of £150,000 has been awarded to six groups in the latest GeoVation round. This
funding has come from a variety of sources: the Technology Strategy Board, the Department
for Transport and the Engineering and Physical Sciences Research Council.
CycleStreets‟ proposal for the toolkit was one of the winning bids, and awarded £27,000.
This involved several rounds of preparation and culminated in a Dragon‟s Den –style pitch at
the Ordnance Survey offices in Southampton in May.
This funding will cover the initial development (including design) work, and a reserve of 3
years‟ hosting costs.
More details about GeoVation can be found at http://www.geovation.org.uk/.
6
4. Cycling community support
Support for the bid came from both of the national campaigning organisations and a
number of the most active local groups and others:
Cyclenation, the national federation of cycle campaign groups
CTC, the national cyclists‟ organisation
Cycling Embassy of Great Britain
London Cycling Campaign
Richmond Cycling Campaign
Bristol
Pedals (Nottingham Cycling Campaign)
Dublin Cycling Campaign
Cambridge Cycling Campaign
Spokes (East Kent Cycle Campaign)
Loughborough & District Cycle Users' Campaign
Push Bikes, the Birmingham Cycling Campaign
CycleSheffield
Spokes, the Lothian Cycle Campaign
CPRE
Andy Allan (the creator of OpenCycleMap)
Ideas submitted by several of the groups have been incorporated into this draft
specification.
The quotes of support can be found in the original bid document on the CycleStreets blog at
http://www.cyclestreets.net/blog/2011/02/04/helping-campaigners-campaign/.
5. Project timescales
The key stages of the project are:
1. The creation of a formal specification, by 24 July 2011 – which is the present
document;
2. Development of the toolkit to an „alpha‟ (proof of concept) stage, by 21st October
2011;
3. Development of the site to a „beta‟ (test site) stage, with a beta being made available
to selected groups, by 4th November 2011;
7
4. The public availability of the site to all groups, by 2nd December 2011.
5. Bug-fixing and feature addition finishes on 16th December 2011, and the system
continues to run on an open source team basis.
6. Name of the toolkit
The name of the toolkit, and its domain name, is being consulted on.
The underlying software will have its own name, as described below.
7. Research aspect
Work on the toolkit and the associated community interaction issues is being researched as
part of research by Loughborough University.
This work will help define the assessment of success of the toolkit, e.g. levels of usage.
8. A geographical basis
Geography, and people‟s interaction with it, is at the heart of cycle campaigning. Indeed,
virtually any issue in cycle campaigning involves geospatial information. For instance,
Lack of cycle parking involves the need to improve a large number of
geographically-dispersed places.
Poor quality cycle routes, or lack of them, need people who pass through an area to
know what the problems are and to share this knowledge.
Hostile roads need audits that involve geographical techniques.
Scrutinising planning applications require an understanding of the area and its
spatial context.
This web-based toolkit will enable cycle campaigners to gather, discuss and make best use
of dispersed geographical knowledge within the specific context of local campaign groups.
It will help facilitate their work, enable much simpler information sharing, and provide a
range of tools that make clearer the problems that cyclists face, all in a delegated manner
that respects both geographical boundaries as well as personal privacy.
Bringing together a whole range of geographical data will make cycle campaigning much
more effective. Knowing where planning applications are, or collision hotspots, and clusters
of development issues are but brief examples, expanded on below.
The authors of the proposal are both heavily involved with the campaign work of Cambridge
Cycling Campaign. They have personal experience of dealing with the geographically-
8
dispersed and numerous nature of cycle campaigning objectives, as well as the sensitivities
involved in worth with, or campaigning towards, Local Authorities. They are well aware of
the need for a system which combines principles of issue management, geography and
campaigning. We believe strongly that the tool will see strong uptake from groups around
the country.
9. Comparison with other problem-reporting websites
Although there are a number of websites currently exist which accept submission of point-
source problems, none of them cover the use-case which the toolkit will solve, namely
management and prioritisation of dispersed cases of absent/inadequate infrastructure, and
the ability for cycle campaign groups to manage and prioritise them.
They are:
MySociety‟s FixMyStreet, including its iPhone app. This is really for maintenance
issues of a more general nature (i.e. not just transport) rather than provision of
absent infrastructure.
MySociety‟s recently-released FixMyTransport. This is more focussed on the process
of building a public, high-profile campaign around solving a particular larger issue
such as making a station disabled accessible, or similar issues, rather than trying to
deal with management of the sum of dispersed issues around a city. Also, it mainly
deals with public transport. FixMyTransport mobile also got funding from GeoVation
at the same time.
The CycleStreets website includes a Photomap, which will continue to run as-is. The
Photomap has never had a full backend management system for making use of the
submitted locations.
The CTC‟s FillThatHole, for reporting of potholes, which also has an iPhone app. This
deals with maintenance issues rather than improvement of absent/inadequate
infrastructure.
As can be seen, those excellent initiatives try to solve different problems for different
audiences.
For the avoidance of doubt, the cycle campaigning toolkit is not about maintenance issues
(i.e. which tends not to any political process).
The toolkit is designed to solve cycling problems, rather than other types of problem.
Development effort will not be expended on solving other communities‟ issues, e.g. horses
and walking, though the open source nature of the project is such that the toolkit could
potentially be adapted by those communities for their own needs. It is, however, possible
that cycling groups‟ usage of the toolkit could benefit pedestrian interests as part of
campaigns (e.g. to stop pavement car parking), of course.
9
10. Outcomes
The toolkit aims to have the following outcomes:
Fundamentally, increased resolution of problems on the street/path network and
therefore an improved cycling environment
Improved and better-organised working practices by local groups around the
country through access to a new tool to help them manage the deluge of cycling
problems that they get told about or wish to see resolved
Increased reporting of network deficiencies, i.e. increased involvement of local
people
Increased awareness of problems faced by cyclists
Improved working relationships between campaign groups and Local Authorities (a
common problem)
Increased ability for Local Authorities to justify central government investment
Increased demonstration of partnership working between Local Authorities and local
people
Potentially, consolidation of existing web-based systems, reducing the need for
groups to maintain custom-written and highly-specific systems.
11. Awareness of the toolkit
It is expected that campaign groups will undertake promotion of the toolkit themselves.
Successful usage will naturally breed further usage. It is not expected that the toolkit will be
„advertised‟ as such, as in many respects it is intended as an internal management tool for
groups, albeit one commonly-hosted.
At present cyclists are „online‟ in a variety of different forums and systems and it is hoped
that the toolkit will help unify and standardise the situation.
10
Section B: Examples of how the toolkit will help
12. Example 1: Solving cycle parking shortages
A first brief example, about cycle parking shortages around a city, will help set the scene for
how the toolkit will help.
Secure cycle parking helps reduce theft, provides confidence in cycling, indicates a valuing
of cycling as a real mode of transport, and helps avoid cycles blocking pavements.
Yet a shortage of cycle parking is a problem in many towns and cities around the UK. In
London, LCC has identified this as a key campaigning priority. In Cambridge, the levels of
cycle theft and fly parking are so high that it is seen by the councils as a key infrastructure
priority within a programme of improving cycling. The same applies in other areas, too.
But cycle parking is needed in very many places around each town/city. It is a dispersed and
widespread problem. The process of getting cycle parking installed in public and private
areas involves:
1) Identifying areas where cycle parking is needed
2) Prioritising these areas in terms of desirability
3) Setting up an e-mail list and on-site meetings to discuss proposals
4) Identifying whether each location is under the council‟s control or on private land
5) Making a political case for the principle of secure cycle parking in each location,
sometimes requiring the removal of a few car parking spaces
6) Knowing about the costs involved
7) Persuading the relevant authority (council/landowner) to allocate funds
8) Determination by the Local Authority of the feasibility of locations, both in terms of
land ownership and political feasibility
9) Coming up with good designs that meet best practice and avoid old-fashioned,
insecure cycle stands
10) Community consultation by the Local Authority and determining of objections (e.g.
from local houseowners/businesses)
11) Implementing each location by the Local Authority (getting the contractors out there)
12) Potentially, monitoring usage to make future provision easier to justify.
Each of these stages involves a fair amount of work. Yet these have to be done for every
location.
Many of these stages are things where user-friendly technology could help. For instance:
11
1) Identification of locations can be done by encouraging cyclists and members of the
public to „point and click‟ on a website or click on a mobile phone app (see pictures)
2) Prioritising the areas can be done by members of campaign groups who could „drag
and drop‟ them into a priority order and add notes
3) Costs and design issues can be helped by pulling in best practice from elsewhere in
the UK available. For instance, particular designs of cycle parking are acknowledged
to be best, and there are standard prices available. Making this information available
„on a plate‟ avoids the need to spend time researching it.
4) Making a political case is made easier by demonstrating the sheer volume of
requests and by bringing in off-the-shelf summaries of case studies from elsewhere.
5) Understanding constraints (e.g. land ownership), to avoid wasted campaigning
energy, could be dealt with by inviting the Local Authority officials into the
discussion. If they know that a landowner will simply not permit cycle parking on
their land, it is best to know this early on rather than after campaigning effort has
been expended.
6) We could more easily create resources to present our ideas and achievements
effectively to the public, e.g. listing the locations that have been improved.
In this way, we can cut out a lot of the „hard slog‟ of campaigning. We can delegate
identification of the areas easily. We can avoid the need for spreadsheets and drawing over
maps. We can avoid the need for much research. We can make an effective political case
more quickly. We can work in a productive way with the local council officials and elected
Councillors who actually would commission the work. Lastly, we can easily list the areas that
have been improved.
The toolkit will provide a platform to solve this problem – which is the same problem all
around the UK – effectively and avoid duplication of effort.
13. Example 2: Allowing two-way cycling in a one-way street
A second example, this time from Cambridge, will discuss how a campaign was undertaken
in 2007 to allow legal two-way cycling in what was a key one-way street.
Kingston Street, in Cambridge was a one-way, quiet residential street near the railway
station. Cambridge Cycling Campaign, like other campaign groups, has a policy of opening
up one-way streets to two-way cycling, in order to make cycle journeys quicker (and
thereby more attractive, compared to the car) and safer (because this helps avoids busier
roads). Anyone cycling through Soho in London will similarly know the difficulties that one-
way streets cause for legal cycling.
It became clear that some local Councillors were against the proposal, pushed by residents
who wished to preserve the status quo. In contrast, the cycling campaign took the view that
12
there were objectively no real problems with allowing two-way cycling and that the benefits
to cyclists would be very worthwhile.
A campaign was therefore initiated to change the status of the street. This campaign
involved the following:
1) Setting up an e-mail list to help campaigners discuss the issue and collaborate
2) Assembling a case for the principle of two-way cycling, making clear the problems
one-way streets cause and the benefits that would come from two-way cycling
3) Researching what current national policy exists for two-way cycling
4) Identifying evidence from similar changes elsewhere in Cambridge, including
collecting photographs
5) Running an on-street petition and on the campaign‟s website and asking where
people had cycled from on their journey through the street
6) Plotting the origins of each person‟s journey onto a map, which immediately
demonstrated that two-way cycling here was a city-wide issue, rather than just being
a purely local issue affecting only residents (and this was key to success of the
campaign)
7) Encouraging members of the Cycling Campaign to write to their local councillor
8) Writing a letter to decision-makers in advance of a key public meeting where the
decision was taken, presenting the national policy, the map of users of the street,
and the overall case.
9) Publicising the whole issue and keeping people informed during and after the
change.
The campaign was won. However, it took a lot of work, just for this single street. Four years
on, there are many more streets that are still one-way.
Many of the above activities could have been automated or helped by a good toolkit:
1) An e-mail list could be automatically created if we already know who lives in the area
(and therefore likely to be interested) or who has said they are interested in „two-way
cycling issues‟
2) Researching national policy could be provided „on a plate‟ since this is a common
issue elsewhere in the UK and there are specific documents about it
3) Setting up an online petition is becoming easier
4) Converting postcode/address locations into a map format could be entirely
automated, rather than each having to be plotted on the map manually
5) The process of encouraging people to write to local councillors could be improved by
having key points available and identifying who the councillors are, based on where
people live, and approaching Councillors only in the areas (and council committee)
concerned
13
6) Publicising the issue could have been made much more easy, ideally avoiding the
need for a particular „webmaster‟ with special web knowledge to do this task.
14
Section C: Overview of the toolkit
14. Overview of the toolkit
The toolkit will be a dedicated website, free of charge to use.
It will be split into two main sections:
a) Reporting a problem: a section open to anyone
b) Managing and solving problems: for campaigners and groups, requiring a login
These are described in more detail below.
15. Reporting a problem: a section open to anyone
This section will enable people to report a cycling-related problem (or an example of good
practice). This will be made as user-friendly and straightforward as possible. People will:
i. pinpoint the location on a map of the UK
ii. add a photo if they have one (which will be encouraged)
iii. add a quick one-line summary of the issue
iv. optionally, add further details of the issue
v. add a category so that types of issues will automatically get grouped.
Submission can also be done via the CycleStreets Photomap website and via the CycleStreets
mobile apps and mobile web site.
15
Anyone will be able to submit problems, e.g.:
Campaigners
Members of the public who cycle, perhaps encouraged to submit problems thanks to
publicity by campaign groups
Members of the public who would cycle if infrastructure were better
Local Authority officials and elected Councillors
Anyone else
The types of problems that can be added are either:
Point-source locations, pinpointed on a map (e.g. for needed cycle parking,
obstruction needing removal, parking problem hotspot etc.)
[[P3]] Linear problems, i.e. lines drawn on a map, e.g. for where a desired cycle route
could be created where it does not currently exist. This could be a single line (e.g.
cycle lane needed on road) or a set of related lines forming one overall route (e.g. a
missing route through an area).
The different types of issues will use the same data format, i.e. will have the same set of
fields. Labelling will be used to encourage good standards of data submission (e.g. for cycle
parking, encouraging people to explain who would use it and how many stands would be
useful).
The available category types are as listed on the left side of
http://www.cyclestreets.net/photos/categories/ . These will be reviewed to see if lesser-
used ones can be consolidated to shorten the list. The meta-categories at the top will also
need review, but at least problem/good-practice must stay.
Implementation notes:
Store as Geometry – doesn‟t matter what type. No need to convert existing data.
Addition of title is an API change but agreed worthwhile.
Consider a tags implementation for the categories using tags
Submission (and/or commenting) requires either a user account or a round-trip „Confirm by
e-mail‟. The same system as used by MySociety would be sensible; e.g. see
http://www.fixmystreet.com/report/198713, where adding a password is optional but is so
easy that people will use it and not realise they are effectively registering an account.
In respect of issues that people have already submitted:
These will be shown publicly on the map (where they have not already been solved)
Others can „thumb up‟ (I agree with the reporter‟s view of the issue) and „thumb
down‟ (I disagree) the issue (once only, cookie-based to deter casual abuse, or
assigned to user account if logged-in). A count of these „Public votes‟ will be shown
internally. The user adding this will be stored so that future segmentation would be
possible, e.g. showing by group.
16
A link to the internal campaign page on that issue (the „thread‟, see below)
discussing it will be shown. This will take people to a login page and only
campaigners can access it.
No discussion will be possible on the public site. (All commenting is in a thread,
which has a group context.)
Outcome of an issue if it has been resolved [Not possible presumably as multi-group
nature means that there is never an unambiguous resolution?]
[[P3]] An issue can be marked as resolved in a soft fashion by a Committee member
of a group.
Public users can tick a box when adding an issue to opt to receive a notification
whenever a group marks a location they submitted as resolved.
Multiple threads per issue are possible. [Discuss splitting later.]
There is no facility to correct a factually-wrong item; this would have to be done by a
Toolkit Manager (i.e. senior person running the system) because groups cannot amend an
issue.
Interfaces to consider when designing the submission phase are:
FixMyStreet: http://www.fixmystreet.com/report/new
FixMyTransport: http://www.fixmytransport.com/
Flickr
CycleStreets Photomap (is problematic and so should not be emulated)
17
16. Managing and solving problems: for campaigners and groups
This section of the website is intended for people interested in campaigning and working to
solve the problems submitted. It is the larger of the two sections and it will contain many
different facilities.
Each local campaign group will have its own area, i.e. its own customised toolkit, picking up
the submitted problems in their geographical area only. All discussions and so on will be
private to their group (unless they decide otherwise) and managed in the way they want.
People using this will be:
Members of campaign groups (both ordinary members and those running the group)
Other campaigners that are not members, potentially, if the group wants to allow
that
Officials, elected Councillors, and people like residents association reps, if
campaigners want to invite them into particular thread(s)
The sorts of activities that campaigners will do here are:
Viewing submitted problems, either on a map or listing format
Categorising and clarifying submitted problems
Discussing the issues amongst the group
Adding/removing oneself from individual discussions
Grouping issues together, e.g. by tagging
Prioritising the issues in a variety of ways, e.g. by importance, achievability, cost
range, date, etc.
Bringing into the discussion any best practice examples from elsewhere
Adding in factual information into the discussion, e.g. a likely costing of some
infrastructure, national guidance, etc.
Marking good practice as something that might be of interest to other campaign
groups elsewhere in the UK
Inviting in other people, e.g. local residents, Local Authority officials and elected
Councillors, if wished. (Often these are external people who have extensive local or
technical knowledge.)
Setting up meetings, petitions
Drafting letters, blog posts and other resources
Publishing issues (i.e. informing the public) in a variety of ways
These and more are given in more detail below.
18
17. A one-stop-shop for campaigning
Cycle campaigners deal with a whole range of issues, and an aim of the toolkit is to try to
bring these together into a „one-stop-shop‟ for managing them.
So the toolkit will aim to:
Provide a central way for anyone to submit a problem, as mentioned above
Provide a central way for campaigners to manage, discuss and campaign on
problems.
Bring in locations of planning applications, and showing these as issues to be looked
at, displayed on the toolkit‟s map automatically
Let people browse and interact with best practice from around the UK
Have an e-mail drop box so that e-mails sent to the group‟s external public e-mail
address can turned into problems on the map in the same way as other issues
appear on the map. (Future implementation could be direct integration, but this
means adding much more editing functionality.)
Provide the ability to replace manually-managed e-mail lists with automatically-
created e-mail discussions and online forums that include only people who have
expressed an interest in each particular issue
Import other sources of geographical data (e.g. a group may already have a database
of cycle parking locations), again to show on the map
Provide a way for issues to be published on an existing website easily and flexibly
without the need for copying and pasting material
19
Section D: Group basis
18. Respecting groups’ autonomy
The cycling community is very diverse, and as such, there are lots of views on lots of
subjects. Sometimes there are multiple groups with an overlapping geographical remit.
The toolkit aims fully to respect groups‟ autonomy. The principle is that the toolkit is, by
default, an „internal management tool‟ that members of the group – and only members –
can use, but they can choose to make the toolkit more open to others if they wish.
The toolkit:
Will enable campaigners to discuss issues as publicly or privately as they want
Will not force a view on anyone – it is merely a platform to make discussion and
issue-management as simple as possible
Will enable groups to share best practice knowledge with other groups
Will make it easy for groups to invite in Local Authority officials and elected
Councillors, if they want. (If not, those people will of course not be able to see the
discussions.)
Will manage issues in their area independently of other groups who might also be in
the same area.
The latter point is important and needs some expansion:
Each group can define whatever geographical area it wants (e.g. “Tell us about all
issues in Placeford”), irrespective of whatever any other group has decided. In rare
cases, a group may wish to exclude a geographical area (e.g. South Cambridgeshire
is a Local Authority area which fully surrounds Cambridge).
For instance, if a Cyclenation group and a CTC group both work in Placeford, they
can both set up their own area and not share discussions
Therefore, it will be possible for more than one campaign group to register for
managing problem reports in the same area. This is not a problem technically and
reflects the current situation in some places. The toolkit will be available equally to
any group so it should not change any politics concerned. If anything, the toolkit
system will hopefully encourage closer working.
Groups can choose to open up an issue („thread‟, see below) to another group,
however. For instance, if Placeshire CTC and Placeford City Cycling Campaign are
both working for a 20mph zone in an area, they could join together on that issue,
while not sharing information on other issues.
Groups could choose to open up an issue („thread‟, see below) on a cross-boundary
basis. For instance, if the South Placeford Cycle Campaign and the North Placeford
20
Cycle Campaign are working on trying to get cycle lanes on the A-road between
them, they could join together on this issue if they wish.
Where a set of campaign groups in an area are working together, both logos would
be shown.
19. Presentation of available groups upon registration
When someone new comes to the site and tries to register in an area, having specified their
home location, they will be told what groups exist in the area.
Having done so, a table showing the list of groups in that area will be shown. For each there
will be a small map showing the geographical remit of that group plus a dot showing the
user‟s location as just specified.
A link for „all other groups‟ will be shown, with a name/place search available to filter these.
Again these will be listed in tabular format.
Groups that are the „main‟ group for an area will be listed first, beyond national groups.
Possibly this achieve by density ranking.
If a group does not exist in the area, or is not chosen, they can continue as a member of the
„Everyone Group‟, which ensures that users always exist in a group.
20. Group identity
Groups can apply for their own toolkit for their area. In doing so, they will:
Fill in a simple webform giving the required details
Specify a geographical area, by selecting this from a list of OS-boundary based areas
and possibly drawing on boxes. The exact possibilities here will be considered
during implementation.
Applications will, initially at least, be checked by CycleStreets before becoming activated.
This is to avoid mistakes and problems. The intention is that this check will be removed in
the light of experience gained with the toolkit after several groups have registered.
The application form will note clearly that this is a tool designed for cycle campaign groups.
If other types of groups wish to register (such as training providers, whose activity
tangentially covers campaigning), they could do so, but they will be warned that it is
designed more for typical campaign group structures and therefore they will need to adapt
their workflow within the toolkit accordingly. Charging after one month‟s usage could be
considered for such groups.
There is no charge for campaign groups to register.
Each group will:
21
Run its area of the toolkit under its own subdomain (see next section) or dedicated
domain name
Be able to customise the header and footer so that it matches their own site. This
can be done by pasting in HTML or by specifying a header and footer file that the
system will dynamically retrieve. (At a technical level, caching will be in place, with a
time setting established.)
Be able to add a logo, which will be strongly encouraged
Be required to fill in certain details about their group, e.g. main contact details, main
website (if they have one), and other things that ordinary members of a group will
find useful to have easily available.
Have a list of their (usually elected) Committee officers. These will be attached to
their usernames in the toolkit. The default state is the Committee member who is the
person who created the group initially.
Have a settings page, determining the parameters of the toolkit, e.g. privacy
controls, member expiry default, etc.
Have a link to auto-subscribe users (further details of which are given below)
State whether they are a national, regional, main city/area group, or ultra-local
group (e.g. a company BUG could potentially register). Possibly this achieve by
density ranking.
Only Committee members can change the settings and lists of officers. They can be edited
at any time.
Changes to the list of Committee members will trigger a notification to the updated list of
Committee members and those that have been removed.
A profile page about the group will be available, listing these details, and showing its
geographical basis. The profile page will also include link to the group‟s
Twitter/Facebook/Blog pages if available, and show a feed of these.
The Committee-only area of the site (containing the settings and Committee forums) will
contain labelling to remind ordinary user threads to be action-orientated and to move
things on, and encourage the Committee members themselves to add in deadlines etc.
When a group registers in an area, this would therefore be available for people in the area to
join it, but they will not be notified in any way.
21. Website addresses for each group
Each group will by default have its own subdomain, e.g. placeford.<toolkitname.com>.
These will try to avoid name clashes (e.g. „ccc‟ which would be vague).
22
A group with an existing website can decide to change its default subdomain, according to
one of the following four options. (A group can only have a single option in use at any time.)
1. A website address they own, e.g. www.placefordcyclecampaign.org and make the site
entirely be the toolkit
2. A subdomain of a website address they own, e.g.
http://toolkit.placefordcyclecampaign.org/
3. A subdirectory of a website address they own, e.g.
www.placefordcyclecampaign.org/campaigning/. This will require proxying.
4. Or change it back to the default subdomain.
Groups can propose changing their default subdomain name (e.g. in the scenario that the
group‟s legal name changes), but this will require the approval of the system administrator
(i.e. a CycleStreets employee). Implementation note: ensure this is considered in the data
model, but implementation of an interface is only [[P3]].
Documentation on this will make clear the technical requirements. Groups using methods 1-
3 will need some technical knowledge of a webmaster to implement the change.
An iframe-based hosting will not be available, because this prevents direct linking to
individual issues.
Where a name has been changed, the old one will still be recognised and will redirect to the
new one.
As noted above, there exists a notion of ungrouped members, so these should be given
www as a domain name.
Implementation note: CycleStreets has an existing and well-developed PHP class which
could be replicated when implementing this.
22. Management of a group
A group‟s area will be „managed‟ by its Committee. In the case of more formally constituted
groups, these would be the elected Committee of officers.
Committee members can approve new people subscribing. This is described further in the
section on registration.
The toolkit will not include a membership payment system. This could be added as a future
feature, although this introduces all kinds of new security risks and will require a different
security context to be implemented.
The toolkit will not have a facility for ensuring changes to settings are approved by a
majority (or approve-unless-objections / approve at threshold).
23
23. Who can take part in a group’s discussions?
The question of who can take part in a group‟s work, i.e. view and subscribe to issues
(called „threads‟ – see later) being dealt with by a group, is entirely the choice of the group.
The Committee can set one of these policies for joining the group: [Confirm this is now OK]
i. To allow members subject to approval. This would either be members (joined, e.g.
paid-up or in the membership database) of their Campaign or a less formal
arrangement.
ii. A private system for Committee members only (though it is hoped that groups will
try to involve people more widely, i.e. the first option)
iii. To allow open access to anyone who wishes to subscribe. (However, this opens the
risk of anti-cyclist members joining maliciously, and arguably means there is no
democratic basis for operation of the group.)
24. Filespace limits
[[P3]] This whole section is P3. In practice this may never become an issue, and simply
buying more disk may be the cheapest solution than paying for development time. Cloud
storage could be particularly time-consuming to implement.
As noted in more detail below, it will be possible for members of a group to upload
materials.
Each group will therefore have a filespace limit, which is intended only to deter the
uploading of unnecessarily large amounts of documents (e.g. entire CDs worth of material
when only two documents in it might be relevant) and to prevent Denial of Service attacks.
There will be a soft limit and a hard limit. If the soft limit is reached, Committee members
will receive a notification that they need to apply to expand the limit before the hard limit is
reached.
Groups needing very large amounts of filespace can opt to add to their settings the details
(e.g. login key) of cloud storage that they have arranged. Further investigation will be
needed to determine which services (e.g. Amazon S3, Dropbox, etc.) will be supported. The
intention is thus that a group arranges their own storage, pays for it, then just adds the
details so that the toolkit can access the storage. This avoids CycleStreets Ltd having any
financial transactions, and provides an incentive to groups to avoid unnecessary uploads.
The quota will be shared when a thread (defined below) is spread amongst more than one
group.
Documents added to a general resource library will not count against the quota, but the
toolkit will be coded in such a way as to enable the central Toolkit Managers to monitor
usage.
24
The „Everyone Group‟ group will have a high filespace limit that the Toolkit Managers are
responsible for.
In practice, uploading large amounts of bulky material will be time-consuming (because of
internet transfer times) and so reaching limits will be hard.
Groups that are part of a larger group (e.g. LCC borough groups) will each have a quota of
their own, the same size as others.
25. Supergroups
A supergroup is basically a group like the LCC and CTC which are very large organisations
with local groups within them.
The main purpose of this is to be able to load the membership list, with the containing
groups being able to use this for auto-validation, rather than each group having to load a
copy themselves.
[[P3]] Potential later implementation is to add supergroup-level forums.
[[P3]] Potential later implementation is to be able to issue organisation-wide priority
campaigns (which draw attention to a specific thread) to all members. By default, all
containing groups will receive this, but they can choose to tick only certain groups instead.
An example would be a campaign on a London Cycle-Superhighway, which crosses multiple
areas. The containing group thus inherits this issue as a Committee notification. This might
need to be a user setting so that it is separate to the local Committee notifications.
25
Section E: Users and registration
26. Registration and profile pages
In order to take part in a group‟s discussions, campaigners will need to sign in with a
username.
Every user will have a profile page, containing the following information (with only the
username and name required – the user can choose to omit the other information:
Their username (i.e. nickname). [We discussed that id should be visible. But surely
username is actually required because real name is optional and e-mail is not
necessarily visible – there needs to be an identifier]
Real name, which is optional but strongly encouraged. MySociety‟s FixMyTransport
page at www.fixmytransport.com/about has a good policy. (Real name cannot be
made into a group setting, as this would break cross-group discussion logic.) This is
a single, unsplit field for the whole name.
Their e-mail address (which is not revealed unless they choose to allow this)
Which group they are registered to (this could be more than one group, potentially)
A picture of themselves (avatar)
Their location, entered either as a postcode (converted automatically to a map
location) or directly clicked on the map
Contact details, if they wish to reveal them
An „about me‟ text section that people can fill in
[[P3]] Profile pages also include a private messaging system. This is to enable other
members to contact each other without revealing their e-mail address. This will display
messages in a conversation-style view, split by user and then subject line. (The new
Facebook-style system of splitting only by user has been rejected – the use of a subject line
maintains similarity with e-mail and means that the standard thread implementation pattern
is possible.) This is lower priority implementation, and it could create issues of court
intervention because we host the material but it is not public.
Existing users from the CycleStreets Signin database will be imported as a single-time
migration.
An e-mail address can be connected to one account only. This is so that a password-reset
feature is possible by quoting only the e-mail address.
Account details, including the e-mail address, can be changed. However, usernames cannot
be changed.
Methods of creating an account (and logging-in) will be:
26
Using a standard user account creation system as currently used by CycleStreets.
[[P3]] OpenId can be added. (People with existing accounts on the relevant cycle
campaign websites could use that account to log in, where those systems have been
OpenID-enabled.)
[[P3]] Facebook login could be added
Auto-registration by a Committee member of a group, as detailed below.
Upon registration they then state which group they are trying to attach themselves to. (If the
user was invited by a Committee member then this step is skipped automatically.) If the user
does not recognise any groups they will be part of the „Everyone Group‟. These will be listed
with city/area groups first, then the other categories (national/regional/micro) using some
UI implementation to make these visible without much scrolling.
An account can have multiple identities (login token), e.g. e-mail address, username,
multiple e-mail addresses, OpenID. Basically same as Facebook, where any of these acts as
the first field, with a second field for the password. This is a lower priority for
implementation; initially, it will be a simple e-mail address & password system.
Registered users:
Will specify the kinds of campaigning themes they are interested in. (This is
described in more detail below.)
[[P3]] Would be encouraged to enter their home postcode, and places of work and
leisure so that the user gets a nice „cycle from/to here‟ route links based on these
submitted key places.
„Plot-my-routes‟: Having entered these work/leisure locations, routes would
automatically be created by the CycleStreets journey planner. The user would be
encouraged to adjust („drag points on the line to correct it‟) the generated routes
against their actual, undertaken journeys (data which, in itself, could be used to
improve routing quality in the CycleStreets journey planner), or upload a GPX file.
This route feature is used so that submitted problems can be linked to people who
actually would stand to benefit (and who therefore have an incentive to get involved
in the issue). Implementation note: requires OpenLayers work – look for a system
with waypoint dragging.
Add bounding boxes of areas to monitor. [Unclear here whether the group boundary
or the user boundary takes priority, i.e. which filters which.]
Will be required to say whether they want to receive thread discussions by e-mail or
(by default) just read them on the web. They can later come back and change this
setting. Important issues flagged by Committee members will still get e-mailed by
default, as discussed in a section later in this spec.
Users agree the copyright status of their contributions when registering. This will include
confirmation that the hosters of the system (CycleStreets) are licensed to host these
contributions.
27
Users agree to respect the copyright status of all material submitted and are reminded
about the importance of respectful and cordial discussion with others.
A formal usage policy („tick here to accept‟) will be considered.
Users will be given helpful „guidance bubbles‟ to ease them into the toolkit‟s interface the
first time they use them. The number of these will be limited, to avoid them becoming
annoying. These will have an „OK‟ button in each case to prevent them being shown again.
The UI will make very clear what is and is not available to other users. Developers will be
urged to read http://www.slideshare.net/padday/the-real-life-social-network-v2 before
beginning development.
27. Types of users
Users are either:
Committee members. Only current Committee members can make other people
Committee members. Committee members have additional rights, as described in
various places around this document. When such additional rights exist, this will be
indicated in the interface by a shield symbol, indicating a privileged operation. Links
to privileged operations will not normally be visible to non-Committee members, but
there may be a few cases for other members to know that an operation exists but
can only be done by a Committee member.
Standard members of the group, however that is defined (e.g. paid-up or otherwise)
according to the Committee‟s choice of how they manage their toolkit
External invitees (e.g. Council officials, elected Councillors, residents‟ association group
contacts, etc.) are just normal users that aren‟t part of the current group in question.
Groups can determine whether these people can see all discussions on a topic (tag) or (more
likely) just individual issues („threads‟ and subthreads, see below). Only committee members
of groups can invite externals into a thread. [This point wasn‟t discussed and needs to be
confirmed.]
28. Auto-invitation of users
Groups can auto-invite their members as users of the toolkit, on the following basis:
This can only be done by Committee members of a group.
It is done by importing a set of e-mail addresses, as a list pasted into a box ([[P3]] or
uploaded as a CSV). The group must tick a data protection box confirming that
CycleStreets Ltd has the legal right to process this data (and only for the purpose of
issuing the invitations, but not storing the e-mail address).
28
It will only have the effect of issuing an pre-formatted invitation to the user to
register.
[[P3]] Where the Committee has added these invitees, the list of those who have
accepted will have hyperlinks to active user profiles (i.e. those who have responded).
The listing will also show those who have not responded, and it can be amended
(e.g. unregistered people deleted).
Invitation by Committee is basically the first stage of the standard registration process i.e.
sends the invitation, but with “You have been invited to join ...” text added.
Invitations to join should expire after some period, e.g. 2 months. This is to guard against
the scenario that an updated membership database is not uploaded.
The importing of e-mail address results in e-mails being sent out, but the e-mail address
itself is not stored. Instead, only a hash of the address is stored. When the user later
registers, a check against the stored hashes is done, to determine if they are a current
member.
Groups can re-enter the list of e-mail address / CSV file to update their membership
database, and effectively deny members further access, when a group runs on the basis of a
members-only access system (which is likely to be the default scenario). [Unresolved
problem here that they don‟t get to see what they previously wrote; this is like an e-mail list
system, except that they would have their e-mails.]
A future development might be full API integration with systems like CiviCRM, both for
validating members and for obtaining lists of who could be encouraged to become a
member.
Individuals can invite others to join, again issuing an invite in the same way.
29. Status bar, at the top of the screen
Once logged-in, users will see a bar along the top of the screen which contains:
A menu giving links to the various sections of the site, including:
o Threads (forums)
o Library
o Best practice galleries
o Group info
Notifications (things they need to look at)
A search box
Confirmation of their username
A link to help and documentation
29
A feedback link, so that people can suggest new features or tips that should be
added around the toolkit.
A logout link
This status bar will be visible whatever section of the site the user is in.
30. Help and documentation
A section giving information about the toolkit, help and documentation, will be available.
This section is likely to be relatively light, as the main pages of the toolkit should be self-
explanatory. Development is being undertaken on the basis that if the toolkit is not entirely
self-explanatory from a usability perspective, the toolkit will not be used to its full potential.
Facebook, for instance, does not require an instruction manual, yet includes significant
amounts of complex functionality.
A wiki could be considered.
30
Section F: Dealing with issues: campaigning
31. Getting an overview of campaigning issues
Upon logging in, the user will be in the campaigning section of the website.
This section is not public, in that it requires a login. No material here will be accessible to
anyone without an account and which is connected to a group. Google and other search
engines will not be able to spider this material.
A campaigner will be able to:
See all the issues of interest to them (however submitted into the system)
Not see other issues not of interest to them by default
View them on a map or in a forum-style text view
Have their own listings of issues prioritised, in various ways
Be able to discuss the issues, e.g. add replies
In respect of the map view:
Locations will have different icons depending on the type of issue, e.g. cycle parking,
obstructions, etc.), in a similar way to the current CycleStreets Photomap
Filters can be applied, e.g. to show only cycle parking problems.
Additional static layers can also be switched on for information purposes, e.g. cyclist
collision locations (subject to availability and licensing compatibility by area),
potentially transport-related crime (if available) and London Cycle Hire locations.
(Implementation note: the current CycleStreets Photomap bubbles can obscure map
sections below them, as they bubbles are quite large. Try to reduce this problem if
possible.)
32. ‘Threads’: core concept for discussing and managing issues
A „thread‟ is basically a discussion on a specific issue or more general topic.
The toolkit will have a core notion that every issue becomes a thread (discussion page), into
which replies (views and facts) and resources (e.g. more pictures, guidance, best practice
examples, even other related issues) can be added.
This is a similar concept to things like:
An e-mail list, where an issue is raised (with the subject line being the title) and
people reply, one-by-one, sometimes quoting previous text, and where people can
attach pictures, documents when they reply
31
Web forums, where each issue is an entry in the forum and people reply one after
another
A thread is created automatically for every submitted issue, planning application, etc. I.e.:
Every issue submitted (e.g. “Cycle parking needed here on York Street”, “Removing
the bollard near the entrance to the supermarket”, “Adding a cycle lane on Downing
Street”)
Every thematic issue (e.g. “20mph zones”, “Cycle parking”, “Cycle lanes”, “Helmets”)
Every non-geographical topic (e.g. “TfL‟s cycling strategy”, “Committee meeting on
2nd July”)
Every planning application (“New school on York Road”)
Every other issue which makes its way into the system (e.g. imported cycle parking
locations)
33. What threads (issues) does a person see when they log in?
People are automatically „subscribed to‟ the types of issues which they have said they want
to know about. All of the following will apply in determining which issues get subscribed to:
By default, the user sees the default listed items of the group they are in, which is
the group‟s boundaries plus any other issues that a Committee member has added
in. Only items marked as problems are shown. Having defined this set of items, a the
following changes and filters then apply:
On first registering with the website, they specify what thematic issues they are
interested in (e.g. “Cycle parking”, “School cycle safety”). Some people may not be
sure (particularly newer groups), so they will be able to leave this blank.
On first registering with the website, they can also specify the areas they cycle,
effectively drawing lines on the map representing the places that, when issues are
submitted in that area, they will get to know about them. (The concept here is that, if
someone cycles through an area, changes to that area affect them, so they are more
likely to be interested.)
If they wish, drawing a box or multiple boxes on the map showing the area(s) they
wish to know about. Some users (particularly Committee members) may even wish to
watch the entire area of relevance to the group.
Manually adding themselves into a thread, by „ticking it‟
Adding a comment to a thread they are not currently subscribed to (since this
indicates they are interested in this particular thread)
Being invited into a thread by another campaigner (i.e. an „I think you should see
this...‟ invitation), which they can chose to tick/respond to in order to subscribe
32
If the person is not interested in an issue comes up, they can just untick it.
Users can start a thread while logged in, which is equivalent to adding it on the public side.
In summary, the result is that:
People only get subscribed to what they‟ve said they want to hear about, and nothing
else
Issues that get submitted automatically become available in their list of threads
People can view/monitor other things being discussed without subscribing to them
People can easily unsubscribe from an issue
If a person has left the thematic issue types section blank, they will see a message at the top
of their thread view that this is the case, and that they can browse other issues in the „all
issues‟ view to help them decide. This message will not be dismissible, as the toolkit is
intended to encourage issue-based filtering.
The map view will have a „View everything‟ option which acts as a view of all issues
submitted, without any geographical filtering or user post-filtering. Committee members
will be particularly drawn to check this regularly for items outside the group‟s normal area
of interest.
Note that there is no concept of „subgroup‟ in the toolkit, because the thread system
effectively provides this granularity natively.
34. How can threads (the issues) be accessed?
Campaigners can read and reply to threads by either (or both) of these:
Logging into the website, exactly like a forum
E-mail, exactly like a normal e-mail list
For instance, if someone replies to a thread on the website, people who prefer to receive
things by e-mail will see that reply coming in by e-mail, and vice-versa. People can also
choose to do both, i.e. also log into the website.
RSS was considered, but this is considered a deprecated technology now and unlikely to be
used.
There will not be a „Send this thread to me by e-mail‟ button for catching up with older
replies. Instead, e-mail –using users must reply on the forum view, which will then subscribe
them.
35. Flagging of important issues by Committee members
Committee members can „flag up‟ important threads:
33
Top-priority, high-profile campaign issues that they particularly want everyone in
the group to be aware of, which will appear in a News section on the front page
when logging in and as a notification.
Notification of flagged items will also go by e-mail to all members of the group, even
if they do not receive e-mail by default. This is because these messages are like
special announcements sent via an announcements list. People can disable receipt of
these in the settings, and in a link in e-mail.
There is no need for Committee members to be able to flag issues on people‟s routes, as
the toolkit does that already natively.
If a person has previously unticked an issue that they were automatically subscribed to, and
the Committee flags up that issue, it will be re-shown, but lower down on the page in a
separate section.
36. Summary of information shown at the top of each thread
The top of the thread will have:
An initial title (which is the summary that was originally submitted by the person
reporting the issue).
Optionally, a description, which is the description originally submitted
The category, which will have a link to other issues in the same category (e.g. other
cycle parking issues)
The time submitted
A button for subscribing or unsubscribing
A button which, when clicked, shows who is subscribed to the thread, which will
always show all usernames (but also their real name where people have enabled this,
which will be encouraged). This panel will make clear that this refers only to the
people currently watching the thread, and that this list could (and likely will) change
in future. Where a person is an external person that is not a member of the
campaign group (e.g. residents‟ association representative or Local Authority
officer/Councillor) an indicator will be shown next to their name. An indicator will
also be shown on the page to confirm that externals are present, so this is visible
even without seeing the detailed list. The general principle is that it must be made
very clear to members that externals are present.
A Google Street View display, to help people give context
A display of the group(s) dealing with this thread. Normally this will just be a single
main group for the area. However, in places where more than one group is covering
an issue and have agreed to share a thread, both logos will be shown.
The number of public thumbs-up, for information
34
Prioritisation controls (see further details below, e.g. „prioritise by importance to
me‟)
A link to the relevant WriteToThem page (a website which enables easy contacting of
elected political representatives for an area) or internal contact-my-Councillor page
having the same underlying data. Text associated on the page with this facility will
encourage people only to do this when they have read and engaged with the thread.
It will also remind them not to purport to represent the group officially without
authority. [Needs to deal with the issue of „Own MP‟ and „Own Councillor‟ since
sometimes the people are in a different area.]
A leader (basically a member who acts as a main contact) of an issue. This does not
make them an „owner‟ in the sense of moderation, etc. [Consider further how this is
set.]
The sphere of influence of an issue, which anyone can amend and which results in a
thread reply appearing saying that it has been set/changed.
Controls for inviting external groups or individuals („externals‟) to join the thread
(discussed in a section below).
37. Types of replies in a thread: advancing the discussion
A thread can have the following types of things added to it (and there can be any number of
such replies):
Text replies, which will be very commonly used. (These can include quoted sections
of a previous reply. Quotations will try to detect people carelessly quoting an entire
entry, but instead encourage it to be cut down to the relevant parts only.)
A photo
A new Google Street View location
A map location
A geolocated image
A notification that the thread‟s title/description has been amended by a user
An link to a online newspaper article or blog post
A document or documents (e.g. a link to a policy document). Documents will be
encouraged to have structured data added so that they can be found more easily
later. [Should every such item become an info block?] Documents can be uploaded or
just linked to. Uploads will be encouraged particularly where this relates to an
important reference.
A general web link, which shall include a field for a description so that people know
what they‟re about to click on
35
A relevant tweet on Twitter. [Should there be other types of Twitter integration
available in the toolkit?]
An e-mail attached into the thread (e.g. a reply from an official that campaigners
should be aware of). E-mails relating to the issue/cloud can be bounced/forwarded
to the toolkit via a mail-to-web gateway, and when they log in to the web forum
view, the person can assign the e-mail they have forwarded from a list of those
waiting to be added to a thread.
Information that is marked as „Strictly private to the group‟ that should not be
forwarded to outsiders. For instance, there could be known issues relating to land
ownership or strategic issues with the council which would not be productive to
broadcast. [Should there also be a „Notes for Committee‟ box?]
A public comment from the public, „dragged-in‟ from a box in the top-right of the
page.
A notification that someone has been invited into the discussion (which can only be
done by a Committee member); in the case of external people such as an official
from a Local Authority, this will be from a „pick list‟ of people and their job titles and
areas of involvement, and campaigner „drags this person into the conversation‟ from
a box in the corner of the screen. The toolkit will have visual clues that help promote
(but not force) this kind of interaction. These people can often add useful
information about feasibility.
An „info block‟ (see fuller description below) which outlines a policy statement, e.g.
national policy (e.g. “National policy on pedestrianised areas”) which tries to
summarise key resources succinctly, and includes key quotes.
Campaigners can pull in examples of best practice related to the particular issue,
from the best practice examples already in the toolkit (see:
http://www.cyclestreets.net/photos/categories/) or which are submitted as good
practice by people adding locations. A quick and direct search will be available to
make these easily-findable. For instance, if an issue regarded the need for cycle
parking in a tight space, best-practice examples of solutions to that problem from
elsewhere could be directly referenced by attaching that to the item, reducing the
ability for decision-makers to claim “it can‟t done”.
An info block which outlines a likely set of costs for a type of infrastructure
An „Item nearby‟ (see next section), which can be „dragged-in‟ to a discussion.
Related to the „nearby‟ concept, the setting of the sphere of influence of the issue
(see next section).
An Official Policy Position of the group.
A pre-formatted invitation (e.g. “Someone please agree to draft a letter”) that people
can accept.
36
The drafting of a letter or article. This will involve integration with an Ensembling
document (www.ensembling.com is a website for enabling people to draft a
document and enable other people to comment on it, iteratively producing drafts).
This will also remind people of the importance of seeking Committee policy approval
for official letters. When the document is approved, the compiled comments will be
forwarded by Ensembling and be imported into the toolkit for future reference.
[Discussions about the integration possibilities, particularly an API approach, are
ongoing.]
A Google Docs link. This will also remind people of the importance of seeking
Committee policy approval for official letters.
A statement that a letter has been sent, and to whom, and attaching the letter itself.
[Could the toolkit do the actual sending out as well?]
A proposed Campaign Objective (e.g. a solution like “Addition of a cycle lane” in
response to a submitted problem like “Dangerous traffic here”. These are designed
to encourage action-orientated discussion. People can thumb these up or down (one
vote per person), with the count shown.
A deadline. More than one deadline can be added, but users will be warned about
other deadlines that are still forthcoming. When adding a deadline, a description of
what the deadline relates to (e.g. “Consultation deadline”) has to be added.
An entry for a poll (described below).
An entry for a petition (described below).
Other types of material/activity (as become required as usage of the toolkit
increases).
Achievement of a campaign objective, e.g. that the cycle parking location has been
added. This will also show as visible text on the public map view, where it was
originally submitted.
A photo which officially supersedes the original photo in depicting the new situation
on the ground.
Reference to a „Case study‟ entry for the information of other groups. This is
explained in a later section below.
The process of dragging things like info blocks into the thread will be subject to the advice
of the designer / Information Architect.
Several of the types here are links. The toolkit will try to auto-detect the type of link (e.g.
map link vs. Twitter) and intelligently structure the metadata and display, according to the
general aim of the toolkit to automate things. For instance, a Tweet would have a Twitter
logo listed, user details, and the content of the tweet could be shown.
In terms of implementation, each type here is a „bag of stuff‟ of information which forms a
single entity. For instance, a set of attached documents are a single entity, consisting of a
set of files each having metadata. Thus the hierarchy is: Toolkit system > Categorisation >
37
Thread > Thread element (i.e. „bag of stuff‟) > Item > Metadata. Each bag is not splittable,
but its contents can sometimes be editable (which could mean removing a document, for
instance).
Some of these (e.g. drafting of a letter) will include tips to encourage groups to do things
well. For instance:
The importance of including the phrase “We object” when submitting a formal
objection to a planning application.
The importance of not publicly chastising a LA officer when it is the ultimate
responsibility of elected Councillors.
The importance of assembling on an issue, a (i) Justification, (ii) Knowledge and (iii)
Context. (Having these was highlighted by a LA officer as useful internally.)
Members can undo („Click X‟) an addition, working on a similar basis to Facebook. If other
people have already viewed the comment, the fact that the person adding the item has
removed it will be noted. This will avoid suggestions that members are trying to „game‟
discussions by adding things that other people then do not see.
Members can also edit their postings (including the ability for a reply submitted by e-mail to
be edited online by the same user). When an edit is made, the fact that an edit has been
made will be noted. [Should the old edit be displayed, perhaps on a time-after-editing
basis?]
Members can view archives (i.e. replies in earlier threads before they created an account).
This is necessary so that new members can immediately get up-to-speed on any particular
issue. This mirrors the ability of a new member joining a campaign forum website to see
what was previously written.
When another group or an external person (e.g. Local Authority officers or residents
association contact) is added into a thread, the Committee member adding them must
specify whether this person can see the archived discussion higher up in the thread, or
whether they cannot see anything beyond the point they are added. If the latter, the
Committee member will be prompted to add a summary of the discussion so far. [If the
latter, how do documents get reforwarded?]
Members (even those not following the thread) can click a button which has the effect of
anonymously stating that they feel that the discussion is becoming too chatty rather than
action-orientated. An indication of this count will be shown. [Is this really necessary?
Probably over-fussy and won‟t get used.]
Threads can be viewed only in date order. Hierarchical replies (who-replied-to-who) is
confusing and will not be supported.
38
38. Sphere of influence of issues: the concept of an item nearby
Often an issue must take account of another nearby issue. For instance, a potential cycleway
alongside a railway corridor needs protection from planning applications in the area which
could cause a blockage to the proposed cycleway.
This is implemented by allocating an area (circular for a point-source issue, or a lozenge for
linear issues) around the issue.
The size of this sphere of influence is determined by a score, which is computed by an
algorithm taking into account
i. Date-based – (not date added, but range of relevancy)
ii. Distance
iii. Same type
iv. Consider a „set a flag‟ basis, e.g. “This important issue must be considered for
anything in the area in future”.
The sphere of influence is then picked up by another issue by detecting whether its area
coincides with the other issue.
Implementation note: For the „My journey(s)‟ lines in the user profile, if implemented as a
line, rather than an expanded box, then the weighting algorithm can do the attachment to
the line, i.e. “does the line go through the circles”, rather than the other way round.
39. Inviting externals to join a thread
„Externals‟ are:
Other groups
[[P3]] Other individuals (e.g. a residents‟ association representative).
In respect of the controls for inviting externals to join the thread:
When inviting another group, the Committee member is told that the member of the
other group will be able to see the current group‟s discussions.
Such an invite results in a notification to the external group‟s Committee members.
In some cases the external group may already have been discussing the issue. Where
this is accepted, and if both groups have already been discussing it, the thread is
marked as merged, and the two discussions (one for each group) can be accessed by
either group. In UI terms, this could be implemented as links or as an expandable
“see earlier discussion” panels. The URL may be a determining issue, because both
parent threads will have the same ID (with system determining which discussion to
show based on the subdomain; obviously when both are being shown, users should
not end up switching to a different subdomain).
39
The control should actively indicate that there may be others interested. This needs
to take account of the relative sizes of the current and external groups, to avoid
people bombarded with a flag continually. (This feature ONLY determines whether
the interface should actively be flagging up “This other group might be interested”,
rather than the ability to share per-se.)
The relative size is implemented using a „Full enclosure rule‟, so the flagging of the
external group doesn‟t happen if the external group fully-encloses the logged-in
group. So NationalCTC>Camcycle is the same case as Camcycle>AddenbrookesBUG.
Camcycle gets notified that AddenbrookesBUG might care about issue within
Addenbrooke‟s, but AddenbrookesBUG will not get notified that Camcycle might be
interest. Make the full enclosure rule be settable as say 100% or 80%. The Committee
can untick groups, which avoids new groups trying to poach other groups‟ members,
but use the full enclosure rule by default.
[[P3]] Individuals are lower-priority for implementation. In respect of them:
Someone may wish to issue an invite to them.
Their stated boundary/boundaries of interest are used in the standard way for the
full enclosure rule.
40. Using e-mail instead of a forum view (mail-to-web gateway)
As noted above, users can ignore the web-based forum-style thread view, and interact with
threads via e-mail instead / as well. The intention here is that users who like to manage
workload by e-mail can use the toolkit as if it implemented a standard e-mail list.
Users, however, will need to use the forum view if they want to add themselves to other
threads that they are not automatically-subscribed to.
Users can follow a link in an e-mail to unsubscribe from a thread. This will not require login.
[Is this sufficiently secure?] The webpage they are taken to will include a confirmation button
to prevent accidental deletion.
When threads are sent by e-mail, e-mail addresses of other people will not be transmitted.
E-mails will come from a system address that does not relate to any person‟s e-mail or
username.
Thread reply will be secured against malicious imitation of another user. The address of
every e-mail will contain a unique and randomised number. The e-mail sender address will
also be analysed. Together, this means that, when replying, other users cannot send a fake
e-mail pretending to be from someone else. Unmatched addresses will result in a bounced
e-mail. [Or should it just use headers to deal with message hierarchy?]
Replies (to a thread) that are sent by e-mail will try to maintain threading:
The use of the unique e-mail address will ensure matching of subjects.
40
Outgoing subject lines will match the thread title; incoming subject lines (i.e.
included in the reply from the user) will ignore changes to the subject line
Quoting of text will take place, and the toolkit will try to match up text using a
variety of means. (Google Groups uses a similar technique.)
[This proposal needs auditing.] A user can start a new thread without going to the website:
By e-mailing a known e-mail address of a list. They will be given this when signing
up and encouraged to add it to their inbox.
This will which will have the effect of creating a new, non-geographical, thematic
discussion with the subject line being the title of the thread.
Any user, including the original poster, viewing threads via the website (forum view)
can migrate this new (currently non-geographical) thread to a geographical thread
by giving it a location by clicking on the map.
Users can opt for a daily digest which will send all the replies at once. This will be organised
by category, then thread, then reply. The daily digest will come from an address which will
bounce if replied to, as the toolkit obviously cannot determine which issue is being replied
to. Instead, each reply in the digest will include a link for the person to reply to in the forum
view.
41. Viewing and managing threads
Discussions on a topic can often contain useful information amongst other chatter which is
less useful. Subscribers to a thread can therefore:
Thumb up or down (i.e. a quick “I agree” or “I disagree”)
Be able to flag up useful things for future reference. They will be able to see these
„bookmarks‟ in their profile
Be able to hide replies that they don‟t want to see any longer. This will only affect
their view of the thread, and not anyone else‟s. [Is this needed – why not do a
Facebook-style auto-scroll instead, or paginate with memory of the last page
shown?]
Set the way that a thread is shown, e.g. unread-only or view-everything. Where
view-everything is set, they will be able to get to the last-viewed post quickly.
When someone is viewing a thread and, at the same time, someone else posts a reply:
That reply will immediately become visible on the page in the relevant ordering
If the person viewing the thread is also writing a reply at that exact time, this reply-
writing process will not be disrupted.
A user viewing threads via the website (forum view) can migrate a non-geographical thread
to a geographical thread by giving it a location by clicking on the map.
41
42. Committee-only threads
There will be an section of the thread discussion area which contains threads marked as
Committee-only. These are intended so that the (usually elected) Committee of the group
can discuss strategic issues in privacy, mirroring the standard operating arrangement of
many groups.
It is hoped that, over time, groups will need to use these Committee-only threads less and
less, as most actual issue-based discussion can be done in the normal threads.
These threads will only be visible and editable by the current Committee members. If an
ordinary member is elected to the Committee, they will gain access to historical private
threads, much as an e-mail archive becomes accessible to them. [Does this create the need
for deletion, and if so, what is the governance arrangements for these?]
These threads cannot subsequently be changed to open-access.
43. Thread prioritisation
An important feature of the toolkit is that issues can be prioritised in various ways. This is
because there are often lots of issues to sort out in a city, but campaigners and councils
obviously cannot tackle everything at once.
Prioritisation exists as a concept in three ways:
Individual priority (“Importance to me: <...>”), not visible to other ordinary members,
but visible to Committee members
Priority to the overall group, set by the Committee
And additionally, a time-based view of deadlines
By cost banding. (This is a lower priority for implementation.)
There are five levels of importance. Each level has a value, shown here in brackets, which is
only of relevance to the Committee (as explained below).
Top-priority (value: 10)
Important (value: 8)
Moderately important (value: 6)
Marginal interest (value: 3)
Not of interest (value: 1)
Changing the importance level can be set using a drag-and-drop style method or by a
traditional drop-down list.
The latter category has the effect of saying „This is not a problem‟, i.e. whitelisting an entry.
It is particularly likely to get used for planning applications that are checked and then
42
determined as not being important. In whitelisting an entry, people are encouraged to add a
comment explaining why, e.g. “I‟ve had a quick look at this planning application and it‟s
only a minor change that doesn‟t affect cycling.” This affects only their own assessment of
the priority, visible only to them.
Priority to the overall group is set by the Committee. In doing this, they will see each
person‟s assessment of priority so that they can judge things. For instance, if 5 people have
all set a planning application thread to „Not of interest‟ then they will see a very low score,
namely “10% reviewed by 5 people” (which presents 5 scores of 1 point, i.e. total score of 5,
out of a total potential score of 50).
Upon appearance as a new thread, issues have no importance attached to them. These will
appear in a specific area of the page, set out in a way which will encourage users to go
though them and prioritise them, thus removing them from the new threads list.
44. Search facility
A search facility, to find threads and information in them, and other things, will be available.
The search will be flexible, so the search will find matches in the title, comments and
elsewhere.
The search will be accessible from the top of any page.
The search can be set to be across all threads of the group, or just those being watched.
An advanced search will also be available, so that more specific searches can be done, e.g.
“User X posting between dates Y and Z”.
The search will show different types of results separately, e.g. threads, documents and info
blocks would each be shown under separate headings.
If time permits, Boolean and phrase search facilities, to enable more exact searches, will be
added.
(Note for implementation: Apache Solr, to provide facetted search facilities, has been
recommended.)
45. Deadline management
A key issue for an effective campaign group is ensuring that deadlines, both for transport
scheme consultations and planning applications, are dealt with in time. Groups will be able
to add key dates and schedule reminders to help them focus on important issues that are
also urgent.
A time-based deadline view of threads will be available to all users.
43
Users can tick a deadline entry in a thread, to indicate that they wish to be notified about
deadlines approaching. This „Reminder‟ will appear as an indicator when they log in (and in
the top „My info‟ bar of the site) and can be set as an e-mail reminder.
Reminders can be set in a customised way. For instance, someone might wish to receive a
reminder “Deadline for consultation response” 5 days beforehand and the day before.
Deadline reminder e-mails will be issued by a scheduler in the morning at 7am so that
people see these at the start of the day when they log in or check their e-mail.
46. Info blocks
Info blocks [Is there a better name?] are widgets containing structured information which
can be pulled into the discussion (literally dragged across the page, so it then appears as a
thread reply).
Info blocks are intended to be factual so that they do not attract argument. The idea of
these is that they are reusable whenever an issue needs them. This avoids, every time,
people having to research things that are already researched.
Types of info block (each of which has its own template) available will initially be:
Infrastructure solution
National guidance (e.g. materials produced by Cycling England, and LCN+
documents, amongst many others)
Local policy document
A legal reference, e.g. to legislation (which should also note whether it is London-
specific, as some transport legislation is)
An Official Policy Position of the group
Case study outlining best practice on an issue
A best practice image (see gallery section described below)
An organisation (e.g. DfT, or a part of a council) and information about its structure
Council officer contacts
Elected Councillor contacts
[What others?]
Creation of an info block will be done in a Wizard-style format, which will require the
inputting of the following (roughly in the order shown) [Though if it is a link, the title could
be derived automatically, e.g. from a Wikipedia page]:
An overall type (e.g. Cycle parking)
A title (e.g. Sheffield stands). The toolkit will try to auto-detect potential duplication
with existing info blocks.
44
Whether this is local or national (in this example, national)
Whether it relates to any other info block, i.e. so they can be linked together
The main details, which could include a photo, web link, Wikipedia link, and
documents, based on the type of info block. [Need further details as to how this is
managed. One stakeholder suggests a wiki approach, with the changelog available.]
Whether this info block can be seen by other groups. For info blocks having a
national status, sharing between groups will be strongly encouraged. It is hoped that
national info blocks will effectively become built-up over time as a community
resource. (Groups such as Cambridge Cycling Campaign are likely to populate a
number of important info blocks early on in the use of the toolkit.)
Permissions for allowing others to edit it [Need further details as to how this is
managed]
Info blocks then become available for use in any thread:
Once an info block has been created, it can be „dragged‟ from one side of the page
into the discussion.
Threads will include a box where info blocks will be auto-suggested based on
heuristic matching (e.g. if „one-way street‟ is in the title, a resource about contraflow
signage will suggest itself, encouraging someone to review it and „drag it in‟ to the
discussion.)
For instance, if someone proposes cycle parking, a type of infrastructure which has a
clear set of best practice associated with it, the “Cycle parking best practice” info
block could be dropped in.
Someone who is not familiar with the contents of the info block can then click on the
icon to see more details (visually, it will appear to expand).
In terms of managing info blocks:
New info blocks can be created by anyone.
Each info block itself has a thread attached to them for discussion and eventual
editing. This will be the place where differences of opinion can be dealt with, though
as noted they are intended to be factual and attract little debate.
Editing will be possible and is determined according to the permissions set. Where a
user does not have permission, they can request it from the original creator of the
info block.
[Should info blocks have a community rating, visible as “Average score X rated by Y
users”, which means that a poor-quality info block created by a user who has left it
uneditable will not continually come up in searches?]
45
47. Library
The Library is the store of best-practice and reference material, accessible from the top bar
of any page.
The library will include the info blocks, examples of best practice, and other things such as
documents will also be here.
48. Galleries of best practice examples
Submissions from users marked as good practice are available for assembly into galleries of
good practice.
Each gallery will be pre-categorised, and images can be added into a category as an
example of particularly good practice for emulation elsewhere. These then become info
blocks that can be dragged into a thread in the normal way.
[Exact UI will need determination. In particular, the need to make clear the difference
between the pre-categorised „good‟ image and an example of best practice (i.e. a more
selective set).]
49. Document management
When documents are added, perhaps as part of an info block, the toolkit will encourage
descriptive summaries to be added about them, and any other details such as a date or web
reference.
This will result in a growing document repository, which can be navigated through in a file-
viewer style view, or via the search, and documents downloaded when wished.
[Should a document automatically always be an info block, albeit with less detail?]
50. [[P3]] Thread branching and splitting
This is only medium-priority for implementation, as it introduces complexity.
A member using the forum view can split a thread into several issues. This is useful if, for
instance, if a discussion about a street has developed into two separate issues. Or a
discussion about a Committee paper includes several different themes. Splitting will work as
follows:
Pressing a specific button that has the effect of splitting the discussion into one or
more new threads.
46
The splitting process requires that new subject lines and categories are created and
that the geographical basis (or lack of it) for each of the new issues is established.
The person doing the splitting (branching) will be required to say whether this is
merely splitting or whether it is creating a „master‟ issue and sub-issues. [Whole
issue of master and sub-issues is not clear.] For instance, a main thread could be
considering a Committee paper, and each item on the paper could be sub-issues. [UI
needs consideration here]
The original thread can still be contributed to. However users [which? – just the first?]
will be warned that it has been split and advise them to follow one of the new
threads instead.
Subscription of the new threads works on the same basis of being geographically or
thematically-related, i.e. users will be auto-subscribed to them in the same way as
any other thread, depending on what the location/category now is.
Split threads copy (inherit, once only) the access control basis of the parent, by
default. So if, for instance, a Local Authority official has been invited into a thread,
they will also be able to see the new thread.
Possible UI solutions for a branched thread could be a „Click to expand‟ button which shows
the contents above the branch point, or a „Click to view‟ button which takes the user to a
different URL.
51. Thread grouping
Threads may need to be grouped together as a „cloud‟ of issues. This is so that issues can
grouped into logical groupings that users can understand.
For instance, a range of issues relating to the construction of a shopping centre could be
pushed into a new „cloud‟ of issues grouping these together. Each issue or cloud then
becomes one entity in terms of discussions and commentary, and divergence of discussion
between several entries is avoided.
[This section needs further expansion – this is the master/sub-thread issue again, and its UI
and consequences need to be defined.]
52. [[P3]] Polls
Members can set up informal polls for the group membership to vote in.
Polls are one-person-one-vote.
Polls are governed by the same privacy setting as everything else in the group‟s toolkit, i.e.
is limited to the group‟s members (however defined).
47
A poll can be referenced by (i.e. attached to) a thread. Multiple threads could refer to the
same poll. For instance, if a helmet-related poll was created, this might get referenced in
many thread discussions.
A listing of all current polls, will be shown. The poll page will show which thread(s) it is
attached to, giving link(s) to them.
It is intended that any discussion around the content of a poll will be had on a thread in the
normal way.
53. [[P3]] Petitions
Members can set up formal petitions, which ask a specific question and accept public
signatories underneath.
Linkages between petitions and threads work in the same way as polls. (Petitions can be
referenced by one or more threads and links will be given.)
It is intended that any discussion around the content of a petition will be had on a thread in
the normal way.
Petitions are one-signatory-one-vote. (Technically, a signatory is ultimately defined by e-
mail address.)
Petitions can be made public, so that such petitions can be referenced in campaign
materials, websites and media reports, etc.
Petitioning is a form of democratically-accountable activity, and so signatories cannot hide
their real names. Forename and surname will be shown. Petitioners can be existing
members of a group on the toolkit (signing while logged in), or members of the public.
With regard to members of the public (as distinct from campaign members) signing a
petition, they are required to include their e-mail address (which will be used only for the
purpose of verification). When confirming the address, they will have the option to create a
user account. [Should this actually be a requirement, which makes things much simpler in
terms of the user account database and simplifies things if people later join a group.]
Where a member of a group signs a petition (rather than an external person who has
accessed this publicly), and the member has set (in their settings) to show their real name as
well as their username, they will be shown as “Name <username>” to other members when
logged in. (Usernames will not be shown outside a login context.)
Petition-creators will only have access to the data that is shown publicly to others and no
more.
Some democratic contexts require that signatories include a postal address. Only current
Committee members of a group will be permitted to see such data. For such petitions, the
address will be auto-filled in (and editable) if the member has already added it to their
profile. If they have not, they will be required to add the address (and then be given an
48
option to save this into the profile also). If the address was prefilled and is changed by the
user, they will also get an option to update the profile. The address field of the form will
include a note explaining the context of petitions requiring an address for accountability.
The person‟s name will be prefilled and editable in the same way. People may wish to have
public variants of their name.
Petitions can be set to be signed only by people living in a certain location, which will be
definable on a map. This is useful for petitions to a specific Local Authority which can only
be signed by residents.
Petitions will have a user-friendly URL with a number by default, e.g. /petitions/25/ . An
optional URL slug can be added, e.g. /petitions/helmets-in-cambridge/ but these will be
unique across all petitions created by any group. Therefore, one-word URL slugs will be
disallowed to reduce the likelihood of namespace clashes.
Petitions are „owned by‟ a group. Accordingly, someone accessing it from
<anothergroupname>.example.com/petition/<moniker>/ (by typing in this address
experimentally) will be redirected to the group‟s URL.
54. [[P3]] Dealing with disputes
[[P3]] This section is P3 but the defamation issue needs to be considered as we are
publishing material.
Cycle campaigners sometimes deal with very divisive topics (e.g. „helmets‟) and so heated
disputes can occasionally arise. It is important that unproductive users do not drain
enthusiasm of others.
The toolkit will work on the basis of trying to encourage cordial and polite discussion, even
where views are divergent.
In dealing with disputes:
Disputes within groups are entirely managed by that group and not by CycleStreets.
Committee members can ban disruptive people, with the process for this being
determined according to a policy in the settings.
Users can report abuse to the Committee via a button on the page. This „report
abuse‟ feature means that a swearword monitor for auto-detecting problems is not
necessary.
Thread discussions are never moderated, because they are not public by default and
therefore visible only to the group themselves. People can easily unsubscribe if they want to,
by unticking the thread.
Committee members can close or re-open a thread. [How does this affect the prioritisation
listings?]
49
Where a member is acting abusively, and action is taken to deal with the specific replies in
the thread that are problematic:
Any removal (actually blanking out) of an individual thread reply will be clearly
marked. For instance, “This reply made by [name] was removed by [committee-
member-name] at [time/date].” This is important if, for instance, a defamatory
remark or highly sensitive material has been made that should not continue to be
seen by others. This is done purely to avoid the website being sued for continued
hosting of defamatory text.
Because some members may have subscribed to a thread by e-mail, an abusive
posting will already have been sent to their inbox. This cannot be undone therefore.
A StackOverflow-style reputation system was considered but would just add additional
complexity and more buttons, so will not be included.
[Are there any governance issues here?]
50
Section G: Integrating different source of data
55. [[P3]] Linking with a group’s public e-mail address
Because an aim of the toolkit is to provide a „one-stop-shop‟ for managing all areas of
campaigning for a group, irrespective of how the problem has been reported, the toolkit can
accept and process incoming e-mail from a group‟s public e-mail address(es).
To set this up, the group‟s e-mail account must allow mail to be forwarded to another
address. (Gmail and many other systems allow this.) A committee member for the group
would go to their group‟s control panel in the toolkit, add the group‟s e-mail address, and
the toolkit will specify the e-mail address that the group should have their existing public
e-mail address forwarding to. [Or should IMAP login details be specifiable?]
A future feature would be that groups would be able to set up real mailboxes on the toolkit
and point its DNS record to the toolkit, so that, e.g. [email protected]
would be directly processed by the toolkit.
The incoming mail can be responded to. In this scenario, the reply goes to the
correspondent and is also treated as a thread reply.
Incoming mail gets turned into a thread like any other. However, these threads are treated
as initially available to the Committee or specified members only. The recipients can migrate
them to public threads („Set as normal thread for group discussion‟) in the same way as
managing any other thread, by adding a category and/or geographical location. In doing so,
they will be reminded of the importance of ensuring that personal data is not transmitted to
others, so a facility to strip e-mail addresses and names will be available.
56. Planning applications
Dealing with planning applications can often be an important part of cycle campaigning but
one easily overlooked. New developments, whether small localised changes, or major new
developments, affect travel patterns for decades. In this regard:
Planning applications will become threads, in the same way as anything else.
Where deadline information relating to a Planning Application is available, this would
automatically be set in the deadline management controls noted above.
This will use the Planning Alerts API, detailed at http://planningalerts.com/apihowto.php.
This currently seems to be paused for updates, and the site maintainer have been contacted
about this. It is understand that work to reinstate operation is being undertaken.
51
57. [[P3]] Importing data
[[P3]] Very low priority as it‟s unlikely there would be much data, and we could just import
this manually for now.
Groups may have existing datasets of e.g. cycle parking locations or other databases. Tools
will be added to enable these to be imported so they become threads like any other.
The importing tool will be a simple webform that requires a spreadsheet to be pasted in (so
that the data is then interpreted as tab-separated values).
Data imported in this way must then all have titles (and other similar thread requirements)
added before it becomes available. The importing tool will enable such titles to be added.
Sometimes this could result in hundreds of new threads appearing at once, cluttering up
other data. Data imported will have a tag associated with it so that users can filter out large
datasets easily. [Tag concept needs further expansion.]
Importing screens will make clear the question of IP rights. Some people might have large
databases that they might not want used by others in certain ways (e.g. no commercial use).
58. [[P3]] External data layers
Additional static layers can also be switched on for information purposes, in the map view,
to give context to issues in the surrounding area.
These could include:
Cyclist collision locations (subject to availability and licensing compatibility by area),
although a warning will be shown as to the limitations of such data (e.g. under-
reporting and variability by year)
Potentially transport-related crime (if available)
London Cycle Hire locations.
Permeability analysis (also called accessibility analysis) [which is basically a whole set
of work itself and lower-priority for implementation.]
52
Section H: Sharing information with others
59. Sharing best practice between groups
Groups will be able to mark an issue as being of particular interest to other groups
elsewhere in the country. For instance, a campaign involving a successful set of tactics (e.g.
allowing cycling in a pedestrian zone, as happened in Cambridge for instance) could be
sfhared with other groups.
In this instance, a user can add a „Case study‟ entry as a type of info block and set the case
study as public.
60. Engagement with Local Authorities
Engagement with Local Authorities will be crucial for effective campaigning in many cases.
As noted above:
Committee members of groups can invite their LA officer/Councillor contacts into
discussions (threads). They specify whether a thread‟s earlier replies (archives) are
visible.
Groups will also be able to make compiled data available to Local Authorities. This
will „close the loop‟ from submission of material, through campaigning, to action.
Councillors could be contacted by members individually directly, as noted in the
section on types of content in a thread.
During the consultation phase on this spec, it was mentioned by a Local Authority Cycling
Officer that officers are likely to be guarded in their responses, unless the issue of a factual
nature only. Also brought up was the issue of a campaign group having access to an officer
in a way that other groups do not. Over time, these issues may change, as the localism
agenda encourages closer working between community groups and local councils, and
hopefully as the toolkit encourages productive and open working practices
The consultation also found an officer view that it is better from a LA officer perspective for
the campaigners to make clear what the problem is, rather than give a solution. For
instance, “Hard to cross the road”, specifying the type of people crossing, the time of day,
etc. Helps provide assessment criteria. The toolkit should therefore make attempts to help
campaigners elicit: (i) Justification, (ii) Knowledge and (iii) Context.
53
61. [[P3]] Publishing
[[P3]] This is a rather open-ended section so is marked as P3 and people can manage
without this, but it will be time-saving so would be good to implement at some point.
Groups can publish „What we‟re working on‟ pages based on the prioritised issues, using a
variety of preset templates, and generated dynamically.
[Needs further consideration as to how the info about these is generated. E.g. title +
summary or more detailed, with pictures, etc.]
These will be available as public page components (effectively HTML snippets) that can be
added as iframes/HTML-via-PHP/JS importing into another page, e.g. the group‟s website.
[Should these be available on the toolkit page itself?]
As issues (threads) are resolved:
The campaign group would mark it as resolved, either successfully (and giving
themselves some credit) and adding a new photo superseding the issue, or
unsuccessfully (giving reasons why – as that will help the public understand why the
problem remains and will thus be less likely to complain in future). This will show on
the public map submission page.
The CycleStreets journey planner has a Photos-en-route feature, whereby journeys
planned along the route show photographs submitted by users. Where a
successfully-resolved issue is on such a route, a message along the lines of “Cycle
infrastructure here has been improved thanks to campaigning work by
<groupname>”, together with the group‟s logo, will be shown. [How will it determine
shared-group success?]
Markers on the map change colour (e.g. red to green).
A variety of attractive views of the resolved locations will be available, so that
campaign groups can easily point people to the effect of their work, i.e. the
outcomes that result when people join and get involved in their group, thus helping
increase membership.
62. [[P3]] Exporting data
[[P3]] Lower-priority as there will not be huge demand for this.
Groups will be able to export sets of data at any time. The data that can be exported is:
For entire category „All cycle parking problem locations‟
Area-based
Search-result based
54
For the-area based export, this will need to be a simple box or area boundary. However, in
future it is hoped, subject to funding, that this will be expanded to allow areas within the
Transport for London Road Network (TLRN) area only.
Data export formats will be:
Published as public page components (see next section)
As a spreadsheet (CSV file, which will open in Excel)
KML (Google Maps view)
GeoRSS will also be considered.
In each case, fields (from the standard requirements of a thread) will be specifiable (e.g.
title, description, outcome summary), with a default sensible set defined.
Users will be able to export „My postings‟. This will be of relevance to external council
officials who might be required to answer an FoI request. This will contain the thread title
but not others‟ postings. [Does this resolve FoI requirements?]
„Export all group info‟ will be available to Committee members:
Groups will be able to export their entire set of threads (i.e. the entire dataset for
their area), including discussions, to e-mail, to avoid any suggestion of lock-in. In
practice it is hoped that the toolkit will be so good that this would hopefully never
need to be used.
Export to e-mail will be in mbox format. Other formats could be added in future.
Full export may take a while to generate and is likely to be implemented as a
scheduled job, run overnight.
55
Section I: Event management
63. [[P3]] Event management
Arranging campaign meetings and ensuring that people attend Council committee meetings
is often an important part of cycle campaigning. The toolkit will therefore include a module
for managing events.
Users will be able to create events. They will:
Add details of the event
Specify whether this an internal or external meeting
Determine whether it can be openly advertised
Be able to set up Doodle-style polls for finding the best time
Include a map showing where the meeting is, which will have an automatic „Cycle
there‟ journey planner link available
Other campaigners can then say they are attending the meeting. The list of those going will
be shown.
Each event also has a thread attached to it, so that it can be discussed in exactly the same
way as other threads. For instance, if a Council meeting has been added, campaigners will
often want to discuss things on the agenda. These can be branched into multiple issues
(threads) in the usual way.
Event listings can be exported as public feeds in RSS, iCal (which is compatible with Google
Calendar), and HTML formats (retrieved as a .js file, for adding directly to a page and then
styling in the site‟s usual style). These exports will not show attendees, for privacy reasons.
64. Deadline management
Deadline management is discussed in a section above.
Deadlines can also be added as public events, e.g. to encourage members of the public to
respond to a consultation.
56
Section J: Privacy and security
65. Privacy
The toolkit will have high regard to user privacy.
Full attention will be paid to data protection issues.
User profiles need contain no more than username, postcode and routes where supplied by
the user, plus association with a campaign.
User data, especially real-life routes, will not be shared with other users except if the user
choses to do so. As noted above, users are required only to reveal their username to other
users, though they will be encouraged to reveal their real relname in the interests of
accountability.
Those users who opt to receive threads via e-mail will not see others‟ e-mail addresses,
even if the user profile of the other user(s) has set to allow their e-mail address to be visible
on the website. This is both to improve security but also to discourage e-mail conversations
taking place away from the site, which will split conversations and therefore alienate other
users. If users really need to discuss things directly, they can use the private messaging
facility to send a message.
User contributions are their own copyright.
The toolkit will remind all users, in a variety of ways, that discussions should be considered
confidential to members (and other discussants where external people have been invited
into a thread), unless agreed by others, in the same way that quoting and forwarding of an
e-mail should be done only when permission has been sought from its author, under the
standard principles of netiquette.
No financial data is needed by the toolkit and indeed this would be undesirable to store.
66. Security
Password security will make use of industry best-practice:
Passwords will be stored hashed, with a salt.
Users can request a password reset by entering their e-mail, which will send them a
link to change it.
When a password has been changed in any way, the user will be informed by e-mail.
Passwords will never be sent by e-mail, which is an insecure medium.
The system will be patched regularly.
An off-site backup will be made regularly and stored securely.
57
Data will only be transferred in an encrypted manner, e.g. using SSH or SCP.
Sections of the site dealing with user login (and therefore passwords) will run under HTTPS.
CycleStreets will run the toolkit according to the requirements of the Data Protection Act and
be registered accordingly.
Financial information of any kind will not be stored on the system.
58
Section K: Ongoing management of the toolkit
67. Ongoing management of the toolkit by CycleStreets
CycleStreets Ltd will be the legal body administering the toolkit.
CycleStreets will run the toolkit according to the requirements of the Data Protection Act and
be registered accordingly.
The ongoing development of the system will be on a project group basis, with members of
the cycling community coming forward to deal with bug fixes and new developments.
CycleStreets itself is likely to allocate some time to it.
68. Costs
The funding of £27k is intended to cover the initial development and bugfixing of the
toolkit and hosting for three years. The hosting amount shall be reserved within this figure.
No business plan exists beyond this three-year period. However it is believed that a popular
system will attract funding.
It is possible that the system could be cross-subsidised by co-hosting with CycleStreets
infrastructure.
Disk space is the only major financial cost, as the system is otherwise is a fairly standard
web application stack with few special requirements (compared to the CycleStreets journey
planner, which needs relatively large amounts of dedicated RAM and CPU for fast planning).
Disk quotas are discussed earlier and the idea of a charge if groups require excessive
storage should avoid high disk costs becoming an issue.
The toolkit is likely to be hosted on a server by Mythic Beasts. By way of background
information, costs are here: https://secure.mythic-
beasts.com/control/fcgi/customer/serverorder
[Further details to be added.]
59
Section L: Technical matters
69. Data sources
A variety of data third-party sources will be used:
An OpenStreetMap tile base, probably OpenCycleMap, will form the map base
OS Boundary-Line Open, used to ensure that the campaign group gets only material
relevant to the Local Authority/Authorities they exist within.
OS CodePoint Open, combined with OSM Nominatim, to form the Gazeteer
Databases constructed by local campaign groups (LCC, CTC, Cyclenation, etc.)
subject to their interest and data protection considerations. (This would not involve
any member details.)
The existing CycleStreets Photomap database (including data from customised GUIs
such as CycleParking4London that write to it).
Database of elected political representatives, e.g. Goveval (would incur licensing
costs)
Planning applications, as discussed above
In terms of issue<>boundary mapping, the following might be of relevance during
implementation:
The National Streets Gazetteer data is the only thing that accurately links roads to
the highway authorities that are legally tasked with maintaining them
On the issue of excluding TLRN roads from London borough listings, the same issue
applies for Trunk Roads and Motorways (perhaps the latter is less important for
cycling-only application though).
The OS Boundaries also tend to travel down road centrelines, as they've
administrative boundaries for properties, not roads. (Not necessarily a big issue.)
FillThatHole has Highway Authority boundary data. It is mostly logical, with Unitary
Authorities or County Councils being the Highway Authority, but there are a few
oddities. Some Highway Authorities like to split their reporting by District too. Then
you have Trunk Roads, and railway crossings also.
70. Browser compatibility
All development will be on the basis of progressive enhancement, i.e. the site will be usable
for older browsers (i.e. IE6) but drag-and-drop style functionality and other advanced use
will be available only in standards-conformant browsers.
60
By way of an informative: Local Authority users are much more likely still to be using IE6
compared to other users.
71. Relationship with the CycleStreets Photomap API
The CycleStreets Photomap API will form the basis of submissions.
[Needs expansion – which is the master database, i.e. which direction does the API flow?]
Threads simply reference (hook on top of), rather than alter, the initial submissions
(„issues‟) made by the public.
It is believed that extension of the CycleStreets Photomap data towards this wider-ranging
system would be acceptable use in terms of intellectual property. [Needs auditing.]
72. Developer API and source code
[[P3]] An public API covering some components (e.g. submission, export) will be made
available so that more mobile apps and external data inputs can be made created.
[Further consideration needed.]
Code will be open source.
Documentation on installation will be needed, so that groups ultimately have the option to
install it themselves if they want, although that loses the sharing focus of the site.
The underlying software, that encompasses the notion of discussion in a geographical
context, with best-practice sharing, will be developed with its own codename, (e.g. geokit,
geocracy, geomocracy, or similar). This is because the problem domain could ultimately be
similar to other communities of interest, increasing the opportunities for code maintenance
and new features to be brought in from outside the project. The URL/implementation aspect
of this codebase will have its own cycling-related name (as described above).
61
Section M: Priorities for implementation
73. The specification: priorities for implementation
The specification outlined above contains a lot of features.
This specification will be turned into a formal coding specification at the start of the
implementation process.
During that process, feature priority will be formally defined. Roughly, it is expected that the
priorities will be as follows:
Top priorities:
Group basis and management
User registration
Plot-my-route (part of user registration)
The core thread concept
Mail-to-web gateway (important)
Prioritisation
Info blocks and the Library
Usability
Deadline management
Search facility
Medium priorities (could be delayed implementation):
Thread branching and splitting / grouping
Event management
Dispute management
Reporting and exporting data
Publishing modes
Cross-group / cross-boundary sharing
Polls and petitions
Best practice galleries (as info blocks provide some of this)
Planning application data importing
External data imports
Prioritisation by cost range
62
Supergroup implementation
Lower priorities:
Public commenting
Accessibility analysis module
Developer API
Cloud storage integration
74. Potential expansion
The following features could be added:
Merging in of another thread – this could be done as another type of thread reply
that references another thread and closes that external thread down. This will be
most useful for marking things as duplicates to avoid discussion spreading between
multiple threads. In the meanwhile, a Committee member could mark it as closed.
Membership joining / payment / management system (though this opens up many
security issues).
A simpler possible future development of the membership concept is the addition of
an expiry date of a member as an additional field in the textbox/CSV of members.
This could then enable a grace period setting, meaning that people will be reminded
that they need to renew (and be given a link to the group‟s website, where details are
given) but still be able to post in that period. After this, they will be locked out. The
use of dates is not proposed at present as this would make the toolkit have only
some, but not all, features of a membership system.
A future development might be full API integration with systems like CiviCRM, both
for validating members and for obtaining lists of who could be encouraged to
become a member.
Groups would be able to set up real mailboxes on the toolkit and point its DNS
record to the toolkit, so that, e.g. [email protected] would be
directly processed by the toolkit. This is more advanced than a mailbox that has to
be specially forwarded to, as it means implementing a lot more editing functionality.
Invitation of externals/internals into threads could be auto-suggested based o their
presence in other threads. (May not be necessary for internals though as the tagging
system may deal with this anyway.)
For the area-based export, it is hoped, subject to funding, that this will be expanded
to allow areas within the Transport for London Road Network (TLRN) area only.
63
Integration of the elections system created for Cambridge Cycling Campaign at
www.camcycle.org.uk/elections, which is used to send pre-formatted questionnaires
to election candidates at election time, and to compile the results automatically.
Questionnaire module.
Interfaces: it would be ideal if this system could talk to other more-specific systems
like FillThatHole using documented APIs and data formats.
Consider integration with Open311.
Ability to create custom CycleParking4London-style iframe submission portals?
