Hi All,
I'm in London with the 3.0 team this week trying to figure on the many many details involved.
We've just finished up a discussion about how categories will work so I'm writing it up while its fresh. Categories have been a major tool in 2.x but I've always felt they're kind of abused and that often there's a better way to represent the data we capture via categories.
Key discussion points: Do categories need a multi level hierarchy? Do categories need to be multiple select?
Categories will be single select. But we temper this by adding multiple category types, and possibly giving report types a colour and icon.
Categories won't have a hierarchy, since this info is often better handled by a custom field instead.
Here's an example to explain.. lets take a subset of the Uchaguzi categories
Restructuring this for 3.0, we could would create 4 'Post types' with their own forms:
Polling Admin issue, Positive Event, Security issue, Voting Issue.
And a tag type of 'Status' with tags resolved and unresolved.
The submission flow then becomes.
1. Create post
2. Select post types (ie. security issue)
3. Enter report details
This would a custom field for specific issue detail. ie. 'Threat of violence'
4. Submit
5. Admin approves and tags with 'Resolved' or 'Unresolved'
--
Single select categories means we can visualise the different categories on the map, showing different icons for categories. While tag and post types mean in future we can switch which bit of the data we're visualizing.
For example if you were mapping earthquake damage you could add tag types for 'Severity' and 'Building type'. Then we might be able to alternate which of these you visualise on a map, ie. heat mapping severity of damage, while also filtering based on type of building.
I'm not totally sure how this will all come together, but I think this model of categories gives us a better base and better data to build on later.
--
Robbie Mackay
Software Developer, External Projects
Ushahidi Inc
skype: robbie.mackay