cyclestreets / cyclescape Goto Github PK

/issues shows all issues irrespective of the subdomain at present.

However, when in e.g. http://camcycle.cyclescape.org/issues/ the issues list shows stuff well outside that area.

The listing should therefore limit by the group's geographical area when in subdomain context, and add in a sentence:
"You can also view the full, UK-wide list of issues."

A private messaging system is needed so that a user can message another user to suggest that they subscribe to a thread.

People are by default subscribed to things in their area, but notified of others in their group.

The latter generates an e-mail (assuming they have e-mail subscription on). However, the similarity of this e-mail to the first type (auto-subscribed to thread) means they may assume they are subscribed.

So this e-mail must be made totally clear that they need to subscribe.

Perhaps have it in a format like this:

A new thread on the issue "%issuename" has been
created by %name, as shown below.

You are NOT subscribed to this discussion as
it is outside your area. Subscribe at:
%link

%thread-description

Tag updates spend more time in the database than any other request, on average.

It's not immediately apparent why this is the case - whether that's fetching the existing tags, or inserting new ones. For info, there's currently 523 tags in the table.

Although not too bad considering the amount of stuff involved, the dashboards are a bit on the slow side. Perfomance is (mean) request / rendering / db 1.35s / 1.18s / 0.20s

We should consider cutting the amount of stuff shown on the dashboard, or lazily loading panels, or splitting the dashboard across multiple pages.

Library tags are awkward to add (and therefore easy to miss) as they currently have to be set outside the main process of adding a library item.

Each library type therefore needs the tag-adding input widget (with autocomplete as in issue #20) on its main creation/editing area.

I understand this is because the library system is structured as a generic-container + type-specific implementation, meaning that the tag. Presumably this can be overcome by adding the tags and writing them to the container just after the last insert ID has been obtained.

OpenLayers is by far our largest javascript, and takes some time to download and parse. Either use the light build (for a 60% saving) or, if needs be, make a custom build.

As well as the ability to add library items using a dedicated GUI, there needs to be the ability to 'promote' an existing message to a library item.

This should be done by use of an 'Add to library' button/link next to each message of the relevant type (i.e. not deadlines for instance), that will clone the message details into an editing pop-up layer, which then enables the user to edit this to be as generic as possible, add tags, etc.

A major usability issue at present is that users have to scroll down through often many messages to view the last unread message, and there has been much feedback on this.

Three solutions are possible, but only the third here should be done as the others are problematic

1. Add pagination - avoid as this makes Control+F searches unworkable and hides the context
2. Show latest-first - avoid as this people read discussion-based material from top-to-bottom and several unread replies are then missed
3. Auto-scroll to the last unread message - do this.

Clearly this means that a database table storing the user's last-read message for each thread is needed.

This could do something clever like storing the exact page position, but in practice this may not work because users may use more than one computer (or mobile device) to access, and different screen sizes, etc., will mean inconsistencies over time as the design is developed.

There is currently a 'friction' in starting a discussion on a fresh issue that has come to mind.

If, for instance, cycle parking at a location is need, the process is

1. Click New issue
2. Add the issue description
3. Click New thread
4. Start the thread with its first message.

This does not compare well with an e-mail list:

1. Compose the e-mail and press send.

There is also the problem that we end up with issues that have no discussions attached to them.

A suggested solution is that creation of a new issue should also start a new thread with the description being the first e-mail.

The only problem here is that the issue description should be relatively dispassionate (as a short, to-the-point description), whereas a thread is a more subjective discussion. Perhaps the solution is to have a sixth box on the new issue page which forms the message box for a new thread. Labelling would be needed to make clear what the difference between boxes 5 and 6 are, but that would probably avoid the current problem of occasional long descriptions. Box 5 could be made smaller to emphasise the need for short descriptions.

Users who are not so active (and therefore less aware of existing discussions) may add issues that already exist.

For this reason, at the point of adding an issue title, Cyclescape could have a semantic name matching. Likewise, the map view should have a button that says 'Show existing issues' that adds the existing issues nearby.

Sometimes the user may have deleted earlier e-mails of a thread, so they don't know what to e-mail to.

Similarly, if the user has been sent an e-mail with attachment from a third-party, they might want to send the message to the thread simply by forwarding rather than having to detach the e-mail, upload, and copy and paste the text. If the e-mail address is stated, they can do that easily.

So we should just show the e-mail address on the page.

The group or front page is not very useful to users once they are signed up. At present people routinely have to click on My Cyclescape so they see their personalised lists.

Therefore, when the local path is / at the point that the user signs in, successful sign-in should take them to /overview .

Google Street View is need in three places:

• Setting of a location as a message reply type. Campaigners will undoubtedly use this heavily. It should result in an iframe directly, not a link elsewhere.
• A button under the issue map which opens a div underneath showing 'Street View here'.
• Ditto, under the map on the thread page

This enables people to get more context easily about the issue, as well as helping newer campaigners to familiarise themselves with the location.

The location should obviously default to the issue's location.

Key problem is how to handle large area-based issues. As a first iteration:

1. For large areas, state that 'The area is too large' to create a Street View location.
2. For smallish areas, take the centre-point.
3. For lines, take the centre-point of the line
4. For point-locations, obviously just take that location.

Setting of a location in the message-reply type will need a map view and the streetview panel next to it, with the location matched in real-time as the location is dragged, enabling people to get an accurate location first time.

The two geometry.json calls (IssuesController and via Group::IssuesController) account for a whopping 75% of the requests to the site.

On average these are fast to create (0.08s) but can also be reasonably slow, up to around 30 seconds for some requests.

We need to:

• Figure out why some of these requests are so slow. I doubt there are all that many particularly complex geometries involved
• Aggressively cache these requests - the geometries very rarely change after being created
• Consider in-lining the geojson on the relevant pages. This would ruin any caching, but massively cut (by, er, about 75%) the number of individual requests made when browsing the site.

The group page design needs to be finished.

Creating messages accounts for the top 5 slots on the slowest average requests.

I think the photo and document message creations include the file upload times, but even plain messages are taking on average more than 4 1/4 seconds on average to process before redirecting.

E-mails do not appear threaded because there is no in-reply-to header.

In the case of replies via the website, this is always the last message, since there is no notion of quoting at present.

In the case of replies to e-mails, clearly these have a context so the reply-to address should be crafted so that the in-reply-to can be determined and stored in the database, then used by the queue to emit the e-mails.

At the moment you just get the garish pink openlayers background

When a person is promoted to a group admin, they should get the
"Also involve me in my groups administrative discussions"
box ticked for them.

Almost by definition, if they are running the group, they should see administrative discussions by default.

The /user/locations page shows the following text:

You can create locations for where you live, your route to work, where you like to go riding, and so on. This helps us figure out which issues are revelent to you, and which groups you might be interested in.

The word "revelent" should read "relevant".

The deadline/date view (the fourth tab on the My Cyclescape screen) at
http://camcycle.cyclescape.org/overview
shows e.g. "posted 23 days ago".

This should instead show the number of days until the deadline, as that is more useful to the user to know how many days they have left to take an action such as writing a document. If the deadline is today, then it should say "Today".

Tagging is currently rather haphazard and non- self-explanatory as there is no naming authority control (so we end up with 'cycle parking', 'cycle-parking', 'cycleparking', etc.). Autocomplete will resolve this. It will also make this feature much more self-explanatory and fun/attractive for users.

There are mixed views on whether tags should allow spaces or not. Personally I feel they should be, with comma separation as the way the user indicates the separation. Users ideally shouldn't have to create 'computery' looking strings like cycleparking when the natural language is 'cycle parking'.

I've used this plugin before and it's pretty good:
http://loopj.com/jquery-tokeninput/

and there are other implementations:
www.google.com/search?q=facebook+style+auto+complete

There should be a gallery of all the groups on the system at /groups .

It should show the name, geographical remit, and a link to what is currently the front page of that group at e.g. http://camcycle.cyclescape.org/

Once created, this can then be linked to from places such as the red groups box on the front page.

At the moment OpenLayers is served directly from the public folder, without an Expires tag. Rather than setting up an Expires tag, and then faffing around whenever we need to change it, it would be best served via the assets pipeline.

We've tried this before and didn't get it working, but OSM has managed it somehow.

The login form frustratingly does not have autofocus on the first widget.

The HTML5 autofocus attribute should be added, with JS fallback for the majority of users that do not use browsers supporting this yet.

The Cambridge view of the map isn't working well now because large issue areas are compounded on each other, resulting in no visibility of the underlying area.

A suggested solution is to make issues that are beyond a certain area size have no opacity.

The My priorities list in My Cyclescape at
http://camcycle.cyclescape.org/overview
(third tab) needs the ability to set the priorities for an item directly.

This should use the same radiobutton set as proposed in issue #16.

In particular, it must have the ability to unset the existence of a priority, as otherwise the list grows and grows, accumulating things which have already been dealt with and therefore not even the lowest-possible priority.

Showing threads accounts for a large proportion of requests, but take around 1s on average to show. Most of this comes from rendering time rather than db calls.

This might be improved when we move to paginated threads.

http://camcycle.cyclescape.org/tags
should have a browsable index to each tag such as
http://camcycle.cyclescape.org/tags/cycleparking

Perhaps in future a tag-cloud interface could be added, as per
http://www.cyclestreets.net/photomap/tags/

Front page design is not fully-implemented yet.

When an e-mail is owned by a group, the link to this should have the group's subdomain, not www

E.g. thread 421 is private to the Camcycle group but the New thread e-mail (and presumably replies) will have
http://www.cyclescape.org/threads/421
at the end.

It would be useful to be able to see CycleStreets Photomap items in the same way that the collisions data layer is selectable.

The API is as at:
http://www.cyclestreets.net/api/v2/photomap.locations/

Each page has a footer with the text "View the source at GitHub". This incorrectly links to:

https://github.com/cyclescape/toolkit

instead of:

https://github.com/cyclestreets/toolkit

If you view a group page, and you're not a member of the group, you get given a bunch of confusing text.

Join our Cyclescape group

To take part in discussions and threads here you will need to join the Some private group first. We can then provide you with access details to this site.
Join this group

This is because the current situation is a bodge between letting people join the group, and some text that's customised for Cambridge (where you have to join the real-world Campaign, pay your dues, and then get access to the Cyclescape group).

We need to alter the website so that each group can clearly explain their joining policy, and either allow / deny / discourage / encourage people to press the "Join this Group".

Discouragement would be where you might need to join the real-world group first, but then the group ask you to press the join button rather than doing the admin work of inviting members themself.

At present, setting a priority on a thread involves using a select drop-down and then pressing a button.

This feature is something that we want people to be able to use for many threads so this becomes a more useful feature. Accordingly, it should not require much effort.

Therefore, this should changed to be a set of 6 radiobuttons:

 X          X        X        X           X                      X
Very low   Low    Medium    High      Very high            No priority

Clicking should immediately set the priority via Ajax, which (for accessibility) should override and hide a standard submit button under the radiobutton set and intercept the post.

Default should be No priority. It should not be 'Medium' as people should only set a priority for things they are actually interested in.

In particular, it must have the ability to unset the existence of a priority, as otherwise the priorities list grows and grows, accumulating things which have already been dealt with and therefore not even the lowest-possible priority.

Funder logos and links must be added to the footer of the site by the launch in October.

The model of subscription based on areas, and the use of various settings to control e-mail, are important for the effective use of the site by users.

At present, although there are links, users needs to be introduced to the area-setting in particular clearly.

Upon creating an account, the link to this should be clearer and more pictoral possibly, as should the My Cyclescape dashboard.

Map-drawing is broken in IE6-8 due to a JS error.

Fix by using the further-developed version of the JS file, at
http://www.cyclestreets.net/geometrydrawing.js

This requires a slight change to the caller, in that a default control (search for this.default_control) is supplied rather than a boolean. This makes it more flexible for the future also.

If you find cyclescape, try joining a group and the group decide to reject your membership, there's no opportunity for the committee to explain why - e.g. pay your dues first.

You also don't get a notification of the rejection.

At present, there is no way to view other issues nearby the current one without going to the main issue view and manually browsing to the same location.

In the same way as the collision data view (#32) and planning application view (#33) both need buttons next to the map (see #34 for the principle of this), 'Issues nearby' could be another such button, enabling this layer.

Thread messages already have an ID being generated in the HTML, meaning that direct links such as
http://camcycle.cyclescape.org/threads/417#message_3566
already work.

This should be exposed in the HTML by adding a # link next to each message.

In the process, the underscore in the ID should be removed as underscores should be avoided in URLs because of their confusion with underlines when printed.

Planning applications, once the importing work is done, need user interfaces:

• A browsing interface, basically a isting and browsable map map as another tab on the Issues page. Would have bubbles that have a button which links to a form to clone these into an issue. If an issue has in fact been promoted already, the button should instead be a link to the issue instead.
• Clone to issue interface, which just pre-fills the issue.

A specific problem is that the issue needs to have a URL associated with it. To get this running quickly, for now just add \n\n + the link to the external URL at the end of the issue description.

Any user should be able to promote a planning application to an issue.

The layer selector in the top-right of the slippymap is not very discoverable.

Therefore the functionality should be enabled by links just above (or next to) the map.

I suggest a simple link with CSS such as

li {display: inline; margin: 0; padding: 2px 4px; color: gray; border: 1px solid #ddd;}

All instances of the slippymap should have the external data views.

(At present the only such layer is the collisions layer, but CycleStreets Photomap (see issue #213) browsing, is proposed as another. More may be added in future.)

Currently the external data layer only appears on an issue page, like /issues/805-holyrood-crescent-to-butterfield-lane but is not present on its component thread(s) pages, i.e. /threads/1000 .

LCC and CTC both need the ability for mass-import of member details, ideally using the supergroup notion in the original spec.

The proposed system for this is:

1. Group admin can go to a panel and paste in all members' e-mails, and press submit
2. Cyclescape creates a hash of each e-mail, stores it in a table of these hashes (id,hash,groupId) but does not store the e-mail, to avoid data protection and security issues
3. When a person registers, a hash of their e-mail is created
4. If the hash matches any hash(es) in the hash table, they are subscribed automatically to that group(s), or asked to confirm that they want to join (probably best)
5. A message is shown confirming they have been access to the group(s)
6. The group admin can re-paste the e-mail list in at any time, which removes all the hashes with that groupId and creates a new set.
7. Where a member has become removed from the list, they are deemed no longer a member and so in some way need to be de-attached from the group's privileges.

The idea of the supergroup concept is that every group (Bromley, Kingston, etc.) shouldn't have to get a list of members from the LCC head office. The LCC head office should just be able to maintain this once, and the child group code effective gains that privilege.

None of this should stop groups adding people themselves directly.

Groups would presumably need a setting that says "Automatically accept people who are members of the %parentgroup".

Clearly there are some things here that need discussion, but the aim is very much to enable large numbers of people who are members of say LCC and CTC to get going quickly and working with their groups with very little friction to get started.

At present, if I need to suggest to a user that a setting is wrong, I have to e-mail them as follows:

"Please click on your user name (top right), click Edit my preferences button" (and then something like "tick 'Also involve me in my groups administrative discussions' and press Save."

Instead this first bit should read

"Please go to http://www.cyclescape.org/settings to fix this."

which will work for the user signed in.

When threads are put in the wrong issue (e.g. due to duplicate issues), it is important that group admins are able to reattach it to a different issue.

This could be done, as a first iteration, by adding a link to a 'Reassign to issue...' link in the small cog panel.

There also needs to be a means to move an administrative issue into an issue. In the process, it should acquire its geometry and subscribe those not already subscribed. If the latter is difficult, just the ability to move it to an issue should be a first start as this will help reduce down the amount of 'administrative' matters so that they really are just administrative.

The library items should basically have the same structure as existing messages, and therefore have a greater range of types.

The absence of a link type is particularly keenly-felt. Putting a link within an unstructured block of text is not really sufficient.

The library addition UI box should have tag-based filtering by default, rather than just showing the most recent type.