December review

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

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

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

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

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

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

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


Design screenshots

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

Report an issue page:


Thread discussion page:


Issue page – each thread of discussion on issue:


And an icon set under development for the map markers:


Moving into beta

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

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

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

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

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

What’s in place now?

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

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

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

Innovation: testing assumptions

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

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

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

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

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

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

The three areas that we’re working through are:

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

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

Design screenshots

Stay tuned for news on design screenshots..