I would add to Heather's hesitation by mentioning that the ushahidi
mobile app requires "category" in the submitted schema, and I have no
idea what the update schedule is for that channel (devs seem a bit
overworked already:
https://github.com/ushahidi/Ushahidi_Android/issues).

The mobile app is clutch for a number of projects I'm working on, so
it would be jarring to suddenly lose access with an update to 3.0.

-Bill

On Thu, Jul 11, 2013 at 12:45 PM, Heather Leson <hleson@...> wrote:
> Hey, I am a touch confused on this based on the various user groups.
>
> While I agree that too many categories might be a poor path for deployments,
> I think we need to be flexible.
>
> Categories are currently used for Top keywords, sub-categories and sometimes
> location, actions and, even, task groups. See the analysis of Corruption
> mappers. I like to say there is a difference between - what the deployer
> wants to collect/analysis and what the reporter has 1. time for 2.
> comprehension of what is being requested = eg. what is the difference
> between "damage" and "instrastructure damage". Part of this is up to the
> deployers to teach and define well, but the ways that categories get
> selected matter.
>
> I think that some groups use "location" within categories to give better
> drill into the data. IF polygons, layers and even search worked at a decent,
> usable level, then this would maybe not be a kluge.
>
> Sometimes deployers use categories for workflow for large teams. How will
> this be addressed?
>
> I am not sure that 'tags' will assist the researchers and reporters. Can you
> please go into how this will work inside the deployment and for exports?
>
> +1 on Rob's questions which are still outstanding.
>
> Heather
>
> On Thu, Jun 27, 2013 at 3:24 PM, Rob Baker <rrbaker@...> wrote:
>>
>> As long as filtering is available for both (and from more than just one
>> section of the public site), this seems to make sense so far.  Will the
>> report status options be separated from the categories?  Having the status
>> and context categories in the same place for Uchaguzi definitely felt like
>> the biggest-but-functional hack of that deployment.
>>
>> Thanks for sharing this with the larger team,
>> R
>>
>>
>> On Thu, Jun 27, 2013 at 11:45 AM, Seth Hall <seth@...> wrote:
>>>
>>> Yes, this makes great sense and seem very streamlined and provides good
>>> options.
>>>
>>> --
>>> Seth Hall
>>> Front-End Designer & Developer
>>> ushahidi.com
>>>
>>> On Thursday, June 27, 2013 at 4:39 PM, Robbie MacKay wrote:
>>>
>>> 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
>>>
>>> Polling Station Administration
>>>
>>> Ballot Box Irregularities
>>>
>>> Polling Station Closed Before Voting Concluded
>>>
>>> Missing/Inadequate Voting Materials
>>>
>>> Polling Station Logistical Issues
>>>
>>> Campaign material in polling station
>>>
>>> Positive Event
>>>
>>> Civilian Peace Efforts
>>>
>>> Everything Fine
>>>
>>> Police Peace Efforts
>>>
>>> Security Issues
>>>
>>> Presence of weapons
>>>
>>> Purchase of weapons
>>>
>>> Mobilisation towards violence
>>>
>>> Threat of violence
>>>
>>> Ambush
>>>
>>> Voting Issues
>>>
>>> Voting Irregularities
>>>
>>> Purchasing of Voters Cards
>>>
>>> Voters Issued Invalid Ballot Papers
>>>
>>> Voter Integrity Irregularities
>>>
>>> Irregularities with voter assistance
>>>
>>> Voter Register Irregularities
>>>
>>> Voter Identification Issues
>>>
>>> Urgent
>>>
>>> Resolved
>>>
>>> Unresolved
>>>
>>>
>>> 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
>>> m: +64 27 576 2243
>>> e: robbie@...
>>> skype: robbie.mackay
>>>
>>>
>>
>
>
>
> --
> Heather Leson
> Director of Community Engagement
> Ushahidi
> hleson@...
> www.ushahidi.com and https://wiki.ushahidi.com
> @heatherleson / skype: heatherleson

~~~~~~~~~~~~~~~~~~~~~~~~~~
List Archive: http://list.ushahidi.com/

Would you like to receive list mail batched in a daily digest instead? Send a message to:
developers-digest-subscribe@...

To remove your address from the list, just send a message to
the address in the "List-Unsubscribe" header of any list
message. If you haven't changed addresses since subscribing,
you can also send a message to:
developers-unsubscribe@...

For addition or removal of addresses, we'll send a confirmation
message to that address. When you receive it, simply reply to it
to complete the transaction.

If you need to get in touch with the human owner of this list,
please send a message to:
developers-owner@...