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..
