Ushahidi Mailing Lists
« All Listsdevelopers@list.ushahidi.com
Re: [ushahidi developers] Categories in Ushahidi 3.0
From: Bill Morris <bill.boykinmorris@...>
Date: Thu, 11 Jul 2013 15:26:44 -0400
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