dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 7 December 2010 10:17, Ola Hodne Titlestad <olati@xxxxxxxxxx> wrote:
> On 7 December 2010 10:41, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>>
>> there seem to be 3 primary motivations for an implementor to use
>> categories
>> (i) it can make auto-generated forms do what you want
>> (ii) it reduces the number of dataelements you have to design
>> (iii) it provides an axis for analysis
>>
>> In the best of cases these three conspire together to produce a good
>> result.  eg datavalues which are collected disaggregated by sex.
>>
>> In other cases the benefits of (i) are so compelling that the fact
>> that (iii) is not consistent is not considered.  I've seen a few
>> proposed solutions to this (I think most recently a setting which
>> indicates whether a category is a "summing" category or not).  Not
>> sure if I'm too happy with any of them, but one observation is that in
>> almost all cases I've seen this occur, it is related to
>> stock/inventory.  This might just be a coincidence but sure looks like
>> a pattern to me. perhaps there might be a point in recognizing the
>> special case of inventory and make a small inventory module rather
>> than handling through "standard" data entry.
>>
>
> In Kenya it is actually the human resources form that is the problem. They
> repeat 10 columns (that do not add up) over about 40-50 different cadres, so
> many data elements.

OK.  I guess HR, like inventory, proceeds with its own logic which is
hard to completely capture in a simple data collection model.

I do also find myself agreeing with you that in a situation like this
and given current concrete reality, it should be better practice to
group data collection by category rather than to proliferate so many
dataelement names.  But the consequences still bother me.  Will think
more later ...

Cheers
Bob

> But I agree that stock forms are the most common one and that we should look
> into better support for logistics functionality, at least the simpler
> inventory stuff that is close to our model anyway.
> I think we have put "use of calculated expressions in custom data entry" on
> the roadmap somewhere. These will then provide a tools for adding more
> complex calculations that are needed in the form. Of course if we limit this
> functionality to the custom forms, which seems easier and less complex, then
> we can't use the auto-generated forms anyway.....
> Ola
>
>>
>> Looking at the 4 categoryoptions there is an opening balance, amount
>> issued, amount received and avg monthly requirement in each case.  As
>> well as stock reorder amounts etc associated with each dataelement.
>> Thuy seems to have done a good job in removing some of the extra
>> calculated values.  Though I am not sure about average monthly
>> requirement.  is that really an observation or is it calculated
>> somehow?  And how do we persist things like the min/max amounts etc.
>> Anyway there seems to be a particular and repeated logic which drives
>> these stock/inventory dataelements.  A stock/inventory module could
>> provide form layout based on that logic rather than on categorycombo.
>> As well as some extra data attributes for inventory related stuff
>> which would not be what we would term datelement.
>>
>> From analysis perspective the fewer the categories the better, reusing
>> categories is good and categories which don't add up are bad as they
>> create confusion and complication at the output end.
>>
>> From UI perspective, unless we can provide an alternative simple way
>> of achieving the simple tabular layout, users will continue to (ab)use
>> the categories for this.  The labour saving is really just too much.
>>
>> Sorry Thuy this is a bit of a distrasction from your initial question,
>> which I see Johan is addressing :-)
>>
>> Cheers
>> Bob
>>
>> On 7 December 2010 08:23, Jason Pickering <jason.p.pickering@xxxxxxxxx>
>> wrote:
>> > This has got me thinking once again what a category/combo/option
>> > actually is and how the current implementation makes too many
>> > assumptions, like that categories should add up to a total.
>> >
>> >  I would suggest we continue thinking about it in background  document
>> > I created a while back..
>> >
>> >
>> > https://docs.google.com/document/d/1swOxM-E-bYRBXhnalvAtuMb8FGYocxOCVvJS36B25C4/edit?hl=en
>> >
>> >
>> > On Tue, Dec 7, 2010 at 1:02 PM, Knut Staring <knutst@xxxxxxxxx> wrote:
>> >> On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen
>> >> <thuy.hispvietnam@xxxxxxxxx> wrote:
>> >>> Dear Johan,
>> >>> Thank you for your suggestions. Please scroll down to see my mail
>> >>>
>> >>>
>> >>>
>> >>> On Tue, Dec 7, 2010 at 1:59 AM, <johansa@xxxxxxxxxx> wrote:
>> >>>>
>> >>>> Dear Thuy,
>> >>>>
>> >>>> I'm not very familiar with the requirements in Sri Lanka, but I have
>> >>>> a few
>> >>>> general comments. First, the categories and combinations should be
>> >>>> used
>> >>>> when we want to aggregate them into a data element that is a natural
>> >>>> total
>> >>>> of these categories. For stock, this is usually not the case, as we
>> >>>> do not
>> >>>> want to add start balance, received, issued, and monthly requirement
>> >>>> (in
>> >>>> this case).
>> >>>
>> >>> About the total meaning of categories and categories options. I got
>> >>> the
>> >>> lesson from my mistake in Vietnam. So I didn't want to repeat again by
>> >>> explanation people here. But again because of the instant benefit of
>> >>> category data elements such as the defaul entry form will generate
>> >>> automatically with good form which DHIS provided. And the shorting of
>> >>> creating data elements,... So the person who do this project decided
>> >>> to use
>> >>> categories for this report as well as other reports for equipments
>> >>> like
>> >>> beds, tables,... I knew it is wrong for the meaning of categories
>> >>> which
>> >>> developers in DHIS wish to use. But I don't know serious reason for
>> >>> defense
>> >>> on this. That's why I consult you to know what will happen in the
>> >>> future
>> >>> when data base become huge if we use category options like this for
>> >>> data
>> >>> elements? Is it affecting to retrieving information later?
>> >>
>> >> Hi Thuy,
>> >>
>> >> I personally think one has to weight these things against each other.
>> >> I understand very well the desire to have nice autogenerated forms,
>> >> and I don't really see the big problem with using categories this way
>> >> AS LONG AS one bears in mind that the total will not work. I think the
>> >> major downside to doing it like this is that Pivot tables will not
>> >> work well on these dataelements, since the whole point of pivot tables
>> >> is to easily sum up - and if some of the sums are meaningless, that
>> >> restricts the usefulness of the pivot tables.
>> >>
>> >> It would be nice if it were possible to easily generate good looking
>> >> forms without violating the semantics of the aggregation model, though
>> >> I suppose that would require a decoupling of the form section
>> >> generating machinery from the data element model. One would then be
>> >> able to assign categorycombos to a section, but also group data
>> >> elements in sections external to the disaggregation model.
>> >>
>> >> Knut
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~dhis2-devs
>> >> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>> >> More help   : https://help.launchpad.net/ListHelp
>> >>
>> >
>> >
>> >
>> > --
>> > Jason P. Pickering
>> > email: jason.p.pickering@xxxxxxxxx
>> > tel:+260968395190
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~dhis2-devs
>> > Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~dhis2-devs
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>
>