ABOUT US PRODUCTS GET INVOLVED BLOG

Ushahidi Mailing Lists

« All Listsdevelopers@list.ushahidi.com

Message: previous - next
Month: July 2013

Re: [ushahidi developers] Categories in Ushahidi 3.0

From: Bill Morris <bill.boykinmorris@...>
Date: Thu, 11 Jul 2013 15:26:44 -0400
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