dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

Several people have asked for the link to the Google doc, and I have
added them to the list of editors.  I also changed the permissions to
allow anyone to read it.  These are some random thoughts I have had
about the whole categories/combos/options.  Your mileage may vary.

I have some more thoughts which I will add when I get a chance, after
this email, but feel free to add your thoughts as well to the doc.
Once we reach some consensus, if ever, perhaps this can evolve into a
more specific blueprint.

Here is the link...

https://docs.google.com/document/d/1swOxM-E-bYRBXhnalvAtuMb8FGYocxOCVvJS36B25C4/edit?hl=en

On 12/7/10, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
> 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
>>> >
>>
>>
>


-- 
Jason P. Pickering
email: jason.p.pickering@xxxxxxxxx
tel:+260968395190