dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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.

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
>