Hi Bill,3.0 is a full rewrite of the codebase and API. So there will definitely be some lag before the mobile app catches up.However we are building a mobile friendly web UI with 3.0 which might help in the mean time, depending on your mobile needs.RobbieOn Fri, Jul 12, 2013 at 7:26 AM, Bill Morris <bill.boykinmorris@...> wrote:
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
>>
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@...
--Robbie MackaySoftware Developer, External ProjectsUshahidi Incm: +64 27 576 2243e: robbie@...skype: robbie.mackay