cyclestreets / cyclescape Goto Github PK
View Code? Open in Web Editor NEWCyclescape - cycle campaign group toolkit
Home Page: https://www.cyclescape.org/
License: MIT License
Cyclescape - cycle campaign group toolkit
Home Page: https://www.cyclescape.org/
License: MIT License
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:
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.
The group page design needs to be finished.
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.
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 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;}
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.
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.
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.
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 .
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.
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/
Planning applications, once the importing work is done, need user interfaces:
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.
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 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.
Request duration - by sum | Hits | Sum | Mean | StdDev | Min | Max | 95 %tile |
---|---|---|---|---|---|---|---|
Group::IssuesController#geometry.JSON | 300379 | 6h22m53s | 0.08s | 0.34s | 0.01s | 30.95s | 0.01s-0.33s |
IssuesController#geometry.JSON | 132087 | 2h49m25s | 0.08s | 0.41s | 0.00s | 34.93s | 0.01s-0.83s |
We need to:
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
This does not compare well with an e-mail list:
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.
At the moment you just get the garish pink openlayers background
Tag updates spend more time in the database than any other request, on average.
Database time - by mean | Hits | Sum | Mean | StdDev | Min | Max | 95 %tile |
---|---|---|---|---|---|---|---|
Issue::TagsController#update.HTML | 47 | 17.47s | 0.37s | 0.68s | 0.00s | 3.87s | 0.00s-3.91s |
Library::TagsController#update.HTML | 27 | 7.16s | 0.27s | 0.34s | 0.01s | 1.30s | 0.01s-1.31s |
MessageThread::TagsController#update.HTML | 51 | 13.18s | 0.26s | 0.59s | 0.00s | 3.06s | 0.01s-2.49s |
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.
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.
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.
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 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".
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.
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 .
Each page has a footer with the text "View the source at GitHub". This incorrectly links to:
https://github.com/cyclescape/toolkit
instead of:
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
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/
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.
Google Street View is need in three places:
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:
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.
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
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.
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.
Front page design is not fully-implemented yet.
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.
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.
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.
A private messaging system is needed so that a user can message another user to suggest that they subscribe to a thread.
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.
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.
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
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.
The library addition UI box should have tag-based filtering by default, rather than just showing the most recent type.
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.
If you view a group page, and you're not a member of the group, you get given a bunch of confusing text.
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.
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.
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.
/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."
Creating messages accounts for the top 5 slots on the slowest average requests.
Request duration - by mean | Hits | Sum | Mean | StdDev | Min | Max | 95 %tile |
---|---|---|---|---|---|---|---|
Message::DocumentsController#create.HTML | 49 | 8m08s | 9.96s | 17.21s | 0.01s | 1m12s | 0.02s-1m12s |
Message::PhotosController#create.HTML | 72 | 6m08s | 5.11s | 9.89s | 0.00s | 36.27s | 0.01s-34.99s |
MessagesController#create.HTML | 1955 | 2h18m44s | 4.26s | 8.51s | 0.00s | 1m06s | 0.03s-33.34s |
Message::DeadlinesController#create.HTML | 82 | 5m21s | 3.91s | 6.76s | 0.02s | 33.43s | 0.03s-25.35s |
Message::LinksController#create.HTML | 201 | 12m05s | 3.61s | 8.34s | 0.00s | 46.60s | 0.03s-34.99s |
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.
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".
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.
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.
Funder logos and links must be added to the footer of the site by the launch in October.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.